Бінарні (файлові) сховища страшна казка з похмурим кінцем



Данило Подільський (Git in Sky)
Доповідь мій називається «Бінарні, вони ж файлові сховища», але, насправді, ми маємо справу зі страшною казкою. Проблема в тому (і це теза моєї доповіді), що зараз не існує не те що гарною, а хоча б прийнятною системи зберігання файлів.

Що таке файл? Файл – це шматок даних з ім'ям. Що важливо? Чому файл – це не рядок у базі даних?

Файл занадто великий, щоб можна було звертатися з ним як з одним шматком. Чому? Є у вас сервіс, раз у нас HighLoad конференція, у вас сервіс, який тримає одночасно 100 тис. сполук. Це не так вже багато, якщо за кожним із з'єднань ми віддаємо файл в 1 Мбайт розміром, але нам потрібно приблизно 100 Гбайт пам'яті для буферів під ці файли.



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


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

Чому так? Чому ми формуємо наш масовий обмін даними на файловому обміні? Бо ще 10 років тому канали були повільними, ще 10 років тому ми не могли собі дозволити JSON інтерфейсів, ми не могли весь час запитувати сервер, у нас надто велика була latency, нам треба було всі дані, які потрібні для показу користувачеві, спочатку закачати, а потім вже надавати користувачеві можливість взаємодіяти з цими даними… Тому що інакше воно все так трішечки лагало.



Файлові сховища. Насправді термін «сховища» вкрай невдалий, тому що треба б їх називати «отдавалищами».

Ще 20-30 років тому це були дійсно сховища – ви обробляли дані, ви їх складали на стрічку, цю стрічку здавали в архів. Це і є сховища. Сьогодні це нікому не потрібно. Сьогодні, якщо у вас є 450 млн. файлів, це означає, що вони всі повинні бути в гарячій доступності. Якщо у вас є 20 Тбайт даних, це означає, що який-небудь 1 байт з цих 20-ти Тбайт, будь-який з них, обов'язково потрібно в самий найближчий час якого-небудь з ваших користувачів. Якщо тільки ви не працюєте в корпоративному середовищі, але якщо ви працюєте в корпоративному середовищі, слово HighLoad до корпоративних середовищ рідко застосовують.

У бізнес вимогах ніколи не написано «зберігати файли, навіть коли написано… Те, що називається системою резервного копіювання – ні, це не система резервного копіювання, це система аварійного відновлення, нікому не потрібно зберігати файли, всім потрібно читати файли – це важливо.

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



Файлові системи бувають старого типу і журналируемые. Що таке файловае система старого типу? Ми відписали на неї дані, вона більш-менш негайно відправила ці дані на диску у потрібне місце.

Що таке журналируемая файлова система? Це файлова система, яка пише дані на диск у два етапи: спочатку ми пишемо дані в спеціальну область диска, іменовану «журнал», а потім, коли у нас є вільний час, або коли журнал заповниться, перекладаємо з цього журналу дані туди, де вони повинні лежати на файловій системі. Це було придумано для того щоб прискорити старт. Ми знаємо, що у нас завжди файлова система консистентна, тому нам не треба перевіряти файлову систему, якщо у нас був невдалий аварійний рестарт, наприклад, сервера, а треба перевірити тільки невеликий журнал. Це буде важливо.

Файлові системи були плоскі й ієрархічні.

  • Плоска – це FAT12. Ви з нею, швидше за все, не зустрічалися. В ній не було директорій, відповідно, всі файлики лежали в кореневій директорії і були доступні відразу по зсуву в таблиці FAT.

  • Ієрархічні. Насправді, організувати директорії на файловій системі не так вже важко і на плоскій. Наприклад, в тому проекті, де ми зараз вирішуємо проблему, ми це зробили. Тим не менш, всі сучасні файлові системи, з якими ви стикалися – це ієрархічні файлові системи, починаючи з NTFS, закінчуючи якимось ZFS. Вони всі зберігають директорії, файли, в цих директоріях зберігається список вмісту цих директорій, відповідно, для того, щоб дістатися до файлу 10-го рівня вкладеності, вам потрібно по черзі відкрити 10 файлів, і 11-ий – той, котрий ваш. На диску SATA 100 IOPS'ів, ви можете з ним виконати 100 операцій у секунду, і 10 ви вже витратили, тобто файл 10-го рівня вкладеності, якщо всіх цих директорій немає в кеші, ви швидше ніж за 0,1 секунди не відкриєте, навіть якщо ваша система більше нічим не займається.
Всі сучасні файлові системи підтримують контроль доступу і розширені атрибути, крім FAT. FAT, як не дивно, до цих пір використовується і ніякого контролю доступу і ніяких додаткових атрибутів не підтримує. Чому це я сюди написав? Тому що це дуже важливий для мене момент. Страшна казка, пов'язана з файловими системами, почалася для мене в 1996 році, коли я уважно вивчив, як влаштований контроль доступу в традиційному UNIX'e. Ви пам'ятаєте про масці прав? Господар, група господаря, всі інші. У мене виникла задача, мені потрібно було створити групу, яка може читати і писати у файл групу, яка може читати файл, і всі інші не мали з цим файлом вміти робити нічого. І тут я зрозумів, що традиційна маска прав у UNIX'a не підтримує такий патерн.



Ще трохи теорії. POSIX – це фактичний стандарт, його підтримують зараз всі операційні системи, якими ми користуємося. В реальності – це просто список викликів, які файлова система повинна підтримувати. Для нас це важливо що? Open. Справа в тому, що робота з файлом у POSIX відбувається не по імені файлу, а по деякому файл-хэндлеру, який ви можете у файловій системи запросити по імені файлу. Після цього ви повинні для всіх операцій користуватися цим самим хэндлером. Операції можуть бути прості типу read, write і операції seek, яка робить неможливим створення розподіленої файлової системою стандарту POSIX.

Чому? Тому що seek – це випадкове переміщення у випадкову позицію файлу, тобто в реальності ми не знаємо, що ми читаємо, і ми не знаємо, куди ми пишемо. Для того щоб зрозуміти, що ми робимо, нам потрібно хендлер, який нам повернула операція open, і нам потрібно поточна позиція у файлі – це та сама друга адресація. Те, що файлова система POSIX підтримує випадкову другу адресацію, а не просто послідовну типу «відкрили і давайте читати файли від початку до кінця», або наприклад, «відкрили і давайте писати його, і кожен новий записуваний блок додається в кінець файлу». Те, що POSIX вимагає, щоб це не було так, не дозволяє (про це пізніше) створити хорошу розподілену POSIX файлову систему.

Що ще існує на файлових системах POSIX. Насправді, зовсім не всі POSIX підтримують однаковий набір атомарних операцій, але в будь-якому випадку, деяка кількість операцій повинні бути атомарними. Атомарна операція – це операція, яка відбувається або не відбувається за один раз. Нагадує чимось транзакції в базах даних, але насправді тільки нагадує. Наприклад, на файлової системи ext4, з якої ми всі повинні бути знайомі, раз ми зібралися на цій конференції, створення каталогу є атомарною операцією.



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

  • Стиснення онлайн – це коли ми при запису блоку його стискаємо. Підтримується, наприклад, на NTFS.

  • Шифрування. Теж підтримується на NTFS, а на ext4 не підтримується ні стиснення, ні шифрування, там організовано за допомогою блокових пристроїв, які підтримують і те і інше. Насправді, для нормального функціонування файлової системи не потрібно ні те, ні інше.

  • Дедупликация. Дуже важливий момент для сьогоднішніх файлових систем. Наприклад, у нас є проект, на якому 450 млн. файлів, але тільки 200 млн. чанків – це означає, що приблизно половина файлів однакова, просто називається по-різному.

  • Снэпшоты. Чому це важливо? Тому що у вас є файлова система розміром в 5 Тбайт – це означає, що консистентне її копія просто так бути не може. Хіба що ви зупинили всі свої процеси і запустили читання з файлової системи. 5 Тбайт будуть читатися з дешевого SATA диска десь 6 годин за моїми оцінками, ну, 5 – по Терабайту в годину. Можете зупинити свої сервіси на 5 годин? Немає, напевно. Тому, якщо вам потрібна, консистентне копія файлової системи, вам потрібні снэпшоты.

    На сьогоднішній день снэпшоты підтримуються на рівні блокових пристроїв в LVM, і там вони підтримуються огидно. Дивіться, ми створюємо LVM снепшот, і наше лінійне читання перетворюється на випадкове, тому що ми повинні почитати в снэпшоте, почитати на базовому блочному пристрої. Із записом все ще гірше – ми повинні почитати на базовому томе, ми повинні відписати в снэпшоты, ми повинні знову прочитати з снэпшота. В реальності снэпшоты на LVM марні.

    На ZFS є хороші снэпшоты, їх там може бути багато, їх можна передавати по мережі, якщо ви, наприклад, зробили копію файлової системи, то ви можете передати снепшот. Загалом, снепшот не обов'язковий для файлового сховища функціонал, але дуже корисний, а трохи пізніше з'ясуватися, що обов'язковий.
Саме останнє, але може бути найважливіше у всій цій теорії.

Кешування читання. Колись, коли інсталятор NT4 запускався з під MS DOS, інсталяція NT4 без запущеного смартдрайва (це кеш читання в MS DOS) займала 6 годин, а з запущеним смартдрайвом – 40 хвилин. Чому? Тому що, якщо ми не кешуємо в пам'яті вміст директорій, ми змушені щоразу робити ось ті самі 10 кроків.

Кешування запису. Насправді, ще до недавнього часу вважалося, що це дуже поганий тон, що єдиний випадок, коли ви можете включити кешування запису на пристрої – це якщо у вас є трейдконтроллер з батарейкою. Чому? Тому що ця батарея дозволяє зберегти в пам'яті дані, що не потрапили на сервер, выключившийся у випадковий момент. Коли сервер буде включений, можна дописати ці дані на диск.

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

Це все було про файлові системи, локальні для вашого комп'ютера.



High Load – це мережа. Це мережа і в тому сенсі, що до вас приходять з мережі відвідувачі, і це означає, що вам потрібно горизонтальне масштабування. Відповідно, мережеві протоколи доступу до файлів діляться на дві групи: stateless – це NFS, WebDAV і ще деяку кількість протоколів.

Stateless – це означає, що кожна наступна операція самостійна у тому сенсі, що її результат не залежить від результату попередньої. З файловою системою стандарту POSIX це не так. У нас результати read'a і write'a залежать від результатів seek'a, а він, у свою чергу, від результатів open'a. Тим не менш, поверх POSIX файлових систем існують stateless протоколи передачі NFS, наприклад, і це його головна проблема. Чому NFS таке лайно? Тому що він stateless поверх statefull.

Statefull. Сьогодні все частіше використовуються statefull протоколи в мережевому обміні. Це дуже погано. Statefull протокол для інтернету дуже погано підходить, тому що у нас непередбачувані затримки, але, тим не менше, все частіше який-небудь JSON javascript'ний інтерфейс все частіше пам'ятає про те, чим закінчилося попереднє його спілкування з сервером, і замовляє черговий JSON, грунтуючись на тому, чим закінчилася попередня операція. З мережевих файлових систем з statefull протоколом треба відзначити CIFS вона ж samba.

Лукава сука відмовостійкість. Справа в тому, що традиційні файлові системи наголошують на цілісність даних, тому що їх творці були заворожені словом «сховище». Вони думали, що найважливіше в даних – це зберігати й захищати. Сьогодні ми знаємо, що це не так. Ми слухали на RootConf'е доповідь людини, яка займається захистом даних в датацентрах, він твердо сказав нам, що вони відмовляються не тільки від хардварних дискових масивів, але і від софтварных дискових масивів. Вони використовують кожен диск окремо і якусь систему, яка стежить за розташуванням даних на цих дисках, за реплікацією цих даних. Чому? Тому що, якщо у вас є дисковий масив з, наприклад, п'яти 4-х Тбайтных дисків, то він містить 20 Тбайт. Для того щоб після випадкового збою, наприклад, один з дисків вилетів, його треба відновити, в реальності треба прочитати всі 16 Тбайт. 16 Тбайт читаються по Тбайту в годину. Тобто у нас вилетів всього один диск, але для того, щоб знову запустити масив в роботу нам потрібно 16 годин – це неприйнятно в сьогоднішній ситуації.

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

Що ще важливо сказати про мережеві бінарні сховища? Та сама CAP-теорема, тобто вибираєте будь-які два з цих трьох:

  1. у вас дані будуть завжди консистентны і завжди доступні, але тоді вони будуть лежати на одному сервері;
  2. у вас дані будуть завжди консистентны і вони будуть розподілені між кількома серверами, але виявиться, що доступ до них час від часу обмежений;
  3. у вас дані будуть завжди доступні і розподілені між серверами, але тоді те, що ви з одного сервера і з іншого прочитаєте одне і те ж вам абсолютно не гарантується.
CAP-теорема – це всього-навсього теорема, її ніхто не довів, але по факту це дійсно так. Не вдається. Спроби робляться постійно, наприклад, OCFS2 (Oracle Cluster Filesystem версії 2), про яку я згадаю трохи пізніше, – це спроба довести нікчемність CAP-теореми.

Це все про файлові системи. Про бінарні сховища, в чому проблема? Давайте розберемося.

Найпростіший спосіб, який приходить в голову кожному системного адміністратора, якому треба зберігати Тбайты даних і мільйони файлів – це просто купити велику СГД (система зберігання даних).



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

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

Коли мені в перший раз потрапив в руки DRBD, я подумав: ось відмінно, у мене буде два сервера, між ними буде реплікація, заснована на DRBD, і в мене будуть сервера, які будуть читати з одного, і з іншого. Дуже швидко з'ясувалося, що всі сервера кешують читання – це значить, що навіть якщо ми щось нишком змінили на блоковому пристрої, комп'ютер, який сам цього не змінював і знав, який кеш инвалидировать, ні за що про це не дізнається, і буде продовжувати читати дані зовсім не з тих місць, де вони насправді вже лежать.

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

Ще з цим OCFS2 є така проблема – гальма при конкурентній запису. Пам'ятаєте, ми говорили про атомарні операції – це операції, які атомарны, які одним шматком відбуваються. У випадку з розподіленої файлової системою, навіть якщо всі наші дані лежать на одній єдиній великій СГД, атомарна операція по набору читачів і письменників вимагає, щоб вони всі прийшли до консенсусу.

Консенсус в мережі – це мережеві затримки, тобто реально писати на OCFS2 – це біль. Насправді, Oracle – не такий ідіот, вони зробили непогану файлову систему, просто вони зробили її під зовсім іншу задачу. Вони її зробили під расшаріваніє одних і тих же файлів бази даних між кількома своїми серверами Oracle. У файлів бази даних Oracle такий патерн роботи, що вони чудово на цій OCFS2 працюють. Для файлового сховища вона виявилася непридатна, ми пробували ще в 2008 році. Ще з OCFS2 виявилося неприємно, що через таймджитеринга, тобто з-за того, що час трішки різниться на всіх виртуалках, які у нас запущені навіть на одному хості, у нас нормально не працює OCFS2, тобто в якийсь момент обов'язково трапляється, що час на цьому сервері забезпечення консистентности пішло назад, він на цьому місці падає і т. д. І чому так повільно, я вже пояснив.

А ще велику-превелику СГД досить складно буде отримати у власне користування, тобто наприклад, в Хеснере ніякої великої СГД вам не дадуть. Є в мене така підозра, що ідея, що велика СГД – це дуже надійно, дуже добре, дуже високопродуктивно, пов'язана просто з правильним розрахунком потрібних ресурсів. Ви ж не можете просто так купити велику СГД, їх не продають в магазині. Ви повинні піти до авторизованого вендеру і поговорити з ним. Він покиває головою, скаже: «It will cost you». І порахує вам тисяч на 50-100 одне шасі, тобто ще його треба буде набити дисками, але він вважатиме правильно. Завантажено це СГД буде відсотків на 5-10, а якщо виявиться, що ваша навантаження зросла, вони порадять поставити вам ще одну таку. Це про життя.

Гаразд, нехай. Велика СГД – це не вихід, це ми з'ясували потім і кров'ю.



Беремо якусь кластерну файлову систему. Ми спробували кілька: CEPH/Lustre/LeoFS.

По-перше, чому так повільно? Зрозуміло чому – тому що синхронні операції по всьому кластеру. Що значить «ребалансинг»? На HDFS немає автоматичного ребалансинга для вже лежать на них даних. Чому її там немає? Тому що в той момент, коли на CEF'е трапляється ребалансинг, ми втрачаємо можливість з ним працювати. Ребалансинг – це добре налагоджена процедура, яка поїдає приблизно 100% смуги дискового обміну. Тобто диск сатурейшн – 100%. Іноді ребалансинг, він же на кожен чих його робить, триває 10 годин, тобто перше, що роблять люди, що працюють з CEF'ом – це навчаються прикручувати інтенсивність ребалансинга.

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

Чому ребалансинг такий? Чому він трапляється на кожен чих? Всі ці «чому» у мене залишилися без відповіді досі.

І та сама проблема – атомарні операції, які повинні пройти по всьому кластеру синхронно. До тих пір, поки у вас в кластері дві машини, у вас все в порядку, коли у вас в кластері 40 машин, ви виявляєте, що всі ці 40 машин… Ми маємо 402– кількість мережевих пакетів, які ми повинні послати. Протоколи ребалансинга і протоколи забезпечення консистентности намагаються з цим боротися, але поки не дуже успішно. Поки в цьому сенсі системи з єдиної точки відмови з неймнодой трошки лідирують, але теж не дуже сильно.



Чому не можна просто скласти всі файли в базу? З моєї точки зору, саме так і треба вчинити, тому що якщо у нас лежать файли в базі, у нас є великий пакет хороших засобів роботи з такими речами. Ми вміємо працювати з базами і в мільярд рядків, і на петабайты, ми вміємо працювати з базами і на кілька мільярдів рядків, на кілька десятків петабайт, це у нас все добре виходить. Хочете, візьміть Oracle, хочете – візьміть який-небудь DB2, хочете – візьміть який-небудь NoSQL. Чому? Тому що файл – це файл. З файлом неможливо звертатися як з атомарною сутністю, тому розподілені файлові системи існують погано, а розподілені бази даних існують нормально.



А ще хрест на всяких ACFS, Lustre'ах та ін. ставить те, що нам потрібно резервне копіювання файлів. Як ви собі уявляєте резервне копіювання 20 Тбайт? Нагадую, Тбайт в годину. І головне – куди, як часто, як забезпечити консистентним на такій кількості, якщо у нас не єдина файлова система, і ми не можемо зняти снепшот. Єдиний вихід, який я особисто бачу з цієї ситуації – це файлові системи з версионированием, коли ви пишете новий файл, і старий нікуди не пропадає і можна до нього дістатися, вказавши час, на яке ви ходите подивитися стан файлової системи. Ще має бути якась збірка сміття.

Microsoft обіцяв нам таку файлову систему ще в 90-х, але так і видав. Так, була розподілена файлова система для Windows, вони її навіть анонсували для Longhorn, але потім не сталося ні Longhorn'а, ні цієї файлової системи.

Чому резервне копіювання – це важливо? Резервне копіювання – це не відмовостійкість – це захист від помилок оператора. Мені самому траплялося переплутати source і destination в команді rsing і отримати (чарівна історія!) сервер, на якому працює 16 виртуалок, але файлів з їх образами немає, тому що я їх видалив. Довелося їх виймати з допомогою команди DD із самих виртуалок. Тоді обійшлося. Але, тим не менш, ми зобов'язані в наших бінарних сховищах забезпечити версіонування, і ніякої файлової системи, яка нормально б забезпечувала версіонування, крім ZFS, яка при цьому не кластерна і, відповідно, нам не підходить, немає на світі.

Що ж робити? Для початку, вивчати власну задачу.

  • Треба економити? Якщо ви здатні покласти всі файли на одну свою СГД і обробити їх на одному надпотужну сервері. Зараз же можна сервера і з 2 Тбайтами пам'яті поиметь і з кількома сотнями ядер. Якщо у вас вистачає бюджету на це все, і вам потрібно файлове сховище, зробіть так. Це може обійтися всього бізнесу дешевше.

  • POSIX. Якщо вам не потрібно випадкове читання або випадковий запис, то це великий плюс вас, ви можете впоратися з наявним набором, наприклад, HDFS, згадуваний раніше або CFS або Lustre. Lustre – прекрасна файлова система для обчислювального кластера, а от для віддає кластера нікуди не годиться.

  • Великі файли – чи потрібні вони? Якщо всі ваші файли можуть вважатися маленькими (маленькі – це, я нагадаю, ситуація, а не властивість файлу), якщо ви можете дозволити собі поводитися з файлом як з єдиним шматком даних, у вас немає проблем – кладіть його в базу – все у вас добре. Чому на тому проекті, який я тут згадую, але не називаю, у нас все вийшло? Тому що там 95% файлів менше 64 Кбайт, відповідно, це завжди один рядок у базі, і в цій ситуації все працює чудово.

  • Версіонування – чи потрібно? Насправді, є ситуації, коли версіонування не потрібно, але тоді не потрібно і резервне копіювання, ці ситуації, коли всі ваші дані сгенерены вашими роботами. Фактично ваше файлове сховище являє собою кеш. Тут немає місця для помилки оператора і нічого втратити.

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

  • Збираємося ми видаляти файли? Як не дивно, це важливо. Є така байка (насправді, це не байка), що ВКонтакте ніколи нічого не видаляє, тобто як тільки ви завантажили туди якусь картинку або якусь музичку, вона лежить там завжди, видаляються посилання на цю інформацію, ніякого рекуперейшн, тобто перевикористання для місця, зайнятого файлами, в тому ж ВКонтакте немає. Кажуть, я слухав таку доповідь. Чому? Тому що як тільки ви намагаєтеся переиспользовать місце, у вас негайно виникають серйозні проблеми з консистентностью. Чому OCFS2 підійшла під Oracle бази даних? Тому що вони не переиспользуют місце, тому що, коли ви пишете нові дані в базу, вони просто додаються в кінець файлу і все. Якщо ви хочете переиспользовать місце, ви запускаєте компакт, я не знаю, чи це в сучасному Oracle, але це було так у 2001-му році. Ви запускаєте компакт – це оффлайн операція, вона забезпечує консистентним тим, що вона монопольно володіє тим файлом, який обробляє. Збираємося ми переиспользовать дисковий простір? Ось той же ВКонтакте тикає нові диски і нормально, і я вважаю, що так і треба.

  • Який буде профіль навантаження? Читання, запис. У багатьох розподілених файлових систем дуже сильно просідає продуктивність саме на записи, чому? Тому що забезпечення консистентности, тому що атомарні операції, тому що синхронні операції по всьому кластеру. У NoSQL баз синхронні операції по кластеру всього одна. Зазвичай инкриментация версії запису. Даних може не лежати, вони можуть приїхати потім, але версію конкретної записи, всі ноди, про неї всі повинні думати одне і те ж. І це не так для всіх NoSLQ, наприклад, Cassandra цим не переймається, у Cassandra немає синхронних операцій по всьому кластеру. Якщо ви читаєте, спробуйте котрусь із кластерних файлових систем, можливо, у вас все вийде з неї. Ось ці історії успіху, коли підходять люди і кажуть: «Навіщо ви все це зробили, візьміть просто Lustre». Так, у вашій ситуації Lustre працювала, а в нашій – не дуже.
Для деяких сполучень вимог, для деяких задач, рішення є прям ось існуюче, а для деяких сполучень – ні, і його дійсно немає. Якщо ви пошукали і не знайшли – це означає, що його немає.

Що ж все-таки робити? Ось те, з чого варто почати:

  • можна ходити і випрошувати ці 200 тис. євро до начальства пару місяців і, коли їх все-таки дадуть, зробити добре. Тільки не клянчити 200 тис., а спочатку сходити до вендеру і порахувати з ним, скільки треба клянчити, а потім клянчити приблизно в півтора рази більше;

  • все-таки скласти всі файли в базу – я пішов по цьому шляху. Ми наші 450 млн. файлів склали в базу, але цей фокус вдався нам, тому що нам не потрібно ніякої POSIX і у нас 95% файлів маленькі;

  • можна написати свою файлову систему. Зрештою, різноманітні алгоритми існують, ось ми нашу написали поверх NoSQL бази, ви можете взяти що-небудь ще. Першу версію нашу ми написали поверх РСУБД Postgresql, але тут у нас виникли деякі проблеми, не відразу, а через 2 роки, але тим не менш. Насправді це не дуже складно, навіть POSIX файлову систему написати не дуже складно, берете FUSE і вперед, там не так багато викликів, їх все можна реалізувати. Але в реальності добре працюючу файлову систему написати все-таки виходить складно.
Ця доповідь — розшифровка одного з кращих виступів на навчальній конференції розробників високонавантажених систем HighLoad++ Junior. Зараз ми активно готуємо дорослого братика — конференцію 2016 року — у цьому році HighLoad++ пройде в Сколково, 7 і 8 листопада.

В цьому році багато цікавого по темі сховищ даних, ось самі спірні і зубодробильні доповіді:



Також деякі з цих матеріалів використовуються нами в навчальному онлайн-курс по розробці високонавантажених систем HighLoad.Guide — це ланцюжок спеціально підібраних листів, статей, матеріалів, відео. Вже зараз у нашому підручнику понад 30 унікальних матеріалів. Підключайтеся!

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.