7.6 KiB
7.6 KiB
| aliases | tags | date | zero-link | parents | linked | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
Тезисы
- Один из вариантов масштабирования.
- Данные разбиваются на части. Части размещаются на разных серверах.
- Не является репликацией и партиционированием.
- Шардирование последняя мера по улучшению производительности.
Шардирование — это метод разделения и распределения больших объёмов данных по разным базам данных или узлам в рамках одной распределённой системы, чтобы облегчить их управление, обеспечить масштабируемость и повысить производительность. Каждая часть данных, или "шард", функционирует как отдельная база данных, и все шарды вместе образуют логически единую базу данных.
Основные принципы шардирования включают в себя:
- Горизонтальное разделение данных: Вместо того чтобы хранить все данные в одной таблице или базе данных, они разделяются на меньшие части. Каждый шард содержит часть данных, например, пользователей с идентификаторами от 1 до 1000 в одном шарде и от 1001 до 2000 в другом.
- Распределение нагрузки: Поскольку запросы к данным могут обрабатываться параллельно разными шардами, это способствует балансировке нагрузки и увеличению производительности системы.
- Масштабируемость: По мере роста объёмов данных новые шарды могут быть добавлены в систему, что позволяет масштабировать приложение горизонтально.
- Локализация данных: Шардирование может быть использовано для локализации данных, чтобы уменьшить задержки, связанные с географическим расположением пользователей и баз данных.
Плюсы:
- Горизонтальное масштабирование
- Улучшение производительности: Единственный метод ускоряющий запись в БД.
- Высокая доступность и устойчивость к отказам: Отказ одного шарда не приводит к полному сбою системы. Данные в остальных шардах остаются доступными, что повышает общую устойчивость системы к отказам.
Минусы:
- Сложность управления: Нет стандартных механизмов по управлению шардами. В случае добавления или удаления шардов может потребоваться перераспределение больших объемов данных, что может быть ресурсоемкой операцией и повлиять на производительность системы.
- Трудности с транзакциями и согласованностью: Шардирование может затруднить обеспечение атомарности и согласованности транзакций, охватывающих несколько шардов, что может потребовать дополнительных усилий для поддержания целостности данных.
Проблемы
Стратегии разбиения на шарды
- Key Based Sharding. Наиболее распространенный способ.
- Range Base Sharding.
- Directory Based Sharding
Роутинг на шарды:
- Умный клиент. Приложение само решает в какой шард идти
- Нет дополнительной точки отказа. Нет лишнего хопа.
- Как обновлять при изменении количества шардов?
- Прокси
- Сервисы вообще не знают о шардинге
- Дополнительная точка отказа. Лишний хоп.
- Координатор
- Сервисы вообще не знают о шардинге.
- Дополнительная точка отказа. Лишний хоп.
- Не отдает сами данные, а указывает сервису в какой шард сходить.
Проблемы:
- Данные неравномерно распределились.
- Попробовать подобрать лучше ключ шардирования/кэш функцию
- Решардинг
- JOIN SQL
- Держать нужные данные на одном шарде
- Делать вычисления в одном сервисе
Решардинг
При добавлении/удалении ноды нужно провести решардинг. Перенести старые данные на новые узлы.
Лучше если количество нод будет равно степени 2. Формула shard_Id % count.
-
16 записей на 8 шардов -> 2 записи на шард
-
16 записей на 16 шардов -> 1 запись на шард
Заметки
- Как и в случае партиционирования запросы по ключу шардирования ускорятся.
- Запросы не по ключу пройдут по всем узлам.
- Запросы по диапазону ключей хэширования могут обойти все шарды.
- Можно создавать различные индексы на узлах. При этом может оказаться так, что индексы на исходной таблице могут не подойди для шардирования.
- В PostgreSQL есть шардирование из коробки, но оно реализовано на базе партиционирования. Фактически партиции уезжают на отдельные сервера. Решардинг это боль, так как должен выполняться вручную.