NoSQL как хранилище для очереди публикации-подписки / нескольких читателей? - PullRequest
1 голос
/ 04 февраля 2011

В поисках решения для хранения следующей проблемы, желательно с некоторой скоростью и масштабируемостью, подобной NoSQL:

  • События. Много их, мало данных на событие. Это то, что нам нужно хранить.

    • Нет необходимости точно соблюдать порядок поступления событий.

Было бы неплохо не хранить несколько копий каждого события (как в отдельном хранилище для каждого наблюдателя).

  • Наблюдатели. Некоторые из них (<50) Они должны прочитать события </p>

    • В своем темпе (модель тянуть)

    • Желательно с API «дайте мне следующий кусок непрочитанных событий»

    • Каждый наблюдатель должен прочитать каждое событие (в конце концов)

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

    1036 **

В СУБД вы, вероятно, просто нумеруете события последовательно и запоминаете «последнее чтение нет» для каждого наблюдателя. Возможно ли реализовать что-то подобное при обмене части ACID на скорость и масштабируемость?

Пока что Redis с его списками выглядит хорошо - что-нибудь лучше, на что мне следует смотреть?

Ответы [ 2 ]

2 голосов
/ 08 февраля 2011

Я думаю, что списки Redis - хороший выбор. Я бы пошел со списком для каждого наблюдателя - таким образом, у вас есть O (1) для чтения и записи с RPUSH / LPOP, и события автоматически исчезают из системы, когда все наблюдатели получают их.

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

Для реализации с одним списком, установите счетчик, который увеличивается каждый раз, когда событие добавляется в начало списка. Также установите счетчик для каждого клиента, показывающий, сколько событий они получили. Разница между ними заключается в количестве предметов, которые вам нужно получить из списка.

Недостатком этого подхода является то, что новые элементы могут быть добавлены в список после проверки счетчиков. Вы можете обойти это, считая от конца списка, но это O (N), а не O (1). Вы можете уменьшить N, обрезав полученные события из списка и сохранив счетчик для хвостовой позиции - насколько хорошо это будет работать, будет зависеть от того, сколько событий может накопиться, когда наблюдатель находится в автономном режиме.

0 голосов
/ 24 февраля 2012

Вы можете взглянуть на то, как это делается в Tarantool, с помощью процедуры Lua, чтобы сохранить кольцевой буфер для событий: https://github.com/mailru/tntlua/blob/master/notifications.lua

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