хорошее, современное и «помогающее принять решение» объяснение того, как выбрать ядро ​​базы данных NoSQL для хранения всех событий в приложении, разработанном CQRS.

В настоящее время я новичок во всех вещах, связанных с NoSQL (но учусь): пожалуйста, будьте ясны и не стесняйтесь объяснять свою точку зрения (почти слишком) точно. Этот пост может заслуживать других новичков, как я.

Эта база данных будет:

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

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

Не требуется никакой связи между сущностями (как в СУБД), за исключением, может быть, идентификатора пользователя / GUID (я не знаю, критично ли это или еще нужно)

Получать события, содержащие от 3 до 10 «столбцов» (идентификатор последовательности, имя события, дата и время, набор параметров JSON / двоичного кода, некоторая контекстная информация ..). Не ориентируя свою точку зрения на базу данных, ориентированную на столбцы, она может быть ориентирована на документы, если она соответствует всем другим требованиям.

Использовать в качестве очереди или отправлять / читать из внешней системы AMQP, такой как RabbitMQ или ZeroMQ (эта часть еще не работала, если вы также можете аргументировать / объяснять ..), так как проекции представления будут построены на событиях

Нужна какая-то фильтрация по идентификатору последовательности, напримерSELECT * FROM events WHERE sequence_id > last_sequence_id для абонентов (или систем очередей), чтобы иметь возможность синхронизации с заданной точки

Я слышал о HBase для хранения событий CQRS, но, может быть, подойдет MongoDB? Или даже Elasticsearch (не ставил бы на это ..)? Я также открыт для RDBMS для согласованности и доступности .. но как насчет части допуска раздела ...?

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