哪个数据库适合这项工作？

Question

我正在开发一项功能，并且可以使用关于我应该使用哪个数据库来解决这个问题的意见。

我们有一个使用 MySQL 的 Rails 应用程序。 MySQL 没有任何问题，并且运行得很好。但对于新功能，我们正在决定是否保留 MySQL。为了简化问题，我们假设有一个 User 和 Message 模型。用户可以创建消息。该消息将根据其他用户与发帖者的关联传递给其他用户。

显然，存在基于友谊的关联，但还有更多基于用户个人资料的关联。我计划将有关海报的一些元数据与消息一起存储。这样我就不必每次查询消息时都提取元数据。

因此，消息可能如下所示：

{
  id: 1,
  message: "Hi",
  created_at: 1234567890,
  metadata: {
    user_id: 555,
    category_1: null,
    category_2: null,
    category_3: null,
    ...
  }
}

当我查询消息时，我需要能够基于零个或多个元数据属性进行查询。此调用需要快速且经常发生。

由于元数据属性的数量以及查询中可以包含任何数量的事实，因此在此处创建 SQL 索引似乎不是一个好主意。

就我个人而言，我有使用 MySQL 和 MongoDB 的经验。我已经开始研究 Cassandra、HBase、Riak 和 CouchDB。我可以向那些可能做过研究的人寻求帮助，以确定哪个数据库最适合我的任务。

是的，消息表可以轻松增长到数百万行。

Answer 1

这是一个非常开放式的问题，所以我们所能做的就是根据经验提供建议。首先要考虑的是，决定使用您以前没有使用过的东西而不是使用您熟悉的 MySQL 是否是一个好主意。当你有机会时不使用闪亮的新东西是很无聊的，但相信我，当你把自己画在角落里时，这很糟糕，因为你认为新玩具会做盒子上所说的一切。没有任何事情像博客文章中所说的那样有效。

我主要有使用 MongoDB 的经验。这是一个糟糕的选择，除非你想花很多时间尝试不同的事情并意识到它们不起作用。一旦你扩大规模，你基本上就不能使用二级索引、更新和其他使 Mongo 成为一个非常好的工具的东西（其中大部分与它的全局写锁和磁盘上的数据库格式有关，它如果删除数据，并发性和碎片基本上很糟糕）。

我不同意 HBase 是不可能的，它没有二级索引，但是一旦超过一定的流量负载，您就无法使用它们。 Cassandra 也是如此（它比 HBase 更容易部署和使用）。基本上，无论您选择哪种解决方案，您都必须实现自己的索引。

您应该考虑的是，如果您需要一致性而不是可用性，反之亦然（例如，如果消息丢失或延迟有多糟糕，而用户无法发布或阅读消息有多糟糕），或者如果您要更新数据（例如，Riak 中的数据是不透明的 blob，要更改它，您需要读取它并将其写回，在 Cassandra、HBase 和 MongoDB 中，您可以添加和删除属性，而无需先读取对象）。易用性也是一个重要因素，从程序员的角度来看，Mongo 确实很容易使用，而 HBase 很糟糕，但只要花一些时间制作自己的库来封装那些讨厌的东西，那就值得了。

最后，不要听我的，尝试一下，看看它们的表现和感觉如何。确保尽可能努力地加载它，并确保测试你将要做的一切。我犯了一个错误，没有测试删除 MongoDB 中的大量数据时会发生什么，并为此付出了高昂的代价。

Answer 2

我建议您查看有关为什么数据库对于消息传递来说很糟糕的演示文稿主要针对为什么不应该使用 MySQL 等数据库进行消息传递的事实。

我认为在这种情况下，CouchDB 的 changes feed 可能会非常方便，尽管您可能还必须基于查询消息元数据创建一些更复杂的视图。如果速度很重要，请尝试查看 redis ，它非常快并且附带 pub/sub 功能。 MongoDB 及其临时查询支持也可能是此用例的一个不错的解决方案。

Answer 3

我认为您在将元数据与每条消息一起存储方面是正确的！牺牲存储空间以加快检索时间可能是正确的选择。请注意，如果您需要更改用户的元数据并将其传播到所有消息，事情可能会变得复杂。您应该考虑这种情况发生的频率，您是否真的需要更新所有消息记录，以及基于此是否值得为了减少查询而付出代价（可能是值得的，但这取决于您的系统的具体情况）。

我同意 @Andrej_L 的观点，即 Hbase 不是解决此问题的正确解决方案。出于同样的原因，卡桑德拉也陷入了困境。

CouchDB可以解决您的问题，但是您必须为要查询的任何元数据定义视图（物化索引）。如果这里不使用 MySQL 的全部目的是避免对所有内容建立索引，那么 Couch 可能也不是正确的解决方案。

Riak 将是一个更好的选择，因为它使用 Map-Reduce 查询数据。这使您可以构建任何您喜欢的查询，而无需像沙发上那样预先索引所有数据。对于 Riak 来说，数百万行不是问题 - 不用担心。如果需要，它还可以通过简单地添加更多节点来很好地扩展（并且它也可以自我平衡，所以这实际上不是问题）。

所以根据我自己的经验，我推荐Riak。然而，与您不同的是，我没有直接使用 MongoDB 的经验，因此您必须自己对 Riak 进行判断（或者也许这里的其他人可以回答这个问题）。

Answer 4

根据我的经验，Hbase 对于您的应用程序来说并不是一个好的解决方案。
因为：

1. 默认不包含二级索引（你应该安装插件或类似的东西）。因此您可以仅通过主键进行有效搜索。我已经使用 hbase 和其他表实现了二级索引。所以你不能在在线应用程序中使用这个，因为为了获得结果你应该运行map/reduce作业，这将在百万数据上花费很多时间。

2. 这个数据库的支持和调整非常困难。为了有效地工作，您将使用 HBAse 和 Hadoop，并且需要强大的计算机或几台。

3. 当您需要对大量数据进行聚合报告时，Hbase 非常有用。好像不需要。

Answer 5

由于元数据属性的数量以及任何数量都可以
包含在查询中，在这里创建 SQL 索引似乎并不像
好主意。

听起来您需要加入，因此您基本上可以忘记 CouchDB，直到他们整理出已处理的多视图代码（实际上不确定它是否仍在处理）。

Answer 6

Riak 的查询速度与您的查询速度一样快，这取决于节点

Mongo 将允许您在任何字段上创建索引，即使这是一个数组

CouchDB 非常不同，它使用存储的 Map-Reduce 构建索引（但没有reduce） ）他们称之为“视图”

RethinkDB 会让你拥有 SQL，但速度更快一点
TokuDB 也将

在速度上杀死所有 Redis，但它完全存储在 RAM 中，

单级关系可以在所有这些中完成，但每个都不同。