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

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 是否是个好主意。当你有机会时不使用 Shiny 的新东西是很无聊的，但相信我，当你把自己涂在角落里时，这很糟糕，因为你认为新玩具会做它在盒子上说的一切。没有任何事情像博客文章中所说的那样有效。

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

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

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

最后，别听我瞎说，自己试一下，看看效果如何，感受如何。确保你尽可能努力地加载它，并确保你测试你将要做的一切。我犯了一个错误，没有测试当您在 MongoDB 中删除大量数据时会发生什么，并为此付出了高昂的代价。