Как распределенные реляционные базы данных и 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 реализуют целостность и устойчивость к разделению.
На самом деле для распределенного хранилища данных также важно учитывать задержку репликации данных по узлам кластера, которая обусловлена не только внутренними механизмами, но и информационной топологией распределенной системы.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
5 ноября, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Топология кластера БД
Для гомогенного кластера БД наиболее распространенными информационными топологиями являются следующие:
- централизованная с мастер-узлом – хостом, на котором работает главный экземпляр сервера СУБД;
- кольцевая.
В централизованной топологии мастер-узлом является один из узлов кластера. Он считается ведущим и именно к нему отправляются команды на изменение (мутации данных). Изменения реплицируются по узлам-подписчикам. Запросы на чтение данных могут обращаться к любому узлу. Это похоже на реализацию паттерна CQRS в гомогенном распределенном хранилище данных. Именно так работают большинство БД: реляционные MySQL, PostgreSQL, Greenplum, а также многие нереляционные, например, Apache HBase, Redis и MongoDB. Такая топология обеспечивает высокую надежность распределенной ИС за счет реплик и хорошо повышает производительность чтения, а потому отлично подходит для аналитических сценариев. При отказе узла-подписчика система продолжает работать как обычно, сохраняя устойчивость к разделению, а при сбое мастера мутации временно недоступны.
В случае кольцевой топологии узлы соединены по кругу и изменения поочередно распространяются по всему кластеру. Мастер-узла здесь нет, запросы на чтение и команды на изменения данных могут обращаться к любому из узлов, гарантируя доступность и устойчивость системы к разделению в случае отказа любого узла. Однако, мгновенная целостность данных в этом случае не обеспечивается: данные будут согласованны в конечном счете, но для этого должно пройти какое-то время пока изменения распространятся по всем узлам кластера. Например, именно так работает NoSQL-хранилище типа ключ-значение Cassandra.
На практике кольцевая топология встречается гораздо реже, чем master-slave. Впрочем, для гомогенной системы топология кластера обычно не является настраиваемой. Тем не менее, аналитику и проектировщику решений важно ее знать, чтобы задать адекватные требования к задержке обработки данных и надежности системы. Как это сделать, вы узнаете на моих курсах в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
16 сентября, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
