🚀 Попробуйте Zilliz Cloud, полностью управляемый Milvus, бесплатно — ощутите 10-кратное увеличение производительности! Попробовать сейчас>

milvus-logo
LFAI
  • Home
  • Blog
  • Плот или не плот? Лучшее решение для обеспечения согласованности данных в облачных базах данных

Плот или не плот? Лучшее решение для обеспечения согласованности данных в облачных базах данных

  • Engineering
May 16, 2022
Xiaofan Luan

Cover image Изображение на обложке

Эта статья написана Сяофаном Луаном и переработана Анжелой Ни.

Репликация на основе консенсуса - широко распространенная стратегия во многих облачных распределенных базах данных. Однако она имеет определенные недостатки и определенно не является серебряной пулей.

Цель этого поста - сначала объяснить понятия репликации, согласованности и консенсуса в облачных распределенных базах данных, затем объяснить, почему алгоритмы на основе консенсуса, такие как Paxos и Raft, не являются серебряной пулей, и, наконец, предложить решение проблемы репликации на основе консенсуса.

Перейти к:

Понимание репликации, согласованности и консенсуса

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

Обратите внимание, что эта статья в основном посвящена синхронизации инкрементных данных/журнала. Поэтому, говоря о репликации данных/журнала, мы имеем в виду только репликацию инкрементных данных, а не исторических.

Репликация

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

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

Согласованность

В двух словах, согласованность в распределенной базе данных - это свойство, которое обеспечивает одинаковое представление данных на каждом узле или реплике при записи или чтении данных в определенный момент времени. Полный список уровней согласованности можно найти в документе здесь.

Чтобы прояснить, здесь мы говорим о согласованности по теореме CAP, а не об ACID (atomicity, consistency, isolation, durability). Согласованность по теореме CAP означает, что каждый узел в системе имеет одни и те же данные, в то время как согласованность по ACID означает, что один узел применяет одни и те же правила для каждой потенциальной фиксации.

Как правило, базы данных OLTP (обработка транзакций в режиме онлайн) требуют сильной согласованности или линеаризуемости, чтобы гарантировать, что:

  • При каждом чтении можно получить доступ к последним вставленным данным.
  • Если после чтения возвращается новое значение, то все последующие чтения, независимо от того, на одном или разных клиентах, должны возвращать это новое значение.

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

Консенсус

Понятие консенсуса вводится в распределенные системы, поскольку пользователи хотят, чтобы распределенные системы работали так же, как и автономные.

Проще говоря, консенсус - это общее согласие по поводу ценности. Например, Стив и Фрэнк захотели перекусить. Стив предложил съесть сэндвичи. Фрэнк согласился с предложением Стива, и они оба съели сэндвичи. Они достигли консенсуса. Точнее, ценность (сэндвичи), предложенная одним из них, была согласована с обоими, и они оба предприняли действия, основанные на этой ценности. Аналогично, консенсус в распределенной системе означает, что когда один процесс предлагает значение, все остальные процессы в системе соглашаются с этим значением и действуют на его основе.

Consensus Консенсус

Репликация на основе консенсуса

Самые ранние алгоритмы, основанные на консенсусе, были предложены вместе с репликацией с метками просмотра в 1988 году. В 1989 году Лесли Лэмпорт предложил Paxos, алгоритм, основанный на консенсусе.

В последние годы в индустрии появился еще один распространенный алгоритм на основе консенсуса - Raft. Он был принят многими основными базами данных NewSQL, такими как CockroachDB, TiDB, OceanBase и т. д.

Примечательно, что распределенная система не обязательно поддерживает линеаризуемость, даже если в ней используется репликация на основе консенсуса. Тем не менее, линеаризуемость является необходимым условием для построения распределенной базы данных ACID.

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

Raft replication state machine Машина состояний репликации Raft

Плюсы и минусы

Действительно, Raft, ZAB и основанный на кворуме протокол протоколирования в Aurora - все это вариации Paxos. Репликация на основе консенсуса имеет следующие преимущества:

  1. Хотя репликация на основе консенсуса больше сосредоточена на согласованности и разделении сети по теореме CAP, она обеспечивает относительно лучшую доступность по сравнению с традиционной репликацией "лидер-последователь".
  2. Raft - это прорыв, который значительно упростил алгоритмы, основанные на консенсусе. На GitHub существует множество библиотек Raft с открытым исходным кодом (например, sofa-jraft).
  3. Производительность репликации на основе консенсуса может удовлетворить большинство приложений и предприятий. С появлением высокопроизводительных SSD и гигабайтных NIC (сетевых интерфейсных карт) бремя синхронизации нескольких реплик уменьшается, что делает алгоритмы Paxos и Raft основными в отрасли.

Одно из заблуждений заключается в том, что репликация на основе консенсуса - это серебряная пуля для достижения согласованности данных в распределенной базе данных. Однако это не так. Проблемы доступности, сложности и производительности, с которыми сталкивается алгоритм на основе консенсуса, не позволяют ему стать идеальным решением.

  1. Снижение доступности Оптимизированный алгоритм Paxos или Raft имеет сильную зависимость от реплики-лидера, что приводит к слабой способности бороться с серыми отказами. При репликации на основе консенсуса новые выборы реплики-лидера не происходят до тех пор, пока узел-лидер не отвечает в течение длительного времени. Поэтому репликация на основе консенсуса не способна справиться с ситуациями, когда ведущий узел работает медленно или происходит треш.

  2. Высокая сложность Хотя уже существует множество расширенных алгоритмов, основанных на Paxos и Raft, появление Multi-Raft и Parallel Raft требует дополнительных размышлений и тестов на синхронизацию между журналами и машинами состояний.

  3. Снижение производительности В эпоху облачных технологий локальные хранилища заменяются общими хранилищами, такими как EBS и S3, чтобы обеспечить надежность и согласованность данных. В результате репликация на основе консенсуса больше не является обязательным условием для распределенных систем. Более того, репликация на основе консенсуса сопряжена с проблемой избыточности данных, поскольку и решение, и EBS имеют несколько копий.

При многоцентровой и многооблачной репликации стремление к согласованности ставит под угрозу не только доступность, но и задержку, что приводит к снижению производительности. Поэтому в большинстве приложений линеаризуемость не является обязательным условием катастрофоустойчивости для нескольких ЦОД.

Стратегия репликации журналов для облачных и распределенных баз данных

Безусловно, алгоритмы, основанные на консенсусе, такие как Raft и Paxos, по-прежнему являются основными алгоритмами, принятыми во многих базах данных OLTP. Однако, наблюдая за примерами протокола PacificA, Socrates и Rockset, мы видим, что тенденция меняется.

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

1. Репликация как сервис

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

Например, в Socrates разделены хранилище, журнал и вычисления. Имеется один выделенный лог-сервис (сервис XLog в центре рисунка ниже).

Socrates architecture Архитектура Сократа

Сервис XLog - это отдельный сервис. Сохранение данных достигается с помощью хранилища с низкой задержкой. Посадочная зона в Сократе отвечает за ускоренное хранение трех реплик.

Socrates XLog service Сервис XLog в Сократе

Лидерский узел асинхронно рассылает логи лог-брокеру и сбрасывает данные в Xstore. Локальный SSD-кэш может ускорить чтение данных. После успешной пересылки данных буферы в посадочной зоне могут быть очищены. Очевидно, что все данные журнала делятся на три уровня - посадочная зона, локальный SSD и XStore.

2. Принцип русской матрешки

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

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

Похоже, нам не обойтись без Paxos, чтобы избежать единой точки отказа. Однако мы все же можем значительно упростить репликацию журналов, передав выборы лидера сервисам Raft или Paxos, основанным на Chubby, Zk и etcd.

Например, архитектура Rockset следует принципу русской матрешки и использует Kafka/Kineses для распределенных журналов, S3 для хранения и локальный SSD-кэш для повышения производительности запросов.

Rockset architecture Архитектура Rockset

Подход Milvus

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

Однако при разработке Milvus не была принята стратегия следования. Другими словами, Milvus не запрашивает индекс фиксации каждый раз, когда получает запрос. Вместо этого Milvus использует механизм, подобный водяному знаку во Flink, который уведомляет узел запроса о местонахождении индекса фиксации через регулярный интервал времени. Причина такого механизма в том, что пользователи Milvus обычно не предъявляют высоких требований к согласованности данных, и они могут принять компромисс в видимости данных для повышения производительности системы.

Кроме того, Milvus использует множество микросервисов и отделяет хранение данных от вычислений. В архитектуре Milvus для хранения данных используются S3, MinIo и Azure Blob.

Milvus architecture Архитектура Milvus

Резюме

В настоящее время все большее количество облачных баз данных делают репликацию журналов отдельным сервисом. Это позволяет снизить затраты на добавление реплик только для чтения и гетерогенную репликацию. Использование нескольких микросервисов позволяет быстро задействовать зрелую облачную инфраструктуру, что невозможно для традиционных баз данных. Отдельный лог-сервис может полагаться на репликацию на основе консенсуса, но также может следовать стратегии "русской матрешки" и использовать различные протоколы согласованности вместе с Paxos или Raft для достижения линеаризуемости.

Ссылки

  • Lamport L. Paxos made simple [J]. ACM SIGACT News (Distributed Computing Column) 32, 4 (Whole Number 121, December 2001), 2001: 51-58.
  • Ongaro D, Ousterhout J. In search of an understandable consensus algorithm[C]//2014 USENIX Annual Technical Conference (Usenix ATC 14). 2014: 305-319.
  • Oki B M, Liskov B H. Viewstamped replication: A new primary copy method to support highly-available distributed systems[C]//Proceedings of the seventh annual ACM Symposium on Principles of distributed computing. 1988: 8-17.
  • Lin W, Yang M, Zhang L, et al. PacificA: Replication in log-based distributed storage systems[J]. 2008.
  • Вербицкий А., Гупта А., Саха Д. и др. Amazon aurora: On avoiding distributed consensus for i/os, commits, and membership changes[C]//Proceedings of the 2018 International Conference on Management of Data. 2018: 789-796.
  • Antonopoulos P, Budovski A, Diaconu C, et al. Socrates: Новый sql-сервер в облаке[C]//Proceedings of the 2019 International Conference on Management of Data. 2019: 1743-1756.

Like the article? Spread the word

Продолжить чтение