(в этой части конспекта курсив – комментарии, остальной текст – презентация)
Когда строим какую-либо реляционную систему, 3 части:
- клиентская
- бэкенд
- база данных
Нужно масштабироваться. Можно делать это вертикально, но упрёмся в производительность. Тогда проще сделать много серверов. Бд разделены на несколько устройств
Определение
- Распределенная база данных - это набор логически взаимосвязанных данных, которые физически распределены между несколькими узлами в некоторой компьютерной сети.
Мотивация
- Масштабируемость
- Высокая доступность и отказоустойчивость
- Производительность
Модели распределения данных
- Репликация Если репликация, то соединённые ноды имеют одни и те же данные одна сломалась - в другой всё осталось(отказоустойчивость) повышается производительность
- Шардинг Если шардинг, то в разных нодах разные данные. нода упала - половина данных недоступна
- Replication + Sharding
РБД?
- Партиционирование - это вертикальное разделение таблицы по строкам внутри одной базы данных
Репликация
- Синхронная
- Асинхронная
Архитектуры реплицирования
- Master-Slave Есть одна нода - мастер, остальные будут её слейвы. Ограничения там на чтение и запись… Мастеры могут писать и читать, а а слейв только читать?
- Multi-Master любая реплика тоже мастер
- Peer-to-Peer каждая нода - полноценный, независимый организм
Стратегии шардирования
- Шардирование по диапазону (самый простой вариант)
- Шардирование по хэшу
- Шардирование по справочнику
- Геошардинг
Проблемы шардирования
- Сложность запросов (JOINs)
- Транзакции (требует дорогих Two-Phase Commit)
- Решардинг (Решардинг - перераспределение данных - очень дорого при шардировании)
- Роутинг запросов (нужен координатор)
- Неподходящие ключи шардирования
- Кайфанешь от SELECT COUNT(*)
Типы распределенных СУБД
- Однородные (Homogeneous)
- Неоднородные (Heterogeneous)
Two-Phase Commit
- Фаза подготовки
- Фаза решения
недостатки 2РС
- Протокол требует двух раундов сетевого взаимодействия
- Каждая транзакция ждет ответов от всех участников
- Координатор - единая точка отказа
альтернатива 2РС: делаем маленький операции на уровне микросервисов
BASE
- BASE — это свойство, которая жертвует немедленной строгой согласованностью в обмен на высокую доступность и производительность.
BASE
- Basically Available - Система отвечает на любой запрос, но этот ответ может быть содержать ошибку или несогласованные данные.
- Soft-state - Состояние системы может меняться со временем из-за изменений конечной согласованности.
- Eventual consistency - Система, в конечном итоге, станет согласованной. Она будет продолжать принимать данные и не будет проверять каждую транзакцию на согласованность.
CAP
САР теорема (теорема Брюера) - утверждает, что в любой распределенной системе, обеспечивающей хранение данных, невозможно одновременно гарантировать более двух из трех свойств.
- Consistency - информация на разных узлах согласована
- Availability - система отвечает на запросы в любой момент времени
- Partition tolerance - связи между узлами могут обрываться
CP
- При разрыве связи между узлами система блокирует запись на часть узлов, чтобы гарантировать, что данные останутся согласованными.
- Примеры: MongoDB, Redis, ZooKeeper
AP
- При разрыве связи все узлы остаются доступными для чтения и записи. Это может привести к тому, что разные узлы будут иметь разные версии данных
- Примеры: Cassandra, Scylla.
CA
Такая система может существовать только при отсутствии сетевых сбоев.
Идея нового сервиса — «Позвони, напомню!»
- Система хранения фактов с разрешенными действиями:
- Запрос на запись факта;
- Запрос на изменение факта;
- Запрос на чтение факта.
Продолжение читать тут…
PACELC
- PACELC - расширяет САР, описывая поведение системы не только во время сетевых сбоев, но и в нормальных условиях работы.
- Если произошел Р, то выбираем между А и С
- (E)lse выбираем между: L и С