Я запускаю веб-сайт, де близько 10 мільйонів файлів (обкладинки книг) зберігаються в 3 рівнях підкаталогів, починаючи з [0-f]:

0/0/0/
0/0/1/
...
f/f/f/

Це призводить до приблизно 2400 файлів у каталозі, що дуже швидко, коли нам потрібно отримати один файл. Крім того, це практика, запропонована багатьма питаннями .

Однак, коли мені потрібно створити резервну копію цих файлів, потрібно просто багато днів переглядати 4k каталоги, що містять 10м файли.

Тож мені цікаво, чи можу я зберігати ці файли в контейнері (або в 4-х контейнерах), який би діяв точно так само, як файлова система (якийсь встановлений контейнер ext3 / 4?). Я думаю, що це було б настільки ж ефективно, як доступ безпосередньо до файлу у файловій системі, і це матиме велику перевагу - дуже ефективно скопіювати на інший сервер.

Будь-яка пропозиція, як це зробити найкраще? Або будь-яка життєздатна альтернатива (noSQL, ...)?

Параметри швидкого доступу та створення резервної копії мільйонів файлів

Позичайте у людей з подібними проблемами

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

http://devel.squid-cache.org/coss/coss-notes.txt

http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf

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

Виділені файлові системи

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

НВМ

Вище я згадав LVM як корисний, щоб дозволити динамічне розмір розділу, щоб не потрібно було створювати резервну копію багато порожнього простору. Але, звичайно, LVM має інші функції, які можуть бути дуже застосовними. Зокрема, функція "знімка", яка дозволяє заморозити файлову систему на момент часу. Будь-який випадковий rm -rfабо будь-який інший спосіб не завадить зробити знімок. Залежно від того, що ви намагаєтеся зробити, це може бути достатньо для ваших потреб в резервному копії.

RAID-1

Я впевнений, що ви вже знайомі з RAID і, ймовірно, вже використовуєте його для надійності, але RAID-1 можна використовувати і для резервного копіювання, принаймні, якщо ви використовуєте програмне забезпечення RAID (ви можете використовувати його з апаратним RAID, але це насправді дає нижчу надійність, оскільки для читання може знадобитися одна і та ж модель / контролер перегляду). Концепція полягає в тому, що ви створюєте групу RAID-1 з ще одним диском, ніж вам насправді потрібно підключити для нормальних потреб у надійності (наприклад, третій диск, якщо ви використовуєте програмне забезпечення RAID-1 з двома дисками, або, можливо, великий диск і апаратне забезпечення, RAID5 з меншими дисками з програмним забезпеченням RAID-1 поверх апаратного RAID-5). Коли настає час взяти резервну копію, встановити диск, попросити mdadm додати цей диск до групи рейдів, дочекатися, поки він покаже повноту, необов’язково попросіть перевірку скрупуля, а потім видаліть диск. Звичайно,

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

Ще одна альтернатива - резервне копіювання всього пристрою за допомогою dd. Наприклад, dd if=/dev/my_device of=/path/to/backup.dd.

Як ви, напевно, знаєте, ваша проблема - місцевість. Типовий пошук диска займає 10 мс або близько того. Тому для виклику "stat" (або open ()) на 10 мільйонів випадково розміщених файлів потрібно 10 мільйонів пошуків, або близько 100000 секунд, або 30 годин.

Отже, ви повинні помістити свої файли у більші контейнери, щоб відповідне число було пропускною здатністю вашого накопичувача (як правило, 50-100 Мб / сек для одного диска), а не час пошуку. Крім того, ви можете кинути на нього RAID, що дозволяє збільшити пропускну здатність (але не скоротити час пошуку).

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

Є пара варіантів. Найпростіша і повинна працювати з усіма файловими системами Linux - це ddскопіювати весь розділ ( /dev/sdb3або /dev/mapper/Data-ImageVol) в одне зображення і заархівувати це зображення. У разі відновлення сингулярних файлів, за допомогою резервного mount -o loop /usr/path/to/file /mountpointкопіювання змонтуйте зображення ( ) та скопіюйте потрібні файли. Для повного відновлення розділу можна змінити напрямок початкової ddкоманди, але вам дійсно потрібен розділ однакового розміру.

Судячи з ваших випадків використання, я здогадуюсь, що окремі відновлення файлів - це дуже рідкісна подія, якщо вони взагалі коли-небудь трапляються. Ось чому резервне копіювання на основі зображення насправді має сенс. Якщо вам потрібно робити індивідуальні реставрації частіше, використовувати поетапні знімки LVM буде набагато зручніше; але вам все-таки потрібно зробити резервну копію на основі зображень для критичних катастроф "ми втратили все". Відновлення на основі зображення, як правило, йдуть набагато швидше, ніж відновлення на основі дьогтю просто тому, що це просто відновлення блоків, це не спричиняє зовсім небагато операцій з метаданими при кожному fopen / fclose, а також може бути дуже послідовною операцією на диску для подальше збільшення швидкості.

Крім того, як Google Video @casey вказував на згадування про половину шляху, XFS - це чудова файлова система (якщо вона складна). Однією з приємніших утиліт з XFS є xfsdumpутиліта, яка скидає всю файлову систему в один файл і, як правило, робить це швидше, ніж tarможе. Це специфічна для файлової системи програма, тому можна скористатися внутрішніми можливостями fs таким чином, що tar не може.

Я б запропонував спершу спробувати оновити до EXT4, якщо ви його вже не запустите.

Google провів багато досліджень, чому EXT4 - хороша ідея .

Після цього слід вивчити розгортання архітектури розподіленої файлової системи. Наприклад:

• http://www.xtreemfs.org/
• http://code.google.com/p/kosmosfs/
• http://hadoop.apache.org/hdfs/

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

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

Яка користь від усього цього? Продуктивність, яка повністю відповідає диску, читається, якщо виконано правильно. Крім того, Mongo оснащений кількома чудовими вбудованими способами для швидкого резервного копіювання всієї кількості даних в екземплярі БД, навіть навіть при роботі з базою даних.

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

Є кілька функцій, які допоможуть у вирішенні проблеми.

• Версія Enterprise підтримує форму віддаленої реплікації на основі знімків, яка не потребує сканування через усю файлову систему.

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

Ви можете використовувати стандартну dumpутиліту для резервного копіювання файлової системи EXT4 з великою кількістю файлів. Ця утиліта спочатку перевіряє, які блоки використовуються у файловій системі, а потім створює резервну копію їх у порядку диска, виключаючи більшість запитів.

Існує відповідна restoreутиліта для відновлення резервних копій, створена компанією dump.

Він підтримує додаткові резервні копії, використовуючи файли резервного копіювання рівнів - рівень 1, змінені з останнього 0 (повного) резервного копіювання, рівень 2 - модифіковані з резервного копіювання рівня 1 тощо.

Для покрокових резервних копій одним із варіантів було б мати друге тіньове дерево для нових обкладинок. Тобто у вас буде ваше основне дерево, яке використовується для всіх операцій з читання. Ви також мали бnewfiles/012345.....jpg каталог; нещодавно додані обкладинки створюють жорстке посилання як тут, так і в головному дереві. Виконуючи резервні копії, ви можете періодично створювати резервні копії головного дерева, але newfilesнабагато регулярніше створювати резервні копії (набагато меншого) дерева.

Зауважте, що для збереження newfilesдерева невеликим, перед виконанням нового резервного копіювання основного дерева, ви можете спорожнити дерево нових файлів:

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

Після цього, звичайно, ви зобов'язані створити нову резервну копію основного дерева.

Додавання трохи сумісності зазвичай допомагає.

У мене схожа проблема, ніж у вас; в моєму випадку мені потрібно створити резервну копію близько 30 мільйонів файлів, більшість з яких HTML, PHP або JPEG. Для мене BackupPC + rsync над ssh працює добре; Повне резервне копіювання займає приблизно один день, але додаткові розміри зазвичай закінчуються через пару годин.

Хитрість полягає в тому, щоб додати кожен каталог основного рівня (0, 1, 2 ... a, b, c ...) як нову ціль, щоб скопіювати в BackupPC і дозволити йому виконувати резервну копію паралельно, щоб вона одночасно створювала резервні копії каталогів a / , b / , c / * тощо. Залежно від вашої дискової підсистеми, можливо, найшвидший спосіб створити резервну копію між двома процесами до приблизно 10 процесів.

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

Бенджамін,

Я думаю, що вашу проблему можна вирішити в кількості файлів на рівні каталогу!

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

Ви також хотіли зберігати метадані файлової системи на окремому диску швидшого доступу? (Наприклад, на SSD).

Я б рекомендував стару добру реляційну базу даних.

Я б використовував PostgreSQL з, скажімо, 256 розділеними таблицями (cover_00, cover_01, ..., cover_ff) із зображеннями даних у вигляді bytea(двійкових) стовпців із зовнішнім сховищем, з ідентифікатором файлу як первинним ключем. Отримання зображення буде швидким (завдяки індексу на первинному ключі), гарантується цілісність даних (сумісна з ACID базами даних), резервне копіювання буде в порядку диска, тому не надто багато шукає.