NoSQL作为发布 - 订阅/多读者队列的存储吗?
寻找以下问题的存储溶液,优选与一些的NoSQL般的速度和可扩展性:NoSQL作为发布 - 订阅/多读者队列的存储吗?
-
活动。其中很多,每个事件的数据很少。这是我们需要存储的。
- 没有必要精确保持事件到达的顺序。
这将是很好不存储每个事件的多个拷贝(如在每个观察者单独的存储)。
-
观察员。他们几个(< 50)他们需要阅读的事件
以自己的节奏(拉模型)
- 以“让我读事件的下一块” API
最好
每个观察者都需要阅读每个事件(最终)
不保证他们多久会提出更改。在阅读之前可能需要存储大量事件。
在RDBMS你可能只是编号的事件顺序,并记住“最后读不”每一个观察者。在交易某些ACID时,是否有可能实现类似的操作来提高可扩展性&?
到目前为止Redis的,其名单看起来不错 - 我应该看什么好?
我认为Redis的列表是一个不错的选择。我会为每个观察者名单,虽然去 - 这样,你有O(1)阅读并RPUSH/LPOP写,当所有观察家都收到他们的事件自动从系统中消失。
可以减少通过只存储在每个列表的事件ID每一个观看所需的存储空间,不过那么你将需要保留一个计数器,每个事件,以确定它可以从系统中删除。
要与一个列表落实,建立具有每经过一个事件被添加到列表的头部时间的计数器。还为每个客户设置一个计数器,指示他们收到了多少事件。这些差异是您需要从列表中获得的项目数量。
这种方法的缺点是,新项目可以被添加到列表中,你检查柜台后。你可以通过从列表的尾部开始计算,但是这是O(N)而不是O(1)。您可以通过从列表中修剪接收到的事件来减少N,并且还可以为尾部位置维护一个计数器 - 工作的效果取决于观察者离线时可以累积的事件数量。
你可以看看它是如何在做Tarantool,用一个Lua程序,以保持一个环形缓冲区事件: https://github.com/mailru/tntlua/blob/master/notifications.lua
谢谢。 Redis的列表确实看起来很合适。我唯一怀疑Redis的是它的内存限制(RAM很便宜,但可能不是*便宜:-)) – 2011-02-08 09:08:32