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实例自动扩展，但你必须稍微修改配置文件（如果我没记错的话）。如果你有太字节数据cassandra是你最好的选择。无需对数据进行分片，它是从第1天开始分发的。您可以为所有数据创建任意数量的副本，如果某些服务器已经死亡，它将自动从实时服务器返回结果并将死服务器的数据分发给其他服务器。它具有高度的容错能力。您可以包含任意数量的实例，它比其他选项更容易扩展。它具有强大的.net和Java客户端选项。它们具有连接池，负载平衡，死服务器标记，......

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

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

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

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上运行。对于S
，您还应该pay for a whole bunch of staff
• 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 maxim工作。我认为S中也是如此，但不能肯定地声称它。
• 两者都不允许不区分大小写的搜索。在M中你可以使用正则表达式（丑陋/没有索引）克服这个限制，而不引入额外的小写字段/应用程序逻辑。
S中的
• 只能进行on one field
• 因为5s timelimit 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，sum average，distinct等基本内容以及数据操作，因此功能并不比Redis / Memcached更丰富。另一方面，Mongo支持丰富的查询语言。