Как настроить YugabyteDB как в конечном счете непротиворечивую распределенную базу данных «ключ-значение»?

Спасибо за интерес к Yugabyte DB! Это, безусловно, отличный вариант использования. Пожалуйста, смотрите ответы в строке.

Меня интересует глобальная репликация с YugaByte. На данный момент я построил абстракцию над BadgerDB, базой данных Key-Value, написанной на GoLang. Наша абстракция поддерживает индексы, похожа на graphql и чрезвычайно БЫСТРАЯ. Можно ли использовать БД YugaByte с глобальной репликацией в качестве хранилища Key Value вместо GoLang? Я стремлюсь к производительности KeyValue, Globally Distributed.

Да, с помощью Yugabyte DB вы можете добиться высокопроизводительного глобально распределенного развертывания по принципу «ключ-значение». Вы можете увидеть пример глобально распределенного развертывания здесь. .

• Реплики чтения — это доступное только для чтения расширение основных данных в кластере. В этом сценарии первичные данные кластера развертываются в нескольких зонах в одном регионе или в соседних регионах. Реплики чтения не увеличивают задержки записи, поскольку запись не реплицирует данные в них синхронно — данные реплицируются для реплик чтения асинхронно. Вы можете писать в реплику, но запись будет внутренне перенаправлена ​​на источник правды.

• Развертывания с несколькими мастерами в настоящее время выпускаются как часть нашей бета-версии 2.0. Эта функция позволяет независимым кластерам реплицироваться друг в друга с семантикой выигрывает последний писатель. Вот подробный проектный документ о развертывании с несколькими мастерами.

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

Поэтому нам нужен уровень аутентификации на сервере между YugaByte и клиентом, в идеале этот уровень должен обеспечивать ту же абстракцию, которую мы сейчас написали в Go.

Да, Yugabyte DB поддерживает аутентификацию и RBAC для авторизации в клиентских драйверах Go.

Как насчет балансировки нагрузки между узлами, направляющими запросы к ближайшему географическому местоположению?

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

Надеюсь, что это поможет, и дайте мне знать, если у вас есть дополнительные вопросы!

Как я понял скорость записи падает с каждой дополнительной реплицируемой нодой. Это правильно?

В предыдущем ответе предполагается, что additional replicated node на самом деле является дополнительной репликой. Однако если это означает новый узел в кластере, то ответ таков: новый узел не увеличивает задержку записи. Новый узел просто обеспечивает большую пропускную способность записи (и чтения) для кластера, поскольку теперь он может размещать некоторые из ведущих и ведомых сегментов (также называемых планшетами), присутствующих в кластере. Задержка операции записи значения ключа контролируется коэффициентом репликации (RF) кластера, где обычное значение RF равно 3 для производственных развертываний. В таких развертываниях каждый шард будет иметь 3 реплики, расположенные на 3 отдельных узлах кластера. Запись должна быть зафиксирована на ведущей реплике и по крайней мере на 1 из 2 подчиненных реплик, прежде чем операция будет подтверждена клиентом приложения как успешная. Таким образом, задержка операций записи увеличивается только при выполнении одного или обоих из следующих действий:

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

2. увеличьте RF, скажем, с 3 до 5 (что приведет к тому, что 3 из 4 реплик должны будут зафиксировать запись до подтверждения клиента).

Можно ли вместо этого предпочесть скорость и вместо этого иметь в конечном итоге согласованную модель для всех узлов?

Возможная согласованность в базе данных Yugabyte невозможна, учитывая зависимость от распределенного консенсуса для каждого сегмента (с использованием Raft в качестве протокола консенсуса) между узлами, обрабатывающими запросы на запись. Вы можете просмотреть, чем Raft отличается от окончательной согласованности, в этом посте Как работает репликация на основе консенсуса в распределенных базах данных? в разделе "Paxos/Raft и протоколы репликации без консенсуса". Как подчеркивалось в предыдущем ответе, когда задержка записи между регионами вызывает беспокойство, решение состоит в том, чтобы использовать асинхронную репликацию между регионами, используя либо кластеры реплик чтения (для обеспечения согласованного по времени чтения в регионах, удаленных от регионов, принимающих запросы на запись), либо Multi -Master Clusters (для обеспечения записи в нескольких регионах с конфликтующими запросами на запись, разрешенными с помощью Last Writer Wins).