适用于 Google Reader 等应用程序的 NoSQL 架构
对于像 Google Reader（一对一副本）这样的应用程序，您会使用什么 NoSQL 架构？
我考虑 MongoDB、Cassandra、CouchDB、Redis、HBase 和 Riak。
What NoSQL architecture would you use for application like Google Reader (one to one copy)?
I consider MongoDB, Cassandra, CouchDB, Redis, HBase and Riak.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
答案很简单，使用您最舒服的那个。
更复杂的答案实际上在于 Google Reader 的功能细节。您可能需要的一项功能是多个索引。
每个 RSS 条目都有一个唯一的密钥、一个用户、一个 ts、一个读取标志和一些类别。当处理面向文档或键值数据库时，通常很容易获得键。但是您真正要运行的第一个查询是什么？按用户、ts、阅读列出。
嗯，这将需要一个二级索引。 AFAIK riak 和 redis 根本不支持这一点。 CouchDB 和 Cassandra 似乎有一些解决方法（视图），但仍然不容易。 MongoDB 支持二级索引“开箱即用”。
因此，您立即可以轻松地使其与 MongoDB 配合使用。
Mongo还有一系列原子操作，使得异步更新数据变得更加容易。
Easy answer, use the one you're most comfortable with.
The more complex answer really lies in the details of what Google Reader can do. One feature that you'll probably want is multiple indexes.
Each RSS entry is going to have a unique key, a user, a ts, a read flag and some categories. When dealing with document-oriented or key-value databases, it's generally easy to get the key. But what's the first query you're really going to run? List by user, ts, read.
Well, that's going to need a secondary index. AFAIK riak and redis don't support this at all. CouchDB and Cassandra seem to have some workarounds (views), but it's still not easy. MongoDB supports secondary indexes "out of the box".
So right off the bat, you're making it easy to get it working with MongoDB.
Mongo also has a series of atomic operations that makes is easier to update data asynchronously.