我已经有过MongoDB,CouchDB,Redis,Tokyo Cabinet和其他NoSQL数据库的经验.最近我偶然发现了Riak,它对我来说非常有趣.为了开始使用它,我决定写一个小的Twitter克隆,NoSQL World中的"hello world".要获得完全可用的克隆,有必要按时间顺序排序推文.在阅读了Riak文档之后,我发现Map-Reduce是这项工作的正确工具.在我的开发环境中它运行得很好,但是生产中的性能如何,有数百个并行查询？是否有其他的,可能更快的方法来排序数据,还是可以以有序的形式存储数据(如Cassandra)？
我想我找到了另一个解决这个问题的方法 - 一个简单的链表.因此,一个可能的实现可能是,每个用户都获得他/她自己的"时间线桶",其中存储了与推文 - 数据本身的链接(推文被单独存储在"推文"桶中).如您所知,此时间轴存储桶必须包含名为"first"的键,该键链接到最新的时间轴对象,并且是列表的起点.要在时间轴中插入新推文,只需在时间轴存储桶中插入一个新项目,将此新项目的"下一个"链接设置为"第一个" - 项目,然后将新项目设置为"第一个".
简而言之:像在链表中那样插入项目...
与Twitter一样,个人时间线只显示向用户显示的20条推文.要收到最后20条推文,只需要2个查询.为了加快速度,第一个查询使用Riak的链接行走能力来获取最新的20个对象,标记为"next".最后,第二个和最后一个查询使用第一个查询计算的键来接收推文本身(使用map/reduce).
要删除您刚刚取消关注的用户的推文,我会使用Riak 1.0的二级索引功能来接收相关的时间轴对象/推文.
小智 2
如果不重写 Riak 核心部分，就不可能在 Riak 中以有序形式存储数据。数据大致按照桶+键的顺序存储。实际顺序取决于您用于 Riak 的后端存储机制。
Riak 1.0 的一些功能也可能对您有所帮助。对二级索引的支持以及对 MapReduce 操作的改进 - 特别是，它们在高度并发的场景中表现得更好。
Alexander Sulars与 Riak 一起写了一篇关于分页的文章。它很好地概述了问题。Yammer 还广泛使用 Riak，他们的两位工程师在 Yammer 上整理了有关 Riak 的演示文稿。它没有涉及很多实施细节，但您可以了解很多有关他们如何设计解决方案的信息。
结合二级索引查询和MapReduce可以非常轻松地解决您的问题。