HighLoad — масштабирование реляционных СУБД

Get Started. It's Free
or sign up with your email address
HighLoad — масштабирование реляционных СУБД by Mind Map: HighLoad — масштабирование реляционных СУБД

1. scale up (более мощное железо)

1.1. Больше CPU

1.1.1. Ограниченная масштабируемость большинства СУБД

1.1.1.1. Особенно mysql

1.2. Больше памяти

1.2.1. Больше кэшей

1.3. Нелинейный эффект от вложения денег

1.4. избыточность мощности — нельзя плавно повышать мощность

1.5. downtime, миграции

2. Репликация

2.1. Виды

2.1.1. Синхронная / асинхронная

2.1.2. master-slave / multi-master (master-master)

2.2. Проблемы

2.2.1. Выигрыш нелинейный

2.2.2. Большой overhead на синхронизацию

2.2.2.1. иерархия серверов

2.2.2.1.1. maatkit

2.2.3. Неконсистентные данные

2.2.3.1. Репликация в один тред

2.2.4. Запись не масштабируется!

2.2.4.1. master / master

2.2.4.1.1. сложно, ненадёжно

2.3. Как роутить чтение между серверами

2.3.1. proxy

2.3.1.1. mysqlproxy

2.3.1.2. pgproxy

2.3.1.3. "sql proxy" от slonik_v_domene

2.3.2. внутри приложения

2.3.2.1. при перебалансировке нужно патчить приложение

2.3.3. DNS-LB

2.3.3.1. латентность

3. Вертикальное масштабирование

3.1. Выделение ролей для серверов

3.1.1. Разные таблицы на разных серверах

3.1.2. Разные колонки на разных серверах

3.1.2.1. Можно уменьшить локи, разнеся insert и update

3.1.3. Проблемы

3.1.3.1. Всё равно упираемся в пределы физической машины

3.1.3.1.1. Ограниченный профит

3.1.3.2. До свиданья джойны...

3.1.3.3. Решения

3.1.3.3.1. mysql federated engine

3.2. Встроенный в СУБД partitioning (разные куски таблицы / разные таблицы на разных дисках)

3.2.1. Можно физически хранить на разных storage...

3.2.2. Минусы

3.2.2.1. Узким местом всё равно становится масштабируемость СУБД

4. Горизонтальное масштабирование

4.1. Плюсы

4.1.1. Неограниченное масштабирование

4.2. Как разделять данные

4.2.1. Статически

4.2.1.1. По списку значений

4.2.1.1.1. девочки налево, мальчики направо

4.2.1.2. Хэш-функции

4.2.1.2.1. Остаток от деления

4.2.1.2.2. По "первой букве"

4.2.1.2.3. MD5 и т.п.

4.2.1.3. По дате

4.2.1.4. По диапазону ID PK

4.2.1.5. Проблемы -- слишком жёсткие правила, неудобно добавлять серверы

4.2.1.5.1. "Математические трюки": 12, 24...

4.2.2. Динамически

4.2.2.1. добавление новых машин, замена, перенос, балансировка – без изменения кода

4.2.2.2. Минус: SPOF, высокая нагрузка

4.2.2.3. Роутинг

4.2.2.3.1. proxy

4.2.2.3.2. координирующий сервер

4.3. Решения

4.3.1. Вручную, внутри приложения

4.3.1.1. Нужно писать прослойку для работы с данными

4.3.2. proxy

4.3.2.1. PL/Proxy

4.3.2.2. mysqlproxy

4.3.2.2.1. LUA

4.4. Минусы

4.4.1. Нельзя JOINs

4.4.2. Усложняется доступ к данным