...

Репликация БД, CAP-теорема и топология кластера

архитектура базы данных, архитектура БД примеры для аналитика, нефункциональные требования к БД, обучение архитекторов системных и бизнес-аналитиков, как задать требования к производительности ИС и БД, Школа прикладного бизнес-анализа

Как распределенные реляционные базы данных и NoSQL-хранилища обеспечивают согласованность данных, чем синхронная репликация отличается от асинхронной и как топология кластера влияет на задержку обработки изменений. Разбираем CAP-теорему гомогенной системы.

Репликация данных и CAP-теорема

Хранилище данных является узким местом любой информационной системы, ограничивая ее производительность – функцию от пропускной способности системы и скорости вычислений. Поэтому для повышения производительности ИС в большинстве случаев необходимо расширить ее емкость, увеличив количество автономных экземпляров хранилища, каждый из которых содержит актуальную копию данных. Это похоже на открытие дополнительной стойки регистрации в аэропорту при большой очереди пассажиров или кассы в магазине в часы пик.

Масштабирование очереди через добавление еще одного экземпляра обработчика
Масштабирование очереди через добавление еще одного экземпляра обработчика

Целостность, т.е. консистентность данных в таком кластере из нескольких распределенных узлов обеспечивает репликация – процесс копирования изменений из одного места в другие. Репликация может быть синхронной, когда все изменения транзакционно фиксируются по всем копиям и существует лишь одна версия данных или асинхронной, когда обновления фиксируются по репликам с некоторой задержкой. Синхронная репликация снижает производительность распределенного хранилища, создавая дополнительную нагрузку и чревата блокировками, зато гарантирует мгновенную согласованность (в рамках транзакции). Асинхронная репликация не влияет на производительность базы данных, но может привести к рассогласованию информации на разных узлах.

Практическая реализация репликации в разных БД выполняется по-разному: например, через триггерные функции, журналы транзакций, моментальные снимки БД и пр.

Помимо согласованности данных, в распределенной системе также важны ее доступность и устойчивость к разделению. Считается, что эти 3 свойства (доступность — Availiability, целостность – Consistency и устойчивость к разделению – Partition Tolerance) невозможно обеспечить одновременно. Это утверждение называется CAP-теорема, автором которой является профессор Эрик Брюер. В 2002 году ее формальное доказательство опубликовали Сет Гилберт и Нэнси Линч из массачусетского университета MIT.

Хотя положения CAP-теоремы характерны не только для кластера БД, но и для любой распределенной системы, в т.ч. гетерогенной, в этой статье разберем их на примере гомогенных хранилищ данных. В частности, некоторые кластерные БД, например, NoSQL-хранилища Cassandra, DynamoDB, Riak и пр., жертвуют мгновенной согласованностью данных в пользу доступности и устойчивости к разделению. Впрочем, говорить о полной рассинхронизации данных здесь тоже не стоит: по прошествии какого-то времени изменения распространятся по всем узлам кластера. Это называется согласованность в конечном счете (eventual consistency).

Реляционные СУБД типа MySQL, PostgreSQL и основанная на ней Greenplum, обеспечивают доступность, позволяя читать и записывать данные, а также гарантируют их мгновенную согласованность. Колоночные Google BigTable и Apache HBase, а также документо-ориентированная MongoDB и key-value Riak реализуют целостность и устойчивость к разделению.

CAP-теорема
CAP-теорема

На самом деле для распределенного хранилища данных также важно учитывать задержку репликации данных по узлам кластера, которая обусловлена не только внутренними механизмами, но и информационной топологией распределенной системы.

Основы архитектуры и интеграции информационных систем

Код курса
OAIS
Ближайшая дата курса
26 августа, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.

Топология кластера БД

Для гомогенного кластера БД наиболее распространенными информационными топологиями являются следующие:

  • централизованная с мастер-узлом – хостом, на котором работает главный экземпляр сервера СУБД;
  • кольцевая.

В централизованной топологии мастер-узлом является один из узлов кластера. Он считается ведущим и именно к нему отправляются команды на изменение (мутации данных). Изменения реплицируются по узлам-подписчикам. Запросы на чтение данных могут обращаться к любому узлу. Это похоже на реализацию паттерна CQRS в гомогенном распределенном хранилище данных. Именно так работают большинство БД: реляционные MySQL, PostgreSQL, Greenplum, а также многие нереляционные, например, Apache HBase, Redis и MongoDB. Такая топология обеспечивает высокую надежность распределенной ИС за счет реплик и хорошо повышает производительность чтения, а потому отлично подходит для аналитических сценариев. При отказе узла-подписчика система продолжает работать как обычно, сохраняя устойчивость к разделению, а при сбое мастера мутации временно недоступны.

Топология master-slave
Топология master-slave

В случае кольцевой топологии узлы соединены по кругу и изменения поочередно распространяются по всему кластеру. Мастер-узла здесь нет, запросы на чтение и команды на изменения данных могут обращаться к любому из узлов, гарантируя доступность и устойчивость системы к разделению в случае отказа любого узла. Однако, мгновенная целостность данных в этом случае не обеспечивается: данные будут согласованны в конечном счете, но для этого должно пройти какое-то время пока изменения распространятся по всем узлам кластера. Например, именно так работает NoSQL-хранилище типа ключ-значение Cassandra.

Кольцевая топология БД
Кольцевая топология БД

На практике кольцевая топология встречается гораздо реже, чем master-slave. Впрочем, для гомогенной системы топология кластера обычно не является настраиваемой. Тем не менее, аналитику и проектировщику решений важно ее знать, чтобы задать адекватные требования к задержке обработки данных и надежности системы. Как это сделать, вы узнаете на моих курсах в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS
Ближайшая дата курса
16 сентября, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.

 

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.