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

Question

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

活动是这样的:

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

问题在于,与Twitter和其他一些系统不同,我不能简单地将活动附加到对活动感兴趣的每个用户的列表中 - 如果我能看起来Redis非常适合(使用其列表操作).

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

• 按相反日期顺序拉动您关注的一组或一组人的活动("John"和"Jane")
• 以反向日期顺序拉动事物(如"培根")的活动
• 按活动类型过滤("收藏","评论")
• 至少存储3000万个活动
• 理想情况下,如果您添加或删除了您关注的人,您的活动流将反映更改.

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

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

更新2009年11月:回答我自己的问题还为时过早,但我目前的解决方案是坚持使用MySQL,但使用Redis进行扩充,以便快速访问新的活动流数据.我在这里回答的更多信息:如何在社交网络中实现活动流 ...

2014年8月更新:多年后,我仍然使用MySQL作为记录系统,并使用Redis快速访问每个用户的最新活动.由于pt-online-schema-change,处理大规模MySQL表上的模式更改已成为一个非问题

Answer 1

在你完全了解情况之前,我确实建议继续使用MySQL(或RDBMS).

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

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

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

编辑:其他一些观点:

• 密钥/值数据库,如Cassandra,Voldermort等,通常不支持二级索引
• 因此,您无法进行CREATE INDEX
• 他们中的大多数也不进行范围扫描(甚至在主索引上),因为他们使用散列来实现分区(他们大多数都这样做).
• 因此他们也没有范围到期(DELETE FROM tbl WHERE ts <NOW() - INTERVAL 30 DAYS)
• 您的应用程序必须自行完成所有这些操作或在没有它的情 二级指数真的是杀手锏
• ALTER TABLE ... ADD INDEX需要相当长的时间,例如MySQL有一个大表,但至少你不必写很多代码来做.在"nosql"数据库中,它也需要很长时间但是你还必须编写大量代码来维护新的二级索引,使其正确到期,并修改你的查询以使用它.

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

Answer 2

我还计划放弃 SQL。我一直在关注CouchDB，它看起来很有前途。考虑到您的需求，我认为所有这些都可以使用 CouchDB 视图和列表 api 来完成。