Масштабування системи стає все більш важливим у сучасному світі даних. Кожен додаток, який працює з великою кількістю даних, з часом стикається з проблемами продуктивності, такими як високий час відповіді або перевантаження серверів. Ось тут на допомогу приходить концепція шардингу — розподілу даних по кількох серверах для зменшення навантаження.
Шардинг — це процес поділу великих баз даних на менші, швидші й легші для керування частини, які називаються шарами. Наприклад, якщо у вас є таблиця користувачів з 1 мільярдом записів, ви можете поділити її на 10 шардів, кожен з яких містить 100 мільйонів користувачів. Кожен з цих шардів працює незалежно, що дає можливість паралельно обробляти запити й зменшити час очікування.
Проблеми монолітних баз даних
Монолітні бази даних мають кілька серйозних обмежень:
- Висока затримка запитів, коли система не встигає обробляти все вчасно.
- Конкуренція за доступ до записів — коли кілька запитів намагаються змінити одні й ті самі дані одночасно.
- Насичення операцій з диском (Disk I/O saturation), коли система не справляється з обсягом даних.
- Єдина точка відмови, що може призвести до повного збої у разі проблеми на сервері.
Завдяки шардингу ці проблеми значно зменшуються. Розподілення даних на кілька серверів дозволяє забезпечити горизонтальну масштабованість, покращити продуктивність, зменшити простої, а також забезпечити кращу ізоляцію від помилок.
Основні поняття шардингу
- Шарди — це горизонтальне поділення даних.
- Ключ для шардингу — це поле, яке визначає, в якому шарді зберігатиметься конкретний запис.
- Мапа шардів — таблиця, яка відстежує, де знаходяться дані.
- Перекластеризація — переміщення даних між шарами для рівномірного розподілу навантаження.
- Реплікація — створення копій даних для забезпечення відмовостійкості.
Типи шардингу
- Горизонтальний шардинг — дані діляться за рядками, наприклад, на основі значення
user_id % 4. - Вертикальний шардинг — дані діляться за таблицями або стовпцями (наприклад, таблиця користувачів може бути в одній базі, а транзакції — в іншій).
- Шардинг на основі каталогу — використовується служба пошуку для визначення, де зберігаються дані.
Коли слід використовувати шардинг?
Шардинг рекомендується, коли кількість записів у базі даних перевищує 100 мільйонів. Для менших обсягів даних шардинг може бути зайвим, адже він вимагає складнішої архітектури. Якщо ваше застосування працює з великими обсягами даних або має високі вимоги до швидкості доступу, шардинг буде корисним.
Проектування стратегії шардингу
- Вибір ключа для шардингу: важливо вибирати рівномірно розподілені ключі, такі як
user_id, які будуть часто використовуватися у запитах. - Стратегії мапування:
- Модульне мапування:
user_id % N - Хешування:
hash(user_id) - Діапазонне мапування: для числових діапазонів
- Географічне мапування: на основі
country_code
- Модульне мапування:
Практичний приклад: шардинг з MySQL
У цьому прикладі ми створюємо три шардовані бази даних:
1. shard_1 для user_id % 3 == 0
2. shard_2 для user_id % 3 == 1
3. shard_3 для user_id % 3 == 2
Ці бази даних створюються в MySQL, і запити до даних будуть маршрутизуватися до відповідних шардів за допомогою додаткового програми-маршрутизатора.
Виклики та підводні камені
- Об’єднання між шарами: важко виконувати запити, що з’єднують дані з кількох шардів, без додаткових складних рішень.
- Транзакції між шарами: двофазне підтвердження транзакцій (2PC) складне й дороговартісне.
- "Гарячі" шардінги: якщо ключ шардінгу вибрано погано, вся навантаження може потрапити на один шард.
Шардинг у реальних системах
- Facebook використовує шардовану MySQL для обробки великих даних за
user_idі для зберігання медіа використовує Haystack. - Twitter перейшов від монолітної MySQL до шардованої архітектури та використовує Snowflake для генерації ID.
- MongoDB має вбудований шардинг, що спрощує управління даними.
Кращі практики
- Вибирайте ключі для шардінгу обачно, щоб уникнути нерівномірного навантаження.
- Використовуйте абстракційні шари для приховування складності архітектури.
- Автоматизуйте перекластеризацію для обробки росту даних.
- Регулярно моніторте стан шардів, щоб запобігти збоїв.
Висновок
Шардинг — це не тільки для великих компаній. Якщо ви створюєте масштабований веб-додаток або працюєте з API з високою пропускною здатністю, або є адміністратором баз даних, шардинг є важливим поняттям, яке ви повинні глибоко розуміти. Використовуючи MySQL, хоча цей процес не має вбудованого механізму шардингу, його можна реалізувати вручну, отримуючи глибоке розуміння та контроль над системою.
Поширені запитання
- Чи можна реалізувати шардинг без коду? Так, але для цього знадобляться інструменти, такі як Vitess або ProxySQL.
- Скільки шардів потрібно на початок? Починайте з 2–3, з проектуванням для легкого розширення.
- Чи можна використовувати UUID як ключ шардінгу? Краще уникати цього, оскільки UUID не забезпечує рівномірний розподіл.
Цей практичний підхід дає вам чудове розуміння та досвід у створенні та масштабуванні реальних систем.
Перекладено з: Understanding Sharding: Concepts and Hands-On with MySQL