upagge/digital-garden
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
93bbce6f77
digital-garden/_inbox/Шардирование в БД.md

8.0 KiB
Raw Blame History

aliases tags date zero-link parents linked
Шардинг
зрелость/🌱
2024-03-12
00 HighLoad
00 Базы Данных
Партиционирование в БД

Тезисы

  • Один из вариантов горизонтального масштабирования.
  • Данные разбиваются на части. В отличии от партиционирования эти части размещаются на разных серверах.
  • Не является репликацией и партиционированием. Но на каждом шарде можно применить партицирование.
  • ==Шардирование последняя мера по улучшению производительности.==

Шардирование — это метод разделения и распределения больших объёмов данных по разным базам данных или узлам в рамках одной распределённой системы, чтобы облегчить их управление, обеспечить масштабируемость и повысить производительность. Каждая часть данных, или "шард", функционирует как отдельная база данных, и все шарды вместе образуют логически единую базу данных.

Основные принципы шардирования включают в себя:

  • Горизонтальное разделение данных: Вместо того чтобы хранить все данные в одной таблице или базе данных, они разделяются на меньшие части. Каждый шард содержит часть данных, например, пользователей с идентификаторами от 1 до 1000 в одном шарде и от 1001 до 2000 в другом.
  • Распределение нагрузки: Поскольку запросы к данным могут обрабатываться параллельно разными шардами, это способствует балансировке нагрузки и увеличению производительности системы.
  • Масштабируемость: По мере роста объёмов данных новые шарды могут быть добавлены в систему, что позволяет масштабировать приложение горизонтально.
  • Локализация данных: Шардирование может быть использовано для локализации данных, чтобы уменьшить задержки, связанные с географическим расположением пользователей и баз данных.

Плюсы:

  • Горизонтальное масштабирование
  • Улучшение производительности: Единственный способ операции вставки в БД.
  • Высокая доступность и устойчивость к отказам: Отказ одного шарда не приводит к полному сбою системы. Данные в остальных шардах остаются доступными, что повышает общую устойчивость системы к отказам.

Минусы

  • Сложность управления: Нет стандартных механизмов по управлению шардами. В случае добавления или удаления шардов может потребоваться перераспределение больших объемов данных, что может быть ресурсоемкой операцией и повлиять на производительность системы.
  • Трудности с транзакциями и согласованностью: Шардирование может затруднить обеспечение атомарности и согласованности транзакций, охватывающих несколько шардов, что может потребовать дополнительных усилий для поддержания целостности данных.

Проблемы:

  • Решардинг
  • Согласованное префиксное чтение
  • При запросе SELECT FROM данные могут отдаться сначала все с одного шарда, потом с другого и так далее.
  • Запросы не по ключу пройдут по всем узлам.
  • Запросы по диапазону ключей хэширования могут обойти все шарды.
  • Данные неравномерно распределились.
    • Попробовать подобрать лучше ключ шардирования/кэш функцию
    • Решардинг
  • JOIN SQL
    • Держать нужные данные на одном шарде
    • Делать вычисления в одном сервисе

Обычно для распределения по шардам ввыбирается какой-то признак. Наиболее популярные стратегии распределения данных по шардам:

Как направлять на шарды:

  • Умный клиент. Приложение само решает в какой шард идти
    • Нет дополнительной точки отказа. Нет лишнего хопа.
    • Как обновлять при изменении количества шардов?
  • Прокси
    • Сервисы вообще не знают о шардинге
    • Дополнительная точка отказа. Лишний хоп.
  • Координатор
    • Сервисы вообще не знают о шардинге.
    • Дополнительная точка отказа. Лишний хоп.
    • Не отдает сами данные, а указывает сервису в какой шард сходить.

Реализации в СУБД:

Заметки

  • Как и в случае партиционирования запросы по ключу шардирования ускорятся.
  • Можно создавать различные индексы на узлах. При этом может оказаться так, что индексы на исходной таблице могут не подойди для шардирования.
  • В 2GIS при переезде на шардирование они создавали шарды, после чего обвешавали основную БД тригерами, чтобы они актуализировали данные в шарда, но при этом продолжали использовать старую БД. В какой-то момент переключились на шарды.