Масштабирование БД
Масштабирование БД
Репликация
Асинхронная репликация
Чтение после записи
В случае асинхронной репликации возможна ситуация, когда юзер записывает данные, они записываются на ведущий узел. Данные проходят процесс асинхронной репликации, но юзер пытается считать данные сразу и попадает на ведомую реплику, на которой еще не закончилась репликация. В итоге данных нет, и для юзера происходит рассинхрон.
Бороться с этим можно с помощью согласованности типа "чтения после записи" (read-after-write consistency).
Несколько способов этого достичь:
- Для информации, которая доступна для редактирования только самому юзеру (например, данные профиля), можно разрешать чтение этой информации только с ведущего узла для юзера, а для остальных с реплики.
- В общем случае можно на некоторое время после изменения данных разрешать чтение для юзера только из ведущего узла.
Монотонные чтения
При асинхронной репликации возможна ситуация, когда юзер сначала произведет операцию чтения с более новой реплики, а потом с более старой. Получится, что юзер как бы откатился назад во времени.
Для обхода такой ситуации необходимо обеспечить монотонное чтение записей. Это более надежная гарантия, чем конечная согласованность (eventual consistency), но менее, чем сильная согласованность (strong consistency).
Для ее обеспечения можно добавить определенность в то, на какую реплику попадают юзеры. Например, вычислять реплику исходя из хэша юзера. Однако, при сбое реплики нужно предусмотреть механизм перенаправления на другую (работающую) реплику.
Согласованное префиксное чтение
При асинхронной репликации возможна ситуация, когда из-за задержек записи нарушается причинно-следственные связи.
Пример:
Мистер Пунс: Насколько далеко в будущее вы можете заглянуть, миссис Кейк?
Миссис Кейк: Обычно секунд на десять, мистер Пунс.
Между этими двумя фразами существует причинная зависимость: миссис Кейк услышала вопрос мистера Пунса и ответила на него.
Теперь представьте третьего человека, слушающего данный разговор через ведомые узлы. Сказанное миссис Кейк проходит через ведомый узел с небольшой задержкой, но задержка репликации сказанного мистером Пунсом значительно больше. Этот наблюдатель услышит следующее.
Миссис Кейк: Обычно секунд на десять, мистер Пунс.
Мистер Пунс: Насколько далеко в будущее вы можете заглянуть, миссис Кейк?
С точки зрения наблюдателя, миссис Кейк отвечает на вопрос еще до того, как мистер Пунс его задал.
Для предотвращение такой ситуации необходимо гарантировать согласованное префиксное чтение (consistent prefix reads).
Если БД всегда применяет операции записи в одном и том же порядке, то префикс при чтении всегда будет согласованным, так что аномалии не случится. Реализовать такое особенно сложно в шардированных базах, где нет гарантий порядка записей.
Master-slave репликация
Мастер принимает запросы на чтение и запись, реплицировать запись на слейвы. Слейвы принимают только запросы на чтение, при этом могут сами реплицировать на дополнительных слейвов, образуя дерево.
При отказе мастера система входит в режим "только для чтения" до переподключения мастера либо до объявления нового мастера.
Недостатки
- Нужна дополнительная логика для поднятия слейва до мастера
Мастер-мастер репликация
Еще называют active-active репликацией или репликацией с несколькими ведущими узлами.
Оба сервера принимают запросы на чтение и запись. Они координируют между собой записи.
При отказе одного из мастеров система остаётся в том же состоянии, принимая запросы на чтение и запись
Достоинства
- Производительность. В случае с одним ведущим узлом если сервер не находится в том же ЦОДе, что и БД, то передача данных будет происходить через внешний интернет с соответствующими задержками. В случае с несколькими ведущими узлами, сервер будет работать с БД в том же ЦОДе, то есть по локальной сети.
- Устойчивость (Failure tolerance). В случае отказа одного из узлов (или одного из ЦОДов) приложение продолжит работу.
Недостатки
- Нужен либо балансировщик, либо менять прикладную логику для выбора мастера для записи
- Большинство мастер-мастер систем имеют слабую связность, нарушая ACID, либо имеют большую задержку при записи из-за синхронизации
- Чем больше узлов добавляется, тем чаще начинает работать разрешение конфликтов при записи
Сценарии
Работа в нескольких ЦОДах
Чаще всего имеет смысл только если сервис расположен сразу на нескольких ЦОДах. Тогда на каждый ЦОД располагают по одному ведущему узлу и внутри ЦОДа уже происходит репликация на ведомые узлы (master-slave).
Оффлайн-приложения
Возможна ситуация, когда приложение должно уметь редактировать свои данные даже без доступа к сети. В таком случае само устройство становится ведущим узлом, а все БД - ведомыми узлами с асинхронной репликацией. Причем задержка репликации может достигать дни, а репликация происходит при следующем доступе в интернет.
Пример: приложения календаря, редактирование/добавление/удаление встреч.
Синхронное и асинхронное разрешение конфликтов
Синхронное на нескольких узлах = 1 ведущий узел + синхронная репликация, так что большого смысла не имеет.
Асинхронное разрешение приводит проблемам, когда 2 юзера параллельно меняют одни и те же данные. Например, заголовок статьи - был А, один юзер назвал B, второй юзер назвал C, как показать название?
Предотвращение конфликтов
Лучший способ - если есть возможность избежать конфликта. Например, если речь идет о редактировании личных данных пользователя, то можно привязывать его к определенному ЦОДу. Тогда невозможны конфликты на разных ЦОДах.
Но иногда приходится менять ЦОД для пользователя. Например, если привязанный вышел из строя или если пользователь сменил локацию и стал ближе к другому ЦОДу.
Сходимость к согласованному состоянию
Некоторые способы разрешения конфликтов на уровне данных:
- Присвоить каждой записи уникальный идентификатор, имеющий частичный порядок (UUID, дата изменения, случайное число). Тогда при конфликте можно оставлять данные с большим идентификатором. Этот способ называется last write wins или LWW. Недостаток - потеря данных.
- Приоритезация реплик. Присваивать репликам уникальный счетный идентификатор и считать, что данные от реплики с большим номером имеют больший приоритет. Недостаток - потеря данных.
- Слияние записей. Можно некоторым образом объединять конфликтные записи в одну. Например, в примере с заголовком статьи можно объединить их в заголовок "B/C".
- Сохранять конфликты в отдельной структуре и разрешать их после с помощью сервисного кода (например, уведомлять пользователей о конфликте и дать разрешить их самим).
Недостатки репликации
- Потенциальные потери данных между записью в мастер и репликацией этой записи.
- Записи в мастер повторяются на всех репликациях. Поэтому операции чтения на всех серверах могут быть заблокированы при большом потоке записи.
- Чем больше целей репликации, тем больше будет задержка репликации
- В некоторых системах, мастер сервера поддерживают параллелизм при записи, а реплики не поддерживают.
- Реплики добавляют больше железа и архитектурной сложности
Source(s) and further reading: replication
Федерация
(Federation)
Федерация - это разбиение монолитной базы данных на несколько по функциям.
При этом трафик на каждую из них станет меньше, что приведет к меньшим задержкам репликации. Так же уменьшится размер базы, значит больший процент данных поместится в памяти, что приведет к большему попаданию в кэш.
Недостатки
- Неэффективно, если нужны большие таблицы в БД
- Джоины между двумя базами становятся проблемой
- Больше железа и сложности поддержки
Шардирование
