Сегментування бази даних

1. Що це таке?
2. Для чого це все потрібно?
3. А як же...
4. ... виконати операцію, затрагівающію різні сегменти?
5. ... реалізувати все це?

У процесі читання мого блогу у вас напевно виникало питання: а що ж мається на увазі під фразою сегментування бази даних? Насправді це просто сподобався мені варіант перекладу терміна sharding (або він же - partitioning), в якості альтернатив можна було б використовувати партіціонірованіе, секціонування або що-небудь ще менш звучне, суть від цього не змінюється.

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

Що це таке?

Особливо в умовах Мережі дані накопичуються і запитуються з неймовірною швидкістю, рано чи пізно навіть самий потужний сервер перестане справлятися з завданням зберігання та надання даних. Кількість запитів в секунду, яке здатний забезпечувати один сервер обмежена нітрохи не менше, ніж його дисковий простір. Коли запити даних починають надходити занадто інтенсивно, найчастіше вдаються до найбільш тривіальним рішенням: реплицирования даних на кілька серверів і обробка запитів на читання даних паралельно, а записи - лише на одному, класична схема master-slave. Але і у такого підходу є межа, з ростом системи витрати обчислювальних потужностей на реплицирования даних рано чи пізно почнуть споживати більшу частину процесорного часу, що зробить приріст продуктивності від простого додавання в систему додаткових серверів мінімальним. Єдиним виходом з такої ситуації стає перегляд архітектури всієї системи зберігання даних, одним з можливих результатів якого і сожет стати сегментування бази даних.

Сама ідея сегментування проста: розбити всі дані на частини по будь-якою ознакою і зберігати кожну частину на окремому сервері або кластері, таку частину даних в сукупності з системою зберігання даних, в якій вона знаходиться, і називають сегментом або shard'ом.

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

Діапазон

Найпростіший і очевидний варіант, вибирається один з параметрів будь-якому записі, наприклад ідентифікаційний номер, і перевіряється його приналежність певного діапазону, наприклад всі записи з ID від 0 до 999 зберігаються на одному сервері, від 1000 до 1999 - на іншому, і так далі. Список Принцип залишається такою ж як і при використанні діапазонів, з тією лише різницею що перевіряється приналежність параметра будь-якого списку значень (який може складатися і з одного значення), а не діапазону, наприклад: людей можна розбити по районам проживання або їх імені. Хеш-функція Про засади роботи хешірующіх функцій я вже розповідав , Так що лише коротко опишу принцип такого підходу: для визначення в якому саме сегменті зберігається та чи інша запис, один з її заздалегідь відомих параметрів передається хешірующей функції, що повертає в якості результату номер сегмента від 0 до (n-1), де - n загальна кількість сегментів. Композиція При подальшому зростанні обсягів даних і навантаженні на систему можна дещо ускладнити її роботу, реалізувавши сегментування на основі композиції з декількох згаданих вище ознак.

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

Для чого це все потрібно?

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

Використання в якості системи зберігання даних для кожного сегмента кластера, а не просто одного сервера, може істотно підвищити надійність системи в разі програмних або апаратних збоїв. Тим більше в разі використання master-slave реплікації в рамках кожного сегмента, у системи в цілому все одно не буде єдиного сервера для обробки операцій записи дозволить мінімізувати витрати реплицирования даних.

А як же...

... перерозподіляти дані?

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

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

... виконати операцію, затрагівающію різні сегменти?

Коли всі дані зберігалися в одному місці - можна було б виконати один складнострукурованих запит і отримати всі потрібні дані, але при такому розподілі даних це не можливо. Для досягнення такого ж результату необхідно виконання декількох запитів до різних сегментів і аггрегаціі отриманих даних на програмному рівні.

... реалізувати все це?

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

• GridSQL від EnterpriseDB надає систему сегментування на базі PostgreSQL (Яку, до речі, не так давно під GPL опублікували);
• Багато реляційні системи управління базами даних, такі як MySQL і Oracle, мають власну вбудовану систему розбиття даних на партіціі;
• В рамках проекту Hibernate розробляється бібліотека, інкапсулюють сегментування даних;
• В статті про архітектуру LiveJournal я розповідав про спектр opensource-рішень від розробників цього проекту для подібних завдань.

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

Ще залишилися питання по темі?