Миллион файлов

[bruto]

Здравствуйте!

Может кто то сталкивался с таким.

Нужно создать на сервере до миллиона небольших файлов (300-500 б.)
Вытаскивать их все, пересчитывать не нужно.
Нужно будет только проверять наличие одного из файлов is_file() и вытаскивать содержимое file_get_contents().
Будет ли тормозить и грузить сервер если поместить все файлы в один каталог?

 

[bruto]

Что будет быстрее работать?
Когда миллион файлов в одном каталоге или один файл в миллионе каталогов?

 

[AnrDaemon]

Возьми да проверь. Тебя кто-то за руки держит что ли?

 

[Фанат]

тормозить будет, клади по 1000 файлов в 1000 каталогов

а еще лучше - все в один файл, например БД

 

[c0dex]

@Фанат, имхо, если там размер 500 байт, то это надо класть в базу

 

[Фанат]

@Фанат, имхо, если там размер 500 байт, то это надо класть в базу

Ну, я по привычке сначала ответил только на заголовок, а потом прочитал сам вопрос

 

[AnrDaemon]

Кстати, да, что-то я сегодня туплю. 500 байт это даже меньше обычного размера кластера.

 

[fixxxer]

Ответ зависит от используемой файловой системы.

В случае наиболее вероятной ext4 скорее всего упрешься в обычно включенный dir_index (man 8 tune2fs).

А вот, скажем, на XFS тормозить в таком случае вроде бы нечему.

 

[fixxxer]

Если заранее известно, что размер блока данных не превышает, скажем, 1 килобайт, и их общее количество не превышает, скажем, миллион, можно вообще все это дело хранить в одном преаллоцированном файле.

Пусть у нас до миллиона блоков данных размером до 1 кб. Делаем преаллоцированный файл, забитый нулями размером в гигабайт, каждый блок данных с номером N от 0 до 999999 храним добитым до килобайта нулями по кратной килобайту позиции, соответствующей его номеру начиная с нуля (N * 1024).
Если в данных могут встречаться нулевые символы, первые 2 байта отводим под длину блока.

 

[AnrDaemon]

Что возвращает нас к использованию БД, как оптимального по соотношению цена/качество варианта.

 

[fixxxer]

С базой первое приходящее в голову очевидное решение, неинтересно даже обсуждать

 

[AnrDaemon]

Ну, логично. Смысл обсуждать, делать надо.

 

[Adelf]

@antson, ну если так немного данных, что они влезут в оперативку - да. у него впс может быть поменьше.

 

[AnrDaemon]

Муська
здесь избыточна .

А кроме MySQL вам другие БД незнакомы?…

 

[Фанат]

@fixxxer, а c файлом все упирается в их общее количество не превышает,

так по условиям задачи и не превысит.
даже с двойным перезакладом по размеру получается 1 гиг. это даже на FAT ничего не превысит
или ты о чем?

 

[Фанат]

@Фанат, не масштабируется.

Не, ну если уж придираться к придложению фиксера, то масштабируемость это сбудет самая меньшая из проблем
Но вот в качестве полезного обучающего эксперимента будет очень полезно

 

[fixxxer]

не масштабируется. Потом придется закладывать , что файл для следующего миллиона.

Аллокация второго файла при необходимости, и чтение файла по принципу $filename = $id % 1000000 - это как раз тут наименьшая проблема.

Если 999 тыс ид из первого миллиона больше не нужны, то все равно гиг держать.
Ну и ключ только целое. Что создает гимор при реализации, если он символьный.

А вот тут начинается интересное. Получается, что физический номер смещения неудобен для адресации по логическому идентификатору. Значит, надо сделать еще один файл, в котором поддерживать карту соответствий логических идентификаторов физическим, причем хотелось бы минимум перезаписей и быстрый поиск по нему. Какие мы там алгоритмы помним? Ну... Например, B+Tree вполне годится. И тут мы начинаем понимать, как в первом приближении работает СУБД.

 

[AnrDaemon]

@AnrDaemon, можно будем считать что под муськой я имел в виду класс реляционных субд (My,Pg,Ms,Oraqle)?

В условии явно прописан локальный файл, так что SQLite.

 

[grigori]

сделать еще один файл, в котором поддерживать карту соответствий логических идентификаторов физическим, причем хотелось бы минимум перезаписей и быстрый поиск по нему. Какие мы там алгоритмы помним?

vacuum, autovacuum и facepalm с убером? =))) знаем такой алгоритм

 

[AmdY]

Какой-то сплошной оверинженеринг, а были времена когда спрашивали: зачем?
@bruto а зачем?