Які наслідки для продуктивності мільйонів файлів у сучасній файловій системі?

Скажімо, ми використовуємо ext4 (з увімкненим dir_index) для розміщення файлів 3M (із середнім розміром 750 КБ), і нам потрібно вирішити, яку схему папок ми будемо використовувати.

У першому рішенні ми застосовуємо хеш-функцію до файлу і використовуємо папку двох рівнів (це 1 символ для першого рівня та 2 символи для другого рівня): тому filex.forхеш дорівнює abcde1234 , ми збережемо його в / path / a / bc /abcde1234-filex.for.

У другому рішенні ми застосовуємо хеш-функцію до файлу і використовуємо папку двох рівнів (це 2 символи для першого рівня та 2 символи для другого рівня): тому, будучи filex.forхеш рівним abcde1234 , ми збережемо його в / path / ab / de /abcde1234-filex.for.

Для першого рішення ми матимемо наступну схему /path/[16 folders]/[256 folders]із середнім рівнем 732 файлів на папку (остання папка, де файл буде перебувати).

У той час як у другому рішенні у нас буде /path/[256 folders]/[256 folders]в середньому 45 файлів на папку .

Зважаючи на те, що ми збираємось писати / від’єднувати / читати файли ( але в основному читати ) з цієї схеми багато (в основному це система кешування nginx), чи це має значення в сенсі продуктивності, якщо ми обрали те чи інше рішення?

Також які інструменти ми могли б використати для перевірки / тестування цієї установки?

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

Наскільки повільніше залежить від дизайну файлової системи.

Файлова система ext4 використовує B-дерево для зберігання записів у каталозі. Очікується, що пошук у цій таблиці займе час O (log n) , який більшу частину часу менше, ніж наївна лінійна таблиця, яку використовували ext3 та попередні файлові системи (а коли це не так, каталог занадто малий, щоб він дійсно має значення).

У файловій системі XFS замість цього використовується дерево B + . Перевага цього над хеш-таблицею або B-деревом полягає в тому, що будь-який вузол може мати кілька дітей b , де в XFS b змінюється і може досягати 254 (або 19 для кореневого вузла; і ці числа можуть бути застарілими ). Це дає часову складність O (log _b n) , величезне вдосконалення.

Будь-яка з цих файлових систем може обробляти десятки тисяч файлів в одному каталозі, причому XFS значно швидше, ніж ext4 в каталозі з однаковою кількістю входів. Але ви, мабуть, не хочете єдиного каталогу з 3M inode, оскільки навіть з B + деревом пошук може зайняти деякий час. Саме це спричинило насамперед створення каталогів таким чином.

Що стосується запропонованих вами структур, то перший варіант, який ви дали, - це саме те, що показано в прикладах nginx. Він буде добре працювати в будь-якій файловій системі, хоча XFS все одно матиме трохи переваги. Другий варіант може бути дещо кращим або трохи гіршим, але він, ймовірно, буде досить близьким, навіть за показниками.

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

Обидва запропоновані вами варіанти створюють до трьох записів вкладки для кожного створеного файлу. Також 732 файли створять іноду, який все ще менше, ніж звичайний 16 КБ. Для мене це означає, що будь-який варіант виконає те саме.

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

Звичайно, будь-який варіант допоможе зменшити кількість файлів у каталозі до того, що здається розумним, для xfs або ext4 або будь-якої файлової системи. Не очевидно, що краще, доведеться перевірити, щоб сказати.

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

hdparmробити стійкий ввід / вивід не так корисно. Він не відображатиме безліч малих записів вводу / виводу або гігантських записів каталогів, пов'язаних з дуже багатьма файлами.

Одне з питань - спосіб сканування папки.

Уявіть метод Java, який виконує сканування в папці.

Йому доведеться виділити великий об'єм пам'яті і розподілити її за короткий проміжок часу, що є дуже важким для JVM.

Найкращий спосіб - упорядкувати структуру папки так, як кожен файл знаходиться у спеціальній папці, наприклад, рік / місяць / день.

Спосіб повного сканування полягає в тому, що для кожної папки є один запуск функції, тож JVM вийде з функції, розподілить оперативну пам’ять і запустить її знову в іншій папці.

Це лише приклад, але все одно мати таку величезну папку немає сенсу.

У мене було те саме питання. Спроба зберігати мільйони файлів на сервері Ubuntu в ext4. Закінчила запускати власні орієнтири. Виявив, що плоский каталог працює набагато краще, одночасно простіший у використанні:

Написав статтю .