Поради щодо ефективного зберігання 25 мільйонів файлів на мільйон файлів у файловій системі


11

Скажімо, ви стикаєтесь з нетисненими файлами журналів, вартістю 25 ТБ, і у вас є у розпорядженні масив із 20 товарних коробок з колективною вільною пам’яттю 25 ТБ.

Як би ви їх зберігали ?.

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

б) Який формат / алгоритм стиснення / декомпресії?

в) Розмір файлу журналу становить від 1 МБ до макс. 7 МБ всього тексту та багато пробілів

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

д) Операційна система, що працює на товарних коробках, є Linux,

f) Що стосується резервного копіювання, то у нас є масив пам’яті, який піклується про це. Отже, можливість відновлення даних з масиву існує.

Я не хочу, щоб вони безпосередньо отримували доступ до файлової системи. Що я повинен зробити ? Як отримати для них API на основі REST?

Будь ласка, заощадите 2 центи, а що б ви зробили?

Анкур


В яких операційних системах працюють товарні коробки? Чи потрібна толерантність до помилок або якщо ви втрачаєте всі дані, що зберігаються в одному ящику, це гаразд?
Марк Хендерсон

@farseeker відредагував це запитання, щоб відповісти на ваші запитання. Спасибі
Анкур Гупта

Просто перечитайте питання, і перше запитання, яке я запитав би, таке: де зараз зберігаються 25 ТБ файлів журналів, і чи можуть вони залишитися там?
Марк Хендерсон

@farseeker у файловій системі NFS
Ankur Gupta

Відповіді:


7

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

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

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

Редагувати: Я все ще новачок у ZFS та налаштовую iSCSI, але нагадав побачити відео з Sun у Німеччині, де вони демонстрували відмову від ZFS. Вони підключили три комп'ютери USB до комп'ютера і поставили чотири флешки у кожен концентратор. Потім, щоб жоден концентратор не міг знімати пул пам’яті, вони створили об'єм RAIDz, що складається з однієї флешки з кожного концентратора. Потім вони знімають разом чотири томи ZFS RAIDz. Таким чином, для паритету використовувались лише чотири флешки. Далі, звичайно, відключений один концентратор, що деградувало кожен zpool, але всі дані були доступні. У цій конфігурації можна втратити до чотирьох накопичувачів, але лише у тому випадку, якщо якісь два накопичувачі не були б в одному пулі.

Якщо ця конфігурація використовувалася з необробленим диском кожного поля, то це дозволило б зберегти більше дисків для даних, а не для паритету. Я чув, що FreeNAS може (або збирався змогти) ділитися накопичувачами в "сирому" режимі через iSCSI, тому я припускаю, що Linux може зробити те саме. Як я вже говорив, я все ще вчуся, але цей альтернативний метод був би менш марнотратним з точки зору паритету приводу, ніж моя попередня пропозиція. Звичайно, він покладався б на використання ZFS, який я не знаю, чи був би прийнятним. Я знаю, що зазвичай краще дотримуватися того, що ви знаєте, якщо вам доведеться щось будувати / підтримувати / ремонтувати, якщо тільки це не є досвідом навчання.

Сподіваюся, що це краще.

Редагувати: Якось копав і знайшов відео, про яке говорив. Частина, де вони пояснюють розповсюдження флеш-пам’яті USB через концентратори, починається з 2м10с. Відео - це демонстрація їх сервера зберігання даних "Thumper" (X4500) та способи розповсюдження дисків по контролерам, тому якщо у вас відмова контролера жорсткого диска, ваші дані все ще будуть хорошими. (Особисто я вважаю, що це просто відео з видовищами, які розважаються. Мені б хотілося, щоб я мав ящик Thumper сам, але моїй дружині не сподобалося б, щоб я перебирав під'їзд піддону через будинок.: D Це одна велика коробка.)

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


4

По-перше, файли журналу можна стискати в дуже високих співвідношеннях. Я вважаю, що мої файли журналів стискаються у співвідношенні 10: 1. Якщо вони стискаються навіть до співвідношення 5: 1, це лише 5 Гб, або 20% вашої ємності.

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

  • Використовуйте zip-файли, якщо користувачі Windows отримають доступ до файлів безпосередньо.
  • Використовуйте gzip, якщо до них можна отримати доступ через Linux, і важлива швидка декомпресія.
  • Використовуйте bzip2, якщо до них можна отримати доступ через Linux, і важливо мати найменші файли.

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

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

Якщо ви не можете створити єдиний файловий сервер для цих файлів, ви можете виявити, що вам потрібна розподілена файлова система. У Windows є розподілена файлова система (DFS), яка може відповідати вашим потребам.

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


FYI: Windows DFS - це спосіб синхронізувати файли / папки на декількох серверах. Це не дозволить використовувати накопичувач на кількох серверах як єдиний накопичувач. microsoft.com/windowsserversystem/dfs/default.mspx
Scott McClenning

Подумавши про це, ти маєш рацію; DFS може бути використаний, якщо ви маєте кореневу точку DFS до папок, що живуть на інших машинах. Таким чином, користувач побачив би одну структуру файлів, і не потрібно було б знати, на яких машинах фактично працюють дані, DFS знає. Це спрацювало б. Зазвичай, коли у мене люди запитують мене про Windows DFS, вони зазвичай думають, що це спосіб об'єднати місця для зберігання, і тому я просто до цього висновку. Вибачте і ваше право, яке могло працювати.
Скотт Маккленінг

2

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


2

експортуйте ці папки через NFS

встановити їх на одній машині з апашею, що працює (під корінь документа), як дерево

використовуйте zip для їх стиснення - гарне співвідношення стиснення, блискавку можна відкрити з усіх ОС

список файлів в Apache - так що ви надаєте користувачам доступ лише для читання (файли журналу не дозволяють редагувати, правда)


1
Погодьтеся на nfs + httpd, не погоджуйтесь на zip. gzip краще взаємодіє з http.
Тобу

+1 для коментаря gzip від @Tobu - При правильній конфігурації Apache може подавати файли gzip'ed у веб-браузер, який прозоро розпакує та відобразить їх. Користувачам навіть не потрібно знати про стиснення.
Крістофер Кашелл

0

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


0

@Ankur і @Porch. Я повністю погоджуюся з необхідністю стиснення цих колод.

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

Моя думка - розділіть журнали на 2 групи - папки "старі" та "нові".

Об’єднайте їх у корінь документа httpd. Використовуйте сильну компресію для старих (архіви xz або 7z, популярні для всіх ОС) з великими розмірами словника та блоку, можуть бути навіть суцільними архівами.

Використовуйте стиснення fs для нових: lessfs (rw, дедупликація + способи легкого стиснення), fusecompress 0,9.x (rw, методи легкого до сильного стиснення), btrfs / zfs, squashfs (ro, легкі до сильних методів стиснення, деякі зменшення, використання для щойно обернутих колод).

Ви навіть можете прозоро писати журнали в стиснуті fs (fusecompress, lessfs, btrfs / zfs). Забезпечити R / O доступ httpd до записів журналів. Вони будуть прозорими для користувачів і прозоро декомпресованими для них.

Попередження про запобіжник: 1) використовувати лише 0,9.x - це стабільно. Клон звідси https://github.com/hexxellor/fusecompress

Пізніші версії або не підтримують lzma добре, або втрачають дані.

2) для стискання одного файлу він використовує лише 1 ядро ​​процесора, тому може бути повільним.

Повторно натисніть кожен журнал у папці «нова», старший певного часу (кілька місяців) та перейдіть до «старого»

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