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