传统关系数据库替代活动流的替代方案

Question

我想知道其他一些非关系数据库是否适合活动流 - 有点像你在Facebook上看到的，Flickr（http://www.flickr.com/activity）等等。现在，我正在使用MySQL，但它非常繁琐（我有数以千万计的活动记录），因为它们基本上是只读的一次，并且总是按时间顺序查看，我认为另一个DB可能运行良好。

活动如下：

• 下午6点：约翰赞成培根
• 下午5:30：Jane对Snow Crash发表评论
• 下午5:15：Jane在她的专辑
中添加了培根的照片

与Twitter和其他一些系统不同，我不能简单地将活动附加到每个对活动感兴趣的用户的列表中 - 如果我能看起来像Redis would be a good fit（带有列表操作） ）。

我需要能够做到以下几点：

• 以相反的日期顺序拉动您所关注的人（“John”和“Jane”）的或子集的活动
• 以反向日期顺序拉动某物（如“培根”）的活动
• 按活动类型过滤（“收藏”，“评论”）
• 至少存储3000万个活动
• 理想情况下，如果您添加或删除了您关注的人，您的活动流就会反映此更改。

我一直用MySQL做这件事。我的“活动”表格尽可能紧凑，键尽可能小，并且它被适当地索引。它有效，但它只是感觉这个工作的错误工具。

是否有人在传统的RDBMS之外做这样的事情？

2009年11月更新：现在回答我自己的问题还为时过早，但我目前的解决方案是坚持使用MySQL，但需要使用Redis进行扩充，以便快速访问新的活动流数据。我在这里的回答中提供了更多信息： How to implement the activity stream in a social network ...

2014年8月更新：多年以后，我仍然使用MySQL作为记录系统，并使用Redis快速访问每个用户的最新活动。由于pt-online-schema-change

，处理大规模MySQL表上的架构更改已成为一个问题

Answer 1

在你完全了解情况之前，我确实建议继续使用MySQL（或RDBMS）。

我不知道您计划使用多少性能或大量数据，但30M行并不是很多。

如果您需要优化某些范围扫描，可以通过明智地选择（隐式聚类）主键和/或在必要时进行非规范化来（例如）InnoDB执行此操作。

但与大多数事情一样，首先让它工作，然后修复在生产级硬件上的性能测试实验室中检测到的性能问题。

---

编辑：其他一些观点：

• 密钥/值数据库，如Cassandra，Voldermort等，一般不支持二级索引
• 因此，您无法执行CREATE INDEX
• 他们中的大多数也不进行范围扫描（即使在主索引上），因为他们使用散列来实现分区（他们大多数都是这样做）。
• 因此他们也没有范围到期（DELETE FROM tbl WHERE ts＆lt; NOW（） - INTERVAL 30 DAYS）
• 您的申请必须自行完成所有这些工作或在没有它的情况下进行管理二级索引真的是杀手
• ALTER TABLE ... ADD INDEX需要相当长的时间，例如MySQL有一个大表，但至少你不必写很多代码来做它。在“nosql”数据库中，它也需要很长时间，但是你还必须编写大量代码来维护新的二级索引，使其正确到期，并修改你的查询以便使用它。

简而言之......您不能使用键/值数据库作为避免ALTER TABLE的快捷方式。

Answer 2

我也打算放弃SQL。我一直在看CouchDB，看起来很有希望。看看你的要求，我认为所有这些都可以通过CouchDB视图和列表api来完成。

Answer 3

在我看来，您想要做的事情 - 以几种不同的方式查询大量数据并对结果进行排序 - 正是RDBMeS的设计目标。

我怀疑你会发现任何其他可以做到这一点的数据存储区以及现代商业DBMS（Oracle，SQLServer，DB2等）或任何可以完成的opn源工具 这比MySql更好。

你可以看一下Googles BigTable，它实际上是一个关系型数据库 它可以为你的程序提供一个“对象”的个性。它非常适合自由格式文本 搜索和复杂谓词。整个事情（至少你可以下载的版本）是用Python实现的，我怀疑它会在查询马拉松中击败MySql。

Answer 4

对于一个项目，我曾经需要一个简单的数据库，它快速进行查找，并且会进行大量的查找，偶尔也会进行写入。我最后编写了自己的文件格式。

虽然你也可以这样做，但它非常复杂，特别是如果你需要从网络服务器支持它。使用Web服务器，您至少需要保护对文件的每次写入，并确保可以从多个线程读取它。这种文件格式的设计是你应该通过大量的测试和实验尽可能好地完成的。对于这种风格的网络项目来说，一个小错误可能是致命的，但是如果你使它工作，它可以很好地工作并且非常快。

但是对于99.999％的情况，您不需要这样的自定义解决方案。更新硬件，迁移到Oracle，SQL Server或InterBase，使用专用数据库服务器，使用更快的硬盘，安装更多内存，升级到64位系统更容易。这些是以更少的努力提高性能的更通用的技巧。

Answer 5

我建议您了解message queue技术。有几种开源选择，还有强大的商业产品，可以提供您描述为小食品的量。

Answer 6

CouchDB是无架构的，快速检索大量数据相当简单，因为您只使用索引。您不是每次“查询”数据库，而是仅检索匹配的键（预先排序使其更快）。

每次将新数据输入数据库时​​，“视图”都会重新编入索引，但这会对用户透明地进行，因此虽然生成更新视图可能会有延迟，但检索时几乎不会有任何延迟结果。

我刚刚开始探索使用CouchDB构建“活动流”解决方案，并且因为范例不同，我对这个过程的思考必须从SQL思维转变。

而不是弄清楚如何查询我想要的数据然后在页面上处理它，而是生成一个按日期键入所有文档的视图，这样我就可以轻松地创建多组数据，只需使用适当的日期key，基本上同时运行多个查询，但性能没有下降。

这是活动流的理想选择，我可以按日期隔离所有内容，或者与日期隔离一起隔离我可以进一步过滤特定子类型的结果等 - 通过根据需要创建视图，并且因为视图本身只是使用javascript和CouchDB中的所有数据都是JSON，几乎所有内容都可以在客户端完成，以呈现您的页面。