Який розмір блоку для мільйонів невеликих файлів

У мене є 2x 4 ТБ диска в апаратному RAID1 (це може бути LSI MegaRaid) на Debian Wheezy. Фізичний розмір блоку - 4 кБ. Я збираюся зберігати 150-200 мільйонів невеликих файлів (від 3 до 10 КБ). Я не прошу продуктивність, але найкращі розміри файлової системи та блоків для збереження пам’яті. Я скопіював файл у 8200 байт на ext4 з розміром блоку 4 кБ. Це зайняло 32 кБ диска !? Чи причина журналу в цьому? То які варіанти є для збереження більшості пам’яті для таких невеликих файлів?

— rabudde
джерело

Дивіться також: Як визначити розмір блоку розділу ext3 в Linux?

— Chris S

Якби я опинився в такій ситуації, я би розглядав базу даних, яка може зберігати всі дані в одному файлі з компактним індексом на основі зміщення, а не як окремі файли. Можливо, база даних, у якій є драйвер FUSE, доступний для взаємодії з нею як файлами, коли це необхідно, без них насправді всі НЕБЕ окремі файли.

Крім того, ви можете розглянути, скажімо, 60 - 70-й перцентиль розмірів файлів і спробувати помістити цей розмір файлів безпосередньо у вузли дерева файлової системи, а не як окремі блоки на диску. Збереження 10k у кожному вузлі - це, мабуть, великий запит, але якщо ви можете отримати там 60% -70% файлів, це, ймовірно, буде величезним виграшем.

Тільки певні файлові системи можуть це робити взагалі (reiserfs - це одне), і я думаю, все залежить від того, який розмір має цей процентиль, чи БУДЕ він вміщуватись у дереві. Можливо, ви зможете це настроїти. Напевно, спробуйте помістити решту в один блок.

І не турбуйтеся про журнали; у них в будь-якому випадку є верхня межа розміру.

Ні ні ні ні ні ні ні ні не просто… ні вашому першому абзацу. Я зробив цю помилку років тому, і її потрібно було потім скасувати. Я також успадкував системи, які використовують цю модель дизайну. Файли належать до файлової системи, або як компроміс, в об'єкті FileStream SQL Server, якщо ви повинні їх об'єднати (так, можливо, ваш драйвер FUSE, але все одно просто немає). Є й інші міркування при роботі у файловій системі, наприклад, не кладіть 4 мільйони файлів в одну папку (я теж помилився).

— Марк Хендерсон

@MarkHenderson, але проблема полягає у визначенні того, який ДОЛЖЕН би бути файлом, а що має бути записом. Без надання більше деталей сотні сотень мільйонів крихітних речей звучать набагато більше, як записи. Тільки тому, що він наразі має їх як файли, це не означає, що вони повинні залишатись такими або повинні були колись бути такими. Крім того, я ні на секунду не пропонував використовувати SQL Server для роботи;)

5 років тому я успадкував систему з 1 мільйоном файлів в одній папці і приблизно 10 000 нових файлів 1-4 КБ щодня. Я вирішив кинути їх усіх у таблицю ISAM, оскільки "Ей, вони просто простий текст для аналізу!" а потім це виявилося величезною помилкою, тому що я мав єдину таблицю об'ємом 12 ГБ із шквалом рядків, які здебільшого нічого не робили після їх обробки. Тож я перейшов до того, щоб розмістити їх у файловій системі з герахіальними папками на основі GUID імені файлу.

— Марк Хендерсон

(чому проблема з єдиним столом на 12 ГБ із рядами шквалу була проблемою - це інша справа, яку я сюди не потрапляю)

— Марк Хендерсон

@MarkHenderson: Це не інша проблема, ось ЧОМУ ви сказали, що це неправильне рішення ("... величезна помилка, тому що в мене зараз єдина таблиця об'ємом 12 ГБ із шрифтом рядків ...."). Ви вибираєте неправильний формат двигуна / таблиці таблиць, але концепція розміщення безлічі дрібних речей в одному файлі з INDEX є здоровим, якщо ви робите це правильно. Те, що вам потрібно, це база даних, яка відрізняється від ключових / цінних сховищ для мільйонів дрібних об'єктів з автоматичним натягуванням. Також зауважте, що він спеціально навіть не піклується про продуктивність, а просто про місце.