MongoDB vs. Cassandra

我正在评估什么可能是最好的迁移选择。

目前，我使用的是分片MySQL（水平分区），我的大部分数据存储在JSON blob中。我没有任何复杂的SQL查询（自从我对数据库进行分区后已经迁移了）。

现在，似乎MongoDB和Cassandra都是可能的选择。我的情况：

  • 在每个查询中大量读取，较少的常规写入
  • 不担心“大规模”可扩展性
  • 更关心简单的设置、维护和代码
  • 最小化硬件/服务器成本
314295 次浏览
小开

我没有用过Cassandra，但我用过MongoDB，觉得它很棒。

如果你追求简单的设置，就是这样：你只需untar MongoDB并运行mongod守护进程，就是这样……它正在运行。

显然这只是一个开始，但要让你开始很容易。

小开

我昨天看了一个关于mongoDB的演示。我可以肯定地说，设置是“简单的”，就像打开它并启动它一样简单。完成。

我相信mongoDB和cassandra几乎可以在任何常规的linux硬件上运行，因此您应该不会在该领域遇到太大障碍。

我认为在这种情况下，在一天结束时，它将归结为你个人觉得哪个更舒服，哪个有你更喜欢的工具集。就MongoDB的演示而言，演示者表示MongoDB的工具集非常轻，并且没有许多（他们说真的有）类似于MySQL可用的工具。这当然是他们的经验所以YMMV。我喜欢MongoDB的一件事是它似乎有很多语言支持（Python和. NET是我主要使用的两个）。

使用mongoDB的网站列表很漂亮令人印象深刻，我知道twitter刚刚切换到使用cassandra。

小开
最佳答案

在每个查询中大量读取，更少的常规写入

这两个数据库都在热数据集适合内存的读取上表现良好。两者都强调无连接数据模型（并鼓励反规范化），并且都提供文档或行上的索引，尽管MongoDB的索引目前更灵活。

无论您的数据集增长多大，Cassandra的存储引擎都提供恒定时间写入。在MongoDB中写入更成问题，部分原因是基于b树的存储引擎，但更多的原因是它的多颗粒度锁定。

对于分析，MongoDB提供了自定义map/duce实现；Cassandra提供原生Hadoop支持，包括Hive（基于Hadoop map/duce构建的SQL数据仓库）和猪（一种特定于Hadoop的分析语言，许多人认为它比SQL更适合map/duce工作负载）。Cassandra还支持使用Spark。

不担心“大规模”可扩展性

如果你正在寻找单个服务器，MongoDB可能更适合。对于那些更关心扩展的人来说，Cassandra的无单点故障架构将更容易设置和更可靠。（MongoDB的全局写锁也往往变得更加痛苦。）Cassandra还可以对复制的工作方式进行更多的控制，包括对多个数据中心的支持。

更关心简单的设置、维护和代码

两者的设置都很简单，对于单个服务器都有合理的开箱即用默认值。在多服务器配置中设置Cassandra更简单，因为没有特殊角色节点需要担心。

如果您目前正在使用JSON blob，那么MongoDB非常适合您的用例，因为它使用BSON来存储数据。您将能够拥有比当前数据库更丰富、更可查询的数据。这将是Mongo最重要的胜利。

小开

我已经广泛使用MongoDB（在过去的6个月里），构建了一个分层数据管理系统，我可以保证设置的简单性（安装、运行、使用！）和速度。只要你仔细考虑索引，它绝对可以快速发展。

我推测Cassandra由于与Twitter等大型项目一起使用，具有更好的缩放功能，尽管MongoDB团队正在那里进行奇偶校验。我应该指出的是，我没有在试运行阶段之后使用Cassandra，所以我不能说细节。

当我们评估非关系型数据库时，对我来说真正的摇摆者是查询——Cassandra基本上只是一个巨大的键/值存储，查询有点繁琐（至少与MongoDB相比），所以为了性能，你必须复制相当多的数据作为一种手动索引。另一方面，MongoDB使用“示例查询”模型。

例如，假设你有一个包含用户的集合（MongoDB的说法相当于RDMS表）。MongoDB将记录存储为文档，基本上是二进制JSON对象。例如：

{
FirstName: "John",
LastName: "Smith",
Email: "john@smith.com",
Groups: ["Admin", "User", "SuperUser"]
}

如果您想找到所有拥有管理员权限的名为Smith的用户，您只需创建一个新文档（在管理控制台使用Javascript，或在生产环境中使用您选择的语言）：

{
LastName: "Smith",
Groups: "Admin"
}

…然后运行查询。就是这样。添加了用于比较、RegEx过滤等的运算符，但这一切都非常简单，基于Wiki的留档非常好。

小开

我可能会成为一个奇怪的人，但我认为你需要继续使用MySQL。你还没有描述你需要解决的真正问题，而MySQL/InnoDB即使对于blob/json数据也是一个出色的存储后端。

Web工程师有一个常见的技巧，就是一旦意识到不是所有的RDBMS特性都被使用，就尝试使用更多的非关系型数据库。这本身并不是一个很好的理由，因为大多数非关系型数据库通常都有相当差的数据引擎（MySQL称之为存储引擎）。

现在，如果您不是那种人，那么请指定MySQL中的失踪是什么，并且您正在寻找不同的数据库（例如，自动分片，自动故障转移，多主复制，集群中较弱的数据展示一致性保证以更高的写入吞吐量回报等）。

小开

为什么要在传统数据库和非关系型数据库数据存储之间进行选择？两者都要使用！非关系型数据库解决方案（超出初始学习曲线）的问题是缺乏事务-您对MySQL进行所有更新并让MySQL填充非关系型数据库数据存储以供读取-然后您可以从每种技术的优势中受益。这确实增加了更多的复杂性，但您已经拥有MySQL方面-只需添加MongoDB，Cassandra等即可。

非关系型数据库数据存储通常比传统数据库更好地扩展相同的其他规格-这就是Facebook，Twitter，Google和大多数初创企业使用非关系型数据库解决方案的原因。


提交答案