Как наиболее эффективно хранить и обслуживать более 1 000 000 небольших сжатых файлов на веб-сервере Linux?

У меня большой статический контент, который я должен доставить через веб-сервер на базе Linux. Это набор из более чем одного миллиона маленьких файлов gzip. 90% файлов имеют размер менее 1 КБ, а остальные файлы - не более 50 КБ. В будущем это может увеличиться до 10 миллионов GZIP-файлов.

Должен ли я поместить этот контент в файловую структуру или мне следует рассмотреть возможность размещения всего этого контента в базе данных? Если это в файловой структуре, могу ли я использовать большие каталоги или мне следует рассмотреть меньшие каталоги?

Мне сказали, что файловая структура будет быстрее для доставки, но, с другой стороны, я знаю, что файлы будут занимать много места на диске, так как файловые блоки будут больше 1 КБ.

Какова лучшая стратегия в отношении эффективности доставки?

ОБНОВИТЬ

Для записей я выполнил тест под Windows 7 с полумиллионом файлов:

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

Я бы не стал слишком беспокоиться о потерянном дисковом пространстве. Например, при размере блока 16 КБ вы потеряете 15 ГБ места в худшем случае, когда вам потребуется один дополнительный блок для каждого отдельного файла. С сегодняшними размерами дисков это ничего, и вы можете адаптировать параметры вашей файловой системы для ваших конкретных потребностей.

Если вы выберете опцию файловой структуры, вы можете, по крайней мере, до некоторой степени улучшить производительность дискового ввода-вывода, - смонтировать раздел с помощью noatime + nodiratime, если у вас их нет. Они совсем не важны, поэтому я рекомендую это сделать. Может быть, вы также можете использовать твердотельный накопитель.

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

Если вы уже делаете запрос к базе данных, чтобы определить имя вашего файла, вы можете обнаружить, что лучше сохранить файл прямо в записи базы данных, вы можете найти наилучшие результаты от настройки некоторых параметров подкачки в вашей базе данных. выберите и затем сохраните файлы в БД (например: большие страницы для учета всех записей BLOB-объектов), или вы можете обнаружить, что вам по-прежнему лучше использовать файловую систему.

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

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

С современными файловыми системами это не должно быть большой проблемой. Я тестировал XFS с 1 миллиардом файлов в одной и той же директории, и я уверен, что ext4 тоже подойдет (если сама файловая система не слишком большая). Иметь достаточно памяти для кэширования записей каталога; Большой кэш процессора тоже поможет.