16

我想知道其他一些非关系数据库是否适合活动流 - 有点像你在 Facebook、Flickr ( http://www.flickr.com/activity ) 等上看到的。现在，我'正在使用 MySQL，但它非常费力（我有数千万条活动记录），而且由于它们基本上是只读的，一旦写入并且总是按时间顺序查看，我认为替代数据库可能会运作良好。

这些活动是这样的：

  • 下午 6 点：约翰最喜欢培根
  • 下午 5:30：简评论了雪崩
  • 5:15 PM：简将培根的照片添加到她的相册

问题是，与 Twitter 和其他一些系统不同，我不能简单地将活动附加到每个对活动感兴趣的用户的列表中——如果可以的话，Redis 会很合适（使用它的列表操作）。

我需要能够执行以下操作：

  • 以相反的日期顺序为您关注的一组或部分人（“John”和“Jane”）提取活动
  • 以相反的日期顺序拉动事物（如“培根”）的活动
  • 按活动类型过滤（“收藏”、“评论”）
  • 存储至少 3000 万个活动
  • 理想情况下，如果您添加或删除了您关注的人，您的活动流将反映更改。

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

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

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

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

4

6 回答 6

5

在您完全了解情况之前，我真的建议您继续使用 MySQL（或 RDBMS）。

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

如果您需要优化某些范围扫描，您可以使用（例如）InnoDB 通过明智地选择（隐式集群）主键和/或在必要时进行非规范化来做到这一点。

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

编辑：其他几点：

  • Cassandra、Voldermort等key/value数据库一般不支持二级索引
  • 因此，您不能执行 CREATE INDEX
  • 他们中的大多数也不进行范围扫描（即使在主索引上），因为他们使用散列来实现分区（他们大多这样做）。
  • 因此他们也不做范围到期（从 tbl 中删除 WHERE ts < NOW() - INTERVAL 30 DAYS）
  • 您的应用程序必须自己完成所有这些工作，或者在没有它的情况下进行管理；二级索引真的是杀手锏
  • ALTER TABLE ... ADD INDEX 在例如 MySQL 的大表中需要相当长的时间，但至少您不必编写太多代码来执行此操作。在“nosql”数据库中，也需要很长时间，但您还必须编写大量代码来维护新的二级索引，正确过期，并修改查询以使用它。

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

于 2009-08-27T20:25:08.657 回答
2

我还计划放弃 SQL。我一直在看CouchDB，它看起来很有希望。看看您的要求，我认为一切都可以通过 CouchDB 视图和列表 api 来完成。

于 2009-08-27T18:21:30.437 回答
2

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

我怀疑您会找到任何其他可以执行此操作的数据存储以及现代商业 DBMS（Oracle、SQLServer、DB2 等）或任何可以比 MySql 更好地完成此操作的开源工具。

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

于 2009-09-07T06:43:18.427 回答
1

对于一个项目，我曾经需要一个简单的数据库，它可以快速进行查找，并且可以进行大量查找并且只是偶尔写入。我刚刚结束了编写自己的文件格式。

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

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

于 2009-08-27T19:31:45.503 回答
1

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

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

我刚刚开始探索使用 CouchDB 构建“活动流”解决方案，由于范式不同，我对流程的思考必须从 SQL 思维转变。

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

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

于 2009-09-15T20:21:08.323 回答
1

我建议学习消息队列技术。有几个可用的开源选项，还有强大的商业产品，可以提供你描述为小零食的体积。

于 2009-09-07T05:53:08.153 回答