Какая кластерная база данных NoSQL для хранения сообщений?

Я не могу говорить от имени Кассандры или Hbase, но позвольте мне коснуться части Riak.

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

Чтобы реализовать это, вам потребуются простые операции Riak Key / Value, а также какой-то механизм индексации. Ваши варианты (в приблизительном порядке предпочтений):

1. Наборы CRDT. Если размер вашей коллекции 1-N имеет разумный размер (скажем, на пользователя меньше 50 сообщений или что-то еще), вы можете сохранить ключи дочерней коллекции в CRDT Set Data Type.

2. Поиск Riak. Если размер вашей коллекции большой, и особенно если вам нужно искать объекты в произвольных полях, вы можете использовать Riak Search. Он запускает Apache Solr в фоновом режиме и индексирует ваши объекты в соответствии с определенной вами схемой. У него отличный поиск, агрегирование и статистика, геопространственные возможности и т. Д.

3. Вторичные индексы. Вы можете запустить Riak поверх Серверная часть хранилища eLevelDB и включите Вторичный индекс (2i) функциональность.

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

Что касается схемы, я бы рекомендовал использовать два сегмента (для описываемой вами настройки): сегмент пользователя и сегмент сообщений.

Индексируйте корзину сообщений. (Либо связав с ним поисковый индекс, либо сохранив user_key через 2i). Это позволяет вам выполнять все необходимые операции (при этом журнал сообщений не должен умещаться в памяти):

• Хранить от 1 до X сообщений для каждого зарегистрированного пользователя. После создания объекта User и получения ключа пользователя сохранить произвольное количество сообщений для каждого пользователя будет легко, они будут напрямую записываться в корзину сообщений. , каждое сообщение хранит соответствующий user_key в качестве вторичного индекса.
• Получите количество сохраненных сообщений на пользователя - нет проблем. Получите список ключей сообщений, принадлежащих пользователю (с помощью поискового запроса, путем получения объекта Set, в котором вы храните ключи, или с помощью запроса 2i для user_key). Это позволяет получить счет на стороне клиента.
• получить сразу все сообщения от пользователя - см. предыдущий элемент. Получите список ключей всех сообщений, принадлежащих пользователю (с помощью поиска, наборов или 2i), а затем получите фактические сообщения для этих ключей путем множественной выборки значений для каждого ключа (все официальные клиенты Riak имеют возможность multiFetch, сторона клиента).
• удалить сразу все сообщения пользователя - очень похоже. Получить список ключей сообщений для пользователя, выдать им удаления на стороне клиента.
• удалить все сообщения старше X месяцев - вы можете добавить индекс по дате. Затем получите все ключи сообщений старше X месяцев (с помощью поиска или 2i) и выполните для них удаления на стороне клиента.

Я вообще не могу разговаривать с Риаком, но сомневаюсь, что ты выбрал Монго. Это неплохо, если вы оставите журналирование выключенным и не будете полностью лишать его оперативной памяти.

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

Недостатком является то, что для его правильной настройки требуется много накладных расходов. Вам нужно знать Hadoop, запустить HDFS, убедиться, что ваш namenode надежен, и т. Д., Прежде чем устанавливать HBase.

Я бы рекомендовал использовать распределенное хранилище ключей / значений, такое как Riak или Couchbase, и сохранять весь журнал сообщений для каждого пользователя, сериализованный (в двоичные термины Erlang или JSON / BSON) как одно значение.

Итак, с вашими вариантами использования это будет выглядеть так:

• Хранить от 1 до X сообщений для каждого зарегистрированного пользователя - когда пользователь выходит в сеть, создается gen_server с отслеживанием состояния, который получает из хранилища и десериализует весь журнал сообщений при запуске, получает новые сообщения, добавляет их в свою копию журнала, в конце сеанса он завершается, сериализует измененный журнал и отправляет его в хранилище.
• Получить количество сохраненных сообщений на пользователя - выйти из системы, десериализовать, подсчитать; или, может быть, хранить счетчик рядом в отдельной паре k / v.
• получить все сообщения от пользователя сразу - просто вытащите его из хранилища.
• удалить сразу все сообщения от пользователя - просто удалите значение из хранилища.
• удалить все сообщения старше X месяцев - получить, отфильтровать, вернуть.

Очевидное ограничение - журнал сообщений должен умещаться в памяти.

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