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

我建议查看有关Why databases suck for messaging的演示文稿，其主要针对的原因是您不应该使用MySQL等数据库进行消息传递。

我认为在这种情况下，CouchDB的changes feed可能会非常方便，尽管您可能还需要根据查询消息元数据创建一些更复杂的views。如果速度至关重要，请尝试查看速度非常快的redis，并附带pub/sub功能。具有它的即席查询支持的MongoDB也可能是这个用例的一个不错的解决方案。

Answer 3

我认为您可以随时随地存储元数据！牺牲存储以获得更快的检索时间可能是最佳选择。请注意，如果您需要更改用户的元数据并将其传播到所有消息，则可能会变得复杂。你应该考虑可能发生的频率，你是否真的需要更新所有的消息记录，并根据它是否值得为了减少查询而付出代价（这可能是值得的），但这取决于您系统的具体情况。）

我同意@Andrej_L认为Hbase不是解决此问题的正确方法。出于同样的原因，卡桑德拉陷入其中。

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

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

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

Answer 4

根据我对Hbase的经验并不适合您的应用程序。这是因为：

默认情况下不包含二级索引（您应该安装插件或类似的东西）。因此，您只能通过主键进行有效搜索。我已经使用hbase和其他表实现了二级索引。因此，你不能在在线应用程序中使用这个，因为要获得结果你应该运行map / reduce job，这将花费很多时间来处理数百万的数据。
支持和调整此数据库非常困难。为了有效的工作，你将使用HBA与Hadoop，它是必要的强大的计算机或几个。
当你需要对大量数据进行聚合报告时，Hbase非常有用。看来你不需要。

Answer 5

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

听起来你需要一个连接，所以你几乎可以忘记CouchDB，直到他们整理出已经处理过的多视图代码（实际上并不确定它仍在使用）。

Answer 6

Riak可以尽快查询，具体取决于节点

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

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

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

Redis将全速杀死，但它完全存储在RAM中

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

哪个是正确的工作数据库？

6 个答案: