EC2服务器或AWS SimpleDB上的MongoDB？

Question

什么情况下更有意义 - 安装了多个使用MongoDB的EC2实例，还是使用Amazon SimpleDB Web服务？

在MongoDB中有多个EC2实例时，我有自己设置实例的问题。

当使用SimpleDB时，我有问题将我锁定到Amazons数据结构的权利？

发展方面有什么不同？我不应该只能切换服务层的DAO，写入MongoDB或AWS SimpleDB？

Answer 1

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

如果您需要更广泛的查询选项，并且读取率高且数据量不大，mongodb会更好。但对于耐久性，您至少需要使用2个mongodb服务器实例作为主/从。否则，您可能会丢失数据的最后一分钟。可伸缩性是手动的。它比simpledb快得多。 Autosharding在1.6版本中实现。

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

另一个选项是hadoop的大数据，但它不像其他人一样实时，您可以使用hadoop进行数据仓库。 cassandra或mongo都没有交易，所以如果你需要交易，postgresql更适合。另一种选择是亚马逊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的斗争中，您会发现（根据我在过去几天亲自参与的测试）。

卡桑德拉：

• 缩放/冗余是非常核心的
• 配置可能会非常激烈
• 做报告，你需要映射简化，对于需要运行一个Hadoop层。这是一个痛苦的配置和更大的痛苦，以获得高性能。

的MongoDB：

• 配置是比较容易的（即使是新的分片，本周）
• 冗余仍然是 “到达那里”
• 的map-reduce是内置的，它的容易获取数据。

老实说，考虑到我们10s的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
  • 最大响应大小选择（数据S的最高金额可以回到你） - 1Mb的
• 小号supports only a few languages（Java，PHP，Python和Ruby，.NET），M supports way more
• 都支持REST
• S的查询语法非常类似于SQL（但功能较弱）。随着M你需要学习一种新的语法看起来像JSON（也是直接了解基础知识）
• 与M你必须学习你如何架构你的数据库。因为很多人认为无模式意味着你可以在数据库中扔掉任何垃圾并轻松提取这些垃圾，他们可能会感到惊讶的是，垃圾入侵，垃圾出来的格言。我认为S也是一样，但不能肯定地要求它。
• 都不允许区分大小写的搜索。在M中，您可以使用regex以某种方式（丑陋/无索引）克服此限制，而不必引入额外的小写字段/应用程序逻辑。
• 在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支持丰富的查询语言。