Будущие планы движка хранения Cassandra

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

В отличие от MySQL/MariaDB, Cassandra не подходит для обработки транзакций. (единственный ограниченный сценарий, который они хорошо обрабатывают, это базы данных с только добавлением).

Вместо этого они сосредоточиваются на возможности предоставления аналитики в реальном времени. Это достигается с помощью следующего сочетания:

1. Операции вставки/обновления сводятся к вставке новой версии, их реализация (SSTree) позволяет выполнять множество обновлений с низкой стоимостью

1. Модель данных ориентирована на денормализованные данные, документация Cassandra и пользовательские истории все упоминают практику создания/заполнения отдельной семейства столбцов (=таблицы) для каждого типа запросов, которые вы собираетесь выполнить.

Другими словами, Cassandra поощряет создание/использование материализованных представлений. Наличие большого количества материализованных представлений делает обновления дорогими, но их низкая стоимость и отсутствие конфликтов должны компенсировать это.

Как использовать Cassandra вместе с базой данных SQL? Я могу придумать такие варианты использования:

вариант использования 1

1. «OLTP как в SQL» хранится в базе данных SQL.
2. Данные, которые слишком велики для базы данных SQL (например, веб-отображения или клики), хранятся в Cassandra, но также могут быть доступны из SQL.

В качестве примера можно привести интернет-магазин, который предоставляет в реальном времени данные об аналитике, такие как «люди, которые просматривали этот товар, также просматривали...», или «самые продаваемые товары в этой категории сегодня — это...», и т. д.

В целом, CQL (Cassandra Query Language) позволяет запрашивать данные Cassandra в формате, похожем на SQL.

Доступ через движок хранения дополнительно позволит:

1. получить все данные с одной точки, а не строки
2. соединения между данными SQL и Cassandra *могут* быть более эффективными благодаря пакетному доступу к ключам (это еще предстоит выяснить)
3. ??

вариант использования 2

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

Cassandra используется только как ускоритель для аналитических запросов. Cassandra не позволит произвольных, импровизированных запросов типа DSS, она потребует от DBA создания и поддержки соответствующих семейств столбцов (однако, она должна давать практически мгновенные ответы на аналитические вопросы).

Задачи, для которых в настоящее время нет очевидных решений:

1. Нет способа реплицировать данные из MySQL/MariaDB в Cassandra. Было бы неплохо, если бы обновление данных в MySQL вызывало соответствующие вставки во все необходимые семейства столбцов в Cassandra.
2. ...