EC2 服务器上的 MongoDB 还是 AWS SimpleDB？

Question

哪种方案更有意义 - 托管多个安装了 MongoDB 的 EC2 实例，或者更确切地说是使用 Amazon SimpleDB Web 服务？

当使用 MongoDB 拥有多个 EC2 实例时，我遇到了自己设置实例的问题。

在使用 SimpleDB 时，我遇到了将我锁定在 Amazon 数据结构中的问题，对吗？

在发展方面有什么不同？难道我不能只切换服务层的 DAO 以写入 MongoDB 或 AWS SimpleDB？

Answer 1

SimpleDB 有一些可扩展性限制。您只能通过分片进行扩展，它的延迟比 mongodb 或 cassandra 高，它有吞吐量限制，而且价格高于其他选项。可扩展性是手动的（你必须分片）。

如果你需要更广泛的查询选项并且你有很高的读取率并且你没有这么多的数据，那么 mongodb 会更好。但是为了持久性，您需要使用至少 2 个 mongodb 服务器实例作为主/从。否则，您可能会丢失最后一分钟的数据。可扩展性是手动的。它比 simpledb 快得多。自动分片在 1.6 版本中实现。

Cassandra 的查询选项较弱，但与 postgresql 一样耐用。它与 mongo 一样快，并且在更大的数据量上更快。写操作比 cassandra 上的读操作快。它可以通过触发 ec2 实例自动扩展，但您必须稍微修改配置文件（如果我没记错的话）。如果你有 TB 的数据，cassandra 是你最好的选择。无需对您的数据进行分片，它是从第一天开始设计的。您可以为所有数据拥有任意数量的副本，如果某些服务器已死，它将自动从活动服务器返回结果并将死服务器的数据分发给其他服务器。它具有高度的容错性。您可以包含任意数量的实例，它比其他选项更容易扩展。它具有强大的 .net 和 java 客户端选项。它们具有连接池、负载平衡、死服务器标记……

另一个选项是用于大数据的 hadoop，但它不像其他选项那样实时，您可以将 hadoop 用于数据仓库。 cassandra 或 mongo 都没有事务，所以如果你需要事务，postgresql 更合适。另一种选择是 Amazon RDS，但它的性能很差，价格也很高。如果您想使用数据库或 simpledb，您可能还需要数据缓存（例如：memcached）。

对于 web 应用程序，如果您的数据很小，我推荐 mongo，如果它是大的 cassandra 更好。您不需要 mongo 或 cassandra 的缓存层，它们已经很快了。我不推荐 simpledb，它也会像你说的那样把你锁在亚马逊上。

如果您使用 c#、java 或 scala，您可以为 mongo、mysql、cassandra 或其他任何数据访问层编写接口并实现它。它在动态语言中更简单（例如 rub、python、php）。如果需要，您可以为其中两个编写提供程序，并且可以通过仅更改配置在运行时更改存储，它们都是可能的。使用 mongo、cassandra 和 simpledb 进行开发比使用数据库更容易，而且它们没有模式，它还取决于您使用的客户端库/连接器。最简单的是mongo。 cassandra 中的每个表只有一个索引，因此您必须自己管理其他索引，但据我所知，随着 cassandra 的 0.7 版本的发布，二级索引将成为可能。您也可以从它们中的任何一个开始，并在将来需要时替换它。

Answer 2

我认为你有时间和速度的问题。

MongoDB / Cassandra 会快得多，但你必须投入 $$$ 才能让它们运行起来。这意味着您需要为所有这些实例运行/设置服务器实例并弄清楚它们是如何工作的。

另一方面，您不必直接按“每笔交易”成本计算，您只需为可能对大型服务更有效的硬件付费。

在 Cassandra / MongoDB 之争中，您会发现以下内容（基于过去几天我亲自参与的测试）。

卡桑德拉：

• 扩展/冗余是非常核心的
• 配置可能非常密集
• 要进行报告，您需要 map-reduce，为此您需要运行 hadoop 层。配置起来很痛苦，而要获得性能则更痛苦。

MongoDB：

• 配置相对容易（即使是新的分片，本周）
• 冗余仍在“实现目标”
• Map-reduce 是内置的，很容易取出数据。

老实说，考虑到 10 GB 数据所需的配置时间，我们最终选择了 MongoDB。我可以想象将 SimpleDB 用于“必须让这些运行”的情况。但是配置一个节点来运行 MongoDB 非常简单，可能值得跳过“SimpleDB”路线。

就 DAO 而言，Mongo 已经有大量的库。 Cassandra 的 Thrift 框架得到很好的支持。您可能可以编写一些简单的逻辑来抽象连接。但是抽象出比简单的 CRUD 更复杂的东西会更难。

Answer 3

现在 5 年后，在任何操作系统上设置 Mongo 都不难。 Documentation 很容易理解，所以我不认为设置 Mongo 是个问题。其他答案解决了可扩展性的问题，所以我将尝试从开发人员的角度来解决这个问题（每个系统有什么限制）：

我将 S 用于 SimpleDB，M 用于 Mongo。

• M 是用 C++ 编写的，S 是用 Erlang 编写的（不是最快的语言）
• M 是开源的，随处安装，S 是专有的，只能在亚马逊 AWS 上运行。您还应该 pay for a whole bunch of staff 为 S
• S 有一大堆strange limitations。 M limitations 更合理。最奇怪的限制是：
  • 域（表）的最大大小为 10 GB
  • 属性值长度（字段大小）为1024字节
  • 选择响应中的最大项目数 - 2500
  • Select 的最大响应大小（S 可以返回给您的最大数据量）- 1Mb
• S supports only a few languages (java, php, python, ruby​​, .net), M supports way more
• 两者都支持 REST
• S 的查询语法与 SQL 非常相似（但功能较弱）。使用 M，您需要学习一种类似于 json 的新语法（也可以直接学习基础知识）
• 使用 M，您必须了解如何构建数据库。因为许多人认为无模式意味着您可以在数据库中放入任何垃圾并轻松提取这些垃圾，所以他们可能会惊讶于 Junk in, Junk out 格言有效。我假设在 S 中也是如此，但不能肯定地声称它。
• 两者都不允许不区分大小写的搜索。在 M 中，您可以使用正则表达式以某种方式（丑陋/无索引）克服此限制，而无需引入额外的小写字段/应用程序逻辑。
• 只能在S中进行排序on one field
• 因为5s时间限制count in S can behave strange。如果 5 秒过去了，查询还没有完成，你会得到一个部分数字和一个允许你继续查询的令牌。应用程序逻辑负责收集所有这些数据并进行汇总。
• everything is a UTF-8 string，这使得在 S 中使用非字符串值（如数字、日期）非常痛苦。M 类型支持是 way richer。
• 两者都没有事务和连接
• M 支持compression，这对 nosql 存储非常有用，在该存储中，相同的字段名称会重新存储一遍。
• S 只支持一个索引，M has single, compound, multi-key, geospatial etc。
• 都支持复制和分片

您应该考虑的最重要的事情之一是 SimpleDB 具有非常基本的查询语言。即使是group by、sumaverage、distinct 等基本功能以及数据操作也不支持，因此功能并不比 Redis/Memcached 丰富。另一方面，Mongo 支持丰富的查询语言。