digital-garden/_inbox/Шардирование в БД.md

80 lines
7.6 KiB
Markdown
Raw Normal View History

2024-06-13 21:01:37 +03:00
---
aliases:
- Шардинг
tags:
- зрелость/🌱
date:
- - 2024-03-12
zero-link:
- "[[00 HighLoad]]"
2024-06-20 21:44:23 +03:00
- "[[00 Базы Данных]]"
2024-06-13 21:01:37 +03:00
parents:
linked:
2024-06-20 21:54:23 +03:00
- "[[Партиционирование в БД]]"
2024-06-13 21:01:37 +03:00
---
2024-06-20 21:54:23 +03:00
## Тезисы
2024-06-20 22:04:23 +03:00
- Один из вариантов масштабирования.
2024-06-20 21:54:23 +03:00
- Данные разбиваются на части. Части размещаются на разных серверах.
2024-06-20 22:04:23 +03:00
- Не является [репликацией](_inbox/Репликация.md) и [партиционированием](Партиционирование%20в%20БД.md).
- Шардирование последняя мера по улучшению производительности.
2024-06-20 21:54:23 +03:00
***
2024-06-13 21:01:37 +03:00
Шардирование — это метод разделения и распределения больших объёмов данных по разным базам данных или узлам в рамках одной распределённой системы, чтобы облегчить их управление, обеспечить масштабируемость и повысить производительность. Каждая часть данных, или "шард", функционирует как отдельная база данных, и все шарды вместе образуют логически единую базу данных.
Основные принципы шардирования включают в себя:
2024-06-20 21:59:23 +03:00
- **Горизонтальное разделение данных**: Вместо того чтобы хранить все данные в одной таблице или базе данных, они разделяются на меньшие части. Каждый шард содержит часть данных, например, пользователей с идентификаторами от 1 до 1000 в одном шарде и от 1001 до 2000 в другом.
2024-06-13 21:01:37 +03:00
- **Распределение нагрузки**: Поскольку запросы к данным могут обрабатываться параллельно разными шардами, это способствует балансировке нагрузки и увеличению производительности системы.
- **Масштабируемость**: По мере роста объёмов данных новые шарды могут быть добавлены в систему, что позволяет масштабировать приложение горизонтально.
- **Локализация данных**: Шардирование может быть использовано для локализации данных, чтобы уменьшить задержки, связанные с географическим расположением пользователей и баз данных.
**Плюсы:**
2024-06-20 21:54:23 +03:00
- [Горизонтальное масштабирование](Горизонтальное%20масштабирование.md)
2024-06-20 21:59:23 +03:00
- **Улучшение производительности**: Единственный метод ускоряющий запись в БД.
2024-06-13 21:01:37 +03:00
- **Высокая доступность и устойчивость к отказам**: Отказ одного шарда не приводит к полному сбою системы. Данные в остальных шардах остаются доступными, что повышает общую устойчивость системы к отказам.
**Минусы:**
2024-06-20 22:04:23 +03:00
- **Сложность управления**: Нет стандартных механизмов по управлению шардами. В случае добавления или удаления шардов может потребоваться перераспределение больших объемов данных, что может быть ресурсоемкой операцией и повлиять на производительность системы.
2024-06-13 21:01:37 +03:00
- **Трудности с транзакциями и согласованностью**: Шардирование может затруднить обеспечение атомарности и согласованности транзакций, охватывающих несколько шардов, что может потребовать дополнительных усилий для поддержания целостности данных.
**Проблемы**
2024-06-20 09:43:02 +03:00
- [Согласованное префиксное чтение](Согласованное%20префиксное%20чтение.md)
2024-06-20 22:04:23 +03:00
Стратегии разбиения на шарды
2024-06-20 22:09:23 +03:00
- [Key Based Sharding](Key%20Based%20Sharding.md). Наиболее распространенный способ.
2024-06-21 09:51:54 +03:00
- [Range Base Sharding](Range%20Base%20Sharding.md).
2024-06-30 11:11:56 +03:00
- [Directory Based Sharding](Directory%20Based%20Sharding.md)
2024-06-30 11:16:56 +03:00
Роутинг на шарды:
- Умный клиент. Приложение само решает в какой шард идти
- Нет дополнительной точки отказа. Нет лишнего хопа.
2024-06-30 11:21:56 +03:00
- Как обновлять при изменении количества шардов?
2024-06-30 11:16:56 +03:00
- Прокси
- Сервисы вообще не знают о шардинге
2024-06-30 11:21:56 +03:00
- Дополнительная точка отказа. Лишний хоп.
2024-06-30 11:16:56 +03:00
- Координатор
2024-06-30 11:21:56 +03:00
- Сервисы вообще не знают о шардинге.
- Дополнительная точка отказа. Лишний хоп.
- Не отдает сами данные, а указывает сервису в какой шард сходить.
Проблемы:
- Данные неравномерно распределились.
2024-06-30 11:27:26 +03:00
- Попробовать подобрать лучше ключ шардирования/кэш функцию
- Решардинг
- [JOIN SQL](JOIN%20SQL.md)
- Держать нужные данные на одном шарде
- Делать вычисления в одном сервисе
2024-06-30 11:32:53 +03:00
## Решардинг
При добавлении/удалении ноды нужно провести решардинг. Перенести старые данные на новые узлы.
Лучше если количество нод будет равно степени 2. Формула shard_Id % count.
- 16 записей на 8 шардов -> 2 записи на шард
2024-06-30 21:09:14 +03:00
- 16 записей на 16 шардов -> 1 запись на шард
2024-06-30 21:14:15 +03:00
- [Consistent hashing](Consistent%20hashing.md)
2024-06-30 21:09:14 +03:00
2024-06-30 21:14:15 +03:00
## Заметки
- Как и в случае [партиционирования](Партиционирование%20в%20БД.md) запросы по ключу шардирования ускорятся.
- Запросы не по ключу пройдут по всем узлам.
- Запросы по диапазону ключей хэширования могут обойти все шарды.
2024-06-30 21:19:14 +03:00
- Можно создавать различные индексы на узлах. При этом может оказаться так, что индексы на исходной таблице могут не подойди для шардирования.
- В [PostgreSQL](00%20PostgreSQL.md) есть шардирование из коробки, но оно реализовано на базе [партиционирования](Партиционирование%20в%20БД.md). Фактически партиции уезжают на отдельные сервера. Решардинг это боль, так как должен выполняться вручную.