Хочу сделать некую дискуссию про Базы Данных

Всем приветище!

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

Подробности под катом… Хочу их пообсуждать немного с Вами.

Мы разработали:

1. «AcapellaDB V2» она же AStorage
2. «AcapellaDB V3» она же ADB

Версии хоть и разные, но это совсем разные базы данных, очень не похожи.

Видимо я зря их обозначил одним именем, это была ошибка, и надо бы пока не поздно дать им разные имена, например, AStorage и ADB.

Согласны? Как Вы считаете ?  — Это и есть основной вопрос поста.

 

Общие черты V2  и  V3

Обе они распределенные. Доступные возможности на данный момент для внешних пользователей:

1. AStorage это multi-master кластер, возможно шардирование и репликация
2. ADB это multi-master кластер с репликацией, пока без шардирования (MVCC на подходе — шардирование будет)

Обе умеют репликацию, правда, немного по-разному:

1. У AStorage число реплик можно менять для каждого ключа как для чтения, для записи и для кворума (как в Riak)
2. у ADB число реплик = 3,  константа (так собран кластер)

Обе они имеют транзакции ACID:

1. AStorage умеет несколько уровней изоляции, которые можно гибко выбирать + можно работать без транзакций в стиле NoSQL
2. ADB умеет толькоSERIALIZABLE, всегда. без транзакций работать никак.

Обе умеют работать с транзакцией из разных соединений, обращаясь к разным узлам

1. AStorage — принимает параметр  trid  в каждом запросе (api), это позволяет не блокировать соединение или поток или процесс для работы с транзакцией
2. ADB — все аналогично. Это наша фишка, выгодно отличает от конкурентов. Правда в SDK и языках, используя «with transaction»,  это трудно показать

А вот дальше пойдут  различия

Схема данных:

1. AStorage — модель данных больше похожа на NoSQL. Поддерживается сразу 6 моделей данных таблица их возможностей тут (3 главных и х2 комбинации с P & С ключами). Если понимать, как это готовить — этого вам хватит для всего, но надо быть не дураком. Можно даже не иметь разных БД для разных свойств в решении, а обойтись этим, одним.
2. ADB — RDBMS т.е. реляционная модель (базы, таблицы, индексы…). Тут все безопасно, и дураком быть допускается, т.к. есть от этого «защита». (LowLevel API планируется, оно будет в стиле LevelDB)

SQL,  query Language

1. AStorage. для KV  стандартные: get, set,cas, getversion. Для DT все как у KV плюс next, prev, find, range with limit. Для SortedMap все то же плюс batch’s и другие особенности производительности
2. в ADB  используется стандартный SQL. Реализация своя (antlr). Протокол Postgres, схема хранится как в Postgres. Отличия от PG имеются в обе стороны от совместимости.

Листнеры и нотификаторы

1. AStorage — можно подписаться на изменение данных, для принятых данных (commited)  будет приходить уведомление (в PG есть LISTEN & NOTIFY — похожим образом работает)
2. ADB — нет уведомлений

Индексы

1. AStorage — индексы есть, и если их задать, то их обновление происходит автоматически при изменении основных данных. индексируются только «touch» данные — само переиндексирование  не происходит, если менять индексы или создавать их когда данные уже есть
2. ADB — индексы есть и все работает как в обычной БД. для ADB, будет переиндексация при создании индексов

Согласованность. Архитектура отличается у V2 и V3

1. AStorage использует Paxos для данных и статическая (сторонняя) конфигурация
2. ADB использует Paxos и Gossip на низком уровне и MVCC на верхнем

Остальные распределенные DB чаще используют Raft чем Paxos. Что лучше ? Если у нас MVCC то нам вообще не нужен никакой алгоритм консенсуса для данных, только для транзакций. 

У Raft есть одна неизлечимая  «болячка» — сложность управления многими «Raft’ами» в кластере. Если использовать протокол консенсуса  только для транзакций, то Paxos проще и надежнее.

Выделим такие отличия:

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

Транспорт (сетевой транспорт и сериализация)

1. AStorage.  Мы использовали Aeron для обмена данными между узлами системы! Это позволяет увеличить скорость операций в KV узле до миллиона в секунду и более на специальном железе .  Это дерзко и очень современно, но таких нагрузок для тестов даже не найти, кажется, что такая производительность никому не нужна 🙁
2. в ADB (Acapella V3) используется обычный GRPC. Aeron и GRPC приближаются друг к другу на «не маленьких»  пакетах данных. История с Aeron труднее в плане горячего обновления версий узлов. GRPC гибче в этом смысле.

Конкуренты

Astorage (как проприетарные так и OpenSource)

1. Azure CosmosDB
2. Amazon DynamoDB
3. MongoDB
4. FoundationDB
5. TiKV
6. YugaByteDB
7. FAUNA

ADB

1. Google Spanner & Google F1
2. CockroachDB
3. VoltDB
4. NuoDB
5. TiKV
6. Clustrix
7. TransLattice Elastic Database (TED)   (FBI use it — информации не найти теперь)

Можете хотя бы крупных пощёлкать, я старался вбивал много ссылок.

Поддержка

1. AStorage закончен и поддерживать его больше не планируем.
2. ADB развивается и поддержка будет

Ну последний пункт совсем как бы совсем уже навязывает ответ, что это не версии, а разные продукты… и названия видимо надо разные.

Ну хорошо, тогда другой вопрос: «делать AStorage OpenSource или нет ?» — зацените его возможности, они вполне выдающиеся.