Как мне наиболее эффективно хранить и обслуживать более 1 000 000 небольших файлов в формате gziped на веб-сервере Linux?
У меня большой статический контент, который мне нужно доставить через веб-сервер на базе Linux. Это набор из более чем миллиона небольших файлов gzip. 90% файлов имеют размер менее 1 КБ, а остальные файлы - не более 50 КБ. В будущем это число может вырасти до более 10 миллионов файлов gzip.
Следует ли мне поместить это содержимое в файловую структуру или следует рассмотреть возможность размещения всего этого содержимого в базе данных? Если он находится в файловой структуре, могу ли я использовать большие каталоги или мне следует рассмотреть каталоги меньшего размера?
Мне сказали, что файловая структура будет быстрее для доставки, но, с другой стороны, я знаю, что файлы будут занимать много места на диске, поскольку блоки файлов будут более 1 КБ.
Какая стратегия является наилучшей в отношении эффективности доставки?
ОБНОВИТЬ
Для справки, я провел тест под Windows 7 с полмиллионом файлов:
Я предполагаю, что структура FS будет быстрее, но вам понадобится хорошая структура каталогов, чтобы избежать каталогов с очень большим количеством файлов.
Я бы не стал слишком беспокоиться о потерянном дисковом пространстве. Например, при размере блока 16 КБ вы потеряете 15 ГБ пространства в худшем случае, когда вам понадобится один дополнительный блок для каждого отдельного файла. С сегодняшними размерами дисков это еще ничего, и вы можете адаптировать параметры файловой системы под свои нужды.
Если вы выберете опцию файловой структуры, то для улучшения производительности дискового ввода-вывода, по крайней мере, до некоторой степени, вы можете смонтировать раздел с помощью noatime + nodiratime, если они вам не нужны. Они вообще не важны, поэтому я рекомендую это сделать. Возможно, вы также можете использовать твердотельный накопитель.
Я думаю, что правильный ответ здесь зависит от того, как файлы будут проиндексированы ... что определяет, когда данный файл будет выбран для доставки.
Если вы уже делаете запрос к базе данных, чтобы определить имя файла, вы вполне можете обнаружить, что вам лучше сохранить файл прямо здесь, в записи db, вы можете найти лучшие результаты от настройки некоторых параметров подкачки в вашей базе данных выбор, а затем сохранение файлов в базе данных (например, большие страницы для учета всех записей BLOB-объектов), или вы можете обнаружить, что вам все же лучше использовать файловую систему.
Вариант с базой данных имеет немного больше шансов сработать, потому что с миллионом записей вероятно, что каждый файл не будет одинаково запрошен. Если вы находитесь в ситуации, когда один файл может запрашиваться несколько раз подряд или почти подряд, база данных может действовать как фактический кеш для недавно извлеченных файлов, и в этом случае вы часто получаете результат файла уже загружен в память. Возможно, вам потребуется тщательно настроить внутреннее устройство вашей базы данных, чтобы получить желаемое поведение.
Но главное, что нужно вынести из моего ответа, это то, что вы действительно не знаете, что будет работать лучше всего, пока не попробуете это с некоторыми репрезентативными данными тестирования и не измерите результаты.
С современными файловыми системами это не должно быть большой проблемой. Я тестировал XFS с 1 миллиардом файлов в одном каталоге, и я почти уверен, что ext4 тоже подойдет (при условии, что сама файловая система не слишком велика). Иметь достаточно памяти для кэширования записей каталога; больший кеш процессора тоже поможет.