EC2服务器或AWS SimpleDB上的MongoDB？
什么情况下更有意义 – 安装MongoDB来托pipe多个EC2实例，或者使用Amazon SimpleDB Web服务？
当MongoDB有多个EC2实例时，我有自己设置实例的问题。
在使用SimpleDB时，我有把我locking到Amazons数据结构的问题吗？
发展方面有什么不同？ 我不应该只能切换服务层的DAO，写入MongoDB或AWS SimpleDB？
SimpleDB有一些可扩展性限制。 您只能通过分片进行扩展，并且比mongodb或cassandra具有更高的延迟，它具有吞吐量限制，并且定价高于其他选项。 可伸缩性是手动的（你必须分割）。
如果您需要更广泛的查询选项，并且读取率高，而且数据量不大，那么mongodb会更好。 但是对于耐久性，您至less需要使用2个mongodb服务器实例作为主/从。 否则，您可能会丢失数据的最后一分钟。 可伸缩性是手动的。 它比simpledb快得多。 自动混合是在1.6版本中实现的。
Cassandra有弱的查询选项，但是和postgresql一样耐用。 它和Mongo一样快，在更高的数据量上速度更快。 写操作比cassandra上的读操作更快。 它可以通过触发ec2实例来自动扩展，但是你必须稍微修改configuration文件（如果我没有记错的话）。 如果你有太字节的数据cassandra是你最好的select。 无需分割您的数据，它是从第一天起分发的。 您可以为您的所有数据拥有任意数量的副本，并且如果某些服务器已经死亡，它将自动从活动服务器返回结果，并将死亡服务器的数据分发给其他服务器。 这是高度容错的。 您可以包含任意数量的实例，比其他选项更容易缩放。 它具有强大的.NET和Java客户端选项。 他们有连接池，负载平衡，死亡服务器的标记，…
另一个选项是hadoop的大数据，但它不像其他的实时，你可以使用hadoop进行数据仓库。 cassandra或mongo都没有交易，所以如果你需要交易postgresql是一个更好的select。 另一个select是Amazon RDS，但性能不好，价格也很高。 如果你想使用数据库或simpledb，你可能还需要数据caching（例如：memcached）。
对于networking应用程序，如果你的数据很小，我build议mongo，如果它是大cassandra更好。 你不需要mongo或cassandra的caching层，它们已经很快了。 我不推荐simpledb，它也locking你到亚马逊，如你所说。
如果您使用的是c＃，java或scala，则可以编写一个接口并将其实现为mongo，mysql，cassandra或其他数据访问层。 dynamic语言（例如rub，python，php）更简单。 如果你愿意的话，你可以为它们中的两个编写一个提供程序，并且可以在运行时更改存储器，只需要更改configuration即可。 mongo，cassandra和simpledb的开发比数据库更容易，它们没有模式，它也取决于你使用的客户端库/连接器。 最简单的是mongo。 在cassandra中每个表只有一个索引，所以你必须自己pipe理其他索引，但是我知道cassandra的二次索引的0.7版本将是可能的。 您也可以从任何一个开始，如果必须的话，将来会replace它。
我认为你有两个时间和速度的问题。
MongoDB / Cassandra将会快得多，但是你将不得不投资$$$来让他们走。 这意味着你需要运行/设置所有的服务器实例，并找出它们是如何工作的。
另一方面，您不需要直接按“每笔交易”的成本，只需要支付对于大型服务可能更高效的硬件。
在Cassandra / MongoDB的战斗中，你会发现（根据我在过去几天亲自参与的testing）。
卡桑德拉：
- 扩展/冗余是非常核心的
- configuration可以非常激烈
- 要做报告，你需要map-reduce，为此你需要运行一个hadoop层。 这是一个痛苦的configuration和一个更大的痛苦，以获得高性能。
MongoDB的：
- configuration是相对容易的（即使是新的分片，本周）
- 冗余仍然“到达”
- Map-Reduce是内置的，很容易获取数据。
老实说，考虑到我们的10s数据所需的configuration时间，我们在MongoDB的最后。 我可以想象使用SimpleDB“必须得到这些运行”的情况。 但是configuration一个节点来运行MongoDB是非常简单的，可能会跳过“SimpleDB”路由。
就DAO而言，已经有很多Mongo的图书馆了。 Cassandra的Thrift框架得到了很好的支持。 你可以写一些简单的逻辑来抽象出连接。 但是抽象出比简单的CRUD更复杂的东西会比较困难。
现在5年后，在任何操作系统上安装Mongo并不难。 文档很容易遵循，所以我不认为把Mongo设置成一个问题。 其他答案解决了可扩展性的问题，所以我将尝试从开发人员的angular度来解决这个问题（每个系统有什么限制）：
我将使用SimpleDB的S和Mongo的M。
- M是用C ++编写的，S是用Erlang编写的（不是最快的语言）
- M是开源的，安装到处都是，S是专有的，只能在亚马逊AWS上运行。 你也应该为S 付一大笔工资
- S有一大堆奇怪的限制 。 M 限制更合理。 最奇怪的限制是：
- 域（表）的最大大小是10 GB
- 属性值长度（字段大小）为1024字节
- select响应中的最大项目 – 2500
- Select的最大响应大小（最大数据量S可以返回给你） – 1Mb
- S 只支持几种语言 （java，php，python，ruby，.net），M 支持的方式更多
- 既支持REST
- S有一个查询语法非常类似于SQL（但方式不那么强大）。 随着M，你需要学习一个新的语法看起来像JSON（也是直接了解基础知识）
- 与M你必须学习如何build立你的数据库。 因为很多人认为无模式意味着你可以在数据库中扔掉任何垃圾并且轻松地提取这些垃圾，他们可能会感到惊讶的是，垃圾入侵，垃圾出来的格言。 我认为S也是一样，但不能肯定地要求。
- 都不允许区分大小写的search。 在M你可以使用正则expression式（丑陋/没有索引）克服这个限制，而不会引入额外的小写字段/应用程序逻辑。
- 在Ssorting只能在一个领域完成
- 因为S中的5s的时间限制可以performance得很奇怪 。 如果5秒钟过去了，查询还没有结束，你最终会得到一个部分号码和一个令牌，让你继续查询。 应用程序逻辑负责收集所有这些数据总结。
- 一切都是一个UTF-8string ，这使得在S中使用非string值（如数字，date）是一个痛苦的麻烦。M型支持更丰富 。
- 都没有交易和join
- M支持对nosql存储真正有用的压缩 ，其中再次存储相同的字段名称。
- S只支持单一索引，M 有单一，复合，多键，地理空间等 。
- 既支持复制和分片
你应该考虑的最重要的事情之一是SimpleDB有一个非常基本的查询语言。 即使像group by ， sum average ， distinct和data操作这样的基本事物也不被支持，所以这个function并不比Redis / Memcached更丰富。 另一方面，Mongo支持丰富的查询语言。
