51

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

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

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

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

4

3 回答 3

58

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 版本的发布，二级索引将成为可能。您也可以从其中任何一个开始，并在将来必要时替换它。

于 2010-08-02T23:41:45.713 回答
21

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

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

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

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

卡桑德拉：

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

MongoDB：

  • 配置相对容易（即使对于新的分片，本周）
  • 冗余仍在“到达那里”
  • Map-reduce 是内置的，很容易取出数据。

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

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

于 2010-08-03T19:57:34.133 回答
1

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

我将对 SimpleDB 使用 S，对 Mongo 使用 M。

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

您应该考虑的最重要的事情之一是 SimpleDB 具有非常基本的查询语言。甚至不支持基本的东西，如,group by以及数据操作，所以功能并不比 Redis/Memcached 丰富。另一方面，Mongo 支持丰富的查询语言。sum averagedistinct

于 2015-09-27T01:44:06.177 回答