Як я найефективніше зберігати та обслуговувати 1 000 000+ малих gziped-файлів на веб-сервері Linux?


10

У мене є великий статичний вміст, який я маю доставляти через веб-сервер на базі Linux. Це набір з понад мільйона маленьких gzip-файлів. 90% файлів менше 1 К, а решта файлів - не більше 50 К. Надалі це може вирости до понад 10 мільйонів файлів gzip.

Чи повинен я вміщувати цей вміст у структуру файлів чи слід розглянути можливість розміщення всього цього вмісту в базі даних? Якщо вона є у файловій структурі, чи можу я використовувати великі каталоги чи слід розглядати менші каталоги?

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

Яка найкраща стратегія щодо ефективності доставки?

ОНОВЛЕННЯ

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

введіть тут опис зображення

Відповіді:


6

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

Я б не переймався надто втраченим місцем на диску. Наприклад, при розмірі блоку 16K ви втратите 15 Гб місця в гіршому випадку, коли вам знадобиться один додатковий блок для кожного окремого файлу. З сьогоднішніми розмірами дисків - це нічого, і ви можете адаптувати параметри вашої файлової системи під ваші конкретні потреби.


5

Якщо ви обрали варіант файлової структури, одне, що ви можете зробити, щоб принаймні певною мірою покращити продуктивність вводу-виводу диска - це змонтувати розділ у режимі noatime + nodiratime, якщо у вас їх не має бути. Вони зовсім не важливі, тому рекомендую це робити. Можливо, ви також можете використовувати твердотільний накопичувач.


4

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

Якщо ви вже робите запит до бази даних, щоб визначити своє ім'я файлу, ви можете виявити, що вам краще зберігати файл прямо там, в db-записи, ви можете знайти найкращі результати від налаштування деяких параметрів підкачки у вашій базі даних Вибір, а потім зберігання файлів у db (напр .: більші сторінки для обліку всіх записів блобу), або ви можете виявити, що вам все-таки краще використовувати файлову систему.

Опція бази даних має трохи кращі шанси випрацювати, тому що, при мільйоні записів, ймовірно, що кожен файл не однаковою мірою буде запитуватися. Якщо у вас виникає ситуація, коли один файл може бути запитаний кілька разів поспіль або майже підряд, база даних може діяти як фактичний кеш для нещодавно отриманих файлів, і в такому випадку ви часто матимете результат свого файлу вже завантажено в пам'ять. Можливо, вам потрібно буде ретельно налаштувати внутрішній механізм бази даних, щоб отримати потрібну поведінку.

Але головне, що потрібно відвернути від моєї відповіді, - це те, що ти насправді не знаєш, що буде найкраще працювати, доки не спробуєш це з деякими репрезентативними даними тесту та не виміряєш результати.


1

З сучасними файловими системами це не повинно бути великою проблемою. Я протестував XFS з 1 мільярдом файлів у тому самому каталозі, і я впевнений, що ext4 теж буде добре (до тих пір, поки сама файлова система не надто велика). Достатньо пам'яті для кешування записів у каталозі; більший кеш процесора теж допоможе.


2
Файлові системи EXT не дуже добре справляються з великою кількістю файлів у тому ж режимі; особливо не з типовими налаштуваннями directory_index. Я не перевіряв XFS з таким високим числом файлів у тому ж режимі, але я впевнений, що EXT не буде працювати з чимось віддаленим, близьким до 1 мільярда в тому ж режимі.
Хрвой Шполяр

1
Я чув, що reiserfs корисний для невеликих файлів, але потім я також почув, що хлопець, який підтримує програмне забезпечення, перебуває у в'язниці (!), Тому найближче майбутнє рейзерфів досить невизначене. Я особисто ходив би EXT4 та XFS як другий вибір. Хіба XFS не найкращий для великих файлів?
öde

Раніше це було, але якщо ви використовуєте свіже ядро ​​(3.0 і вище), воно добре працює і для невеликих файлів.
wazoox
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.