AcapellaDB v2 - General Information

About

Success

AcapellaDB - Fast Distributed ACID Transactional Replicated NoSQL Database (storage).

It can be used when you need "Postgres", but need linear horisontal scale read recomendations

Guarantees Features

AcapellaDB поддерживает следующие возможности, которые отличают её от других SQL и NoSQL баз данных:

  • Несколько уровней консистентности данных - для обеспечения строгой консистентности используется алгоритм Paxos, есть возможность подтверждения записи/чтения на одну, кворум или явно указанное число реплик.
  • Распределённые транзакции - в транзакцию можно включить любой набор ключей, независимо от их расположения в кластере.
  • Индексы - автоматическое индексирование данных по указанной схеме.
  • Линейная масштабируемость - пропускная способность кластера растёт пропорционально количеству узлов.
  • Изоляция транзакций - три уровня : NULL, RU - Read Uncommited, RC - Read Commited
  • Высокая скорость работы link1 link2 Благодаря Aeron transport и не блокирующей архтектуре на Kotlin coroutines

What about CAP

Компромисы в распределённых системах.

Когда какая-либо система начинает работать в кластере, всегда возникают проблемы связанные с CAP (Consistency, Availability, Partition tolerance) теоремой. Её основная идея - если система потеряла часть узлов (из-за проблем с сетью или выключения серверов), то нужно пожертвовать либо консистентностью данных, либо их доступностью.

Info

AcapellaDB находится в пространстве CP

AcapellaDB находится в пространстве CP (обеспечивает консистентность при разделении кластера), но потеря доступности происходит не сразу же.

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

Info

есть возможность работать в режиме AP, но без транзакций

Если не использовать транзакционое API,а использовать только get, set, cas, то имеется возможность работать в режиме AP. Но смешивать low level API и транзакционный API нельзя.

Recomendation

Когда стоит использовать AcapellaDB

Если вам необходимы следующие возможности, то AcapellaDB может стать подходящим решением:

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

Когда не стоит использовать AcapellaDB

AcapellaDB скорее всего вам не подойдёт, если присутствуют следующие требования:

  • Данные могут быть в неконсистентном состоянии (eventually consistent, last write wins).
  • Необходим простой key-value кеш.
  • Требуется полноценная поддержка SQL (очень сложная модель данных/предметная область).
  • Основная нагрузка на базу - аналитические выборки.

Обзор архитектуры

AcapellaDB можно разделить на следующие слои:

  • Работа с транзакциями - создание и завершение транзакций, транзакционные запросы к данным.
  • Key-Value слой - нетранзакционные запросы к данным.
  • Слой реплицирования - запросы для реализации алгоритма Paxos.
  • Слой хранения данных - запись и чтение данных на диск. Данный слой работает поверх RocksDb.

Paxos

Paxos - это алгоритм принятия решений в распределённой среде. Он используется для поддержания данных в консистентном состоянии. Каждая запись или чтение проходит через следующие фазы исполнения:

  1. Запрос приходит на произвольный узел базы. Этот узел становится лидером для данного запроса.
  2. Лидер определяет, на каких узлах лежат запрашиваемые данные. Эти узлы называются репликами.
  3. По необходимости выполняются запросы на чтение данных со всех реплик. Количество ответов для подтверждения чтения может быть задано пользователем.
  4. Данные из ответов от всех реплик объединяются, чтобы получить актуальные значения.
  5. По необходимости посылаются запросы на запись на все реплики. Количество ответов для подтверждения записи может быть задано пользователем.

Если во время исполнения алгоритма произошли изменения в данных, то произойдёт повторная попытка применить новые данные. Использвание Paxos не требует блокировок и обеспечивает отсутствие deadlock'ов.

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

Распределение данных по кластеру

Info

Ключи в AcapellaDB состоят из двух частей partition и clustering. Первая часть используется для распределения ключей по кластеру, вторая - для создания упорядоченных последовательностей данных, чтобы увеличить локальность связанных данных.

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

Поддержка ACID

Запросы на запись и чтение поддерживают все ACID свойства:

  • Atomicity. Записи в запросе либо целиком применяются, либо (при ошибке) целиком откатываются, как будто запрос не происходил вообще.
  • Consistency. В отличие от реляционных баз данных, в AcapellaDB не предоставляет проверок целостности данных, так, что эта задача ложится на разработчика, но остальные свойства обеспечивают применение только тех данных, которые были получены из запроса.
  • Isolation. Другие запросы на запись или чтение не увидят частичных изменений из других запросов.
  • Durability. Сохранение на диск обеспечивается RocksDb. В зависимости от настроек реплицирования, перед ответом пользователю, данные будут записаны на одну реплику, кворум или все реплики.

Распределённые транзакции

Info

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

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

  • Оптимистичное чтение данных. Не блокирует ключ. Для поддержки изоляции перед завершением транзакции нужно проверить, что этот ключ не был изменён.
  • Пессимистичное чтение данных. Блокирует ключ до завершения транзакции.
  • Запись данных (возможно с условием). Блокирует ключ до завершения транзакции.

Чтения и записи диапазонов значений сейчас не поддерживаются в транзакциях.