与其他NoSQL数据库相比，DynamoDB有哪些优缺点？

Question

我们在Heroku上为我们的SaaS产品使用MongoDB数据库附加组件。现在，亚马逊推出了一个云数据库服务DynamoDB，我想知道这是如何改变NoSQL产品的格局？

特别是对于基于云的服务或SaaS供应商，与MongoDB相比，如何使用DynamoDB更好或更差？是否有任何成本，性能，可扩展性，可靠性，驱动程序，社区等使用一个与另一个的好处？

Answer 1

对于初学者来说，它将完全由亚马逊的专家团队管理，所以你可以打赌，它几乎没有来自最终用户（开发者）的输入，可以很好地扩展。

此外，由于它由亚马逊构建和管理，您可以假设他们已将其设计为与其基础架构良好协作，因此您可以认为性能将是最佳的。除了专门为其基础架构而构建之外，他们还选择使用SSD作为存储，因此从一开始，磁盘吞吐量将显着高于支持HDD的AWS上的其他数据存储。

我还没有看到任何驱动程序，我认为现在说社区将如何对此做出反应还为时尚早，但我怀疑亚马逊将拥有所有最流行语言的驱动程序，社区可能会收到这么好的 - 并且反过来创建其他驱动程序和工具。

Answer 2

通过Heroku的附加组件使用MongoDB有效地将MongoDB转变为SaaS产品。

实际上，人们会比较所选择的提供商所提供的服务与亚马逊提供的服务，而不是将一种持久性解决方案与另一种解决方案进行比较。

这很难做到。每个提供商将在不同的价位提供不同级别的服务，并且可以考虑在本地为自己的硬件运行它的选项，以便进行开发，这是一个受欢迎的选择。

Answer 3

以下链接中有一个表格，总结了DynamoDB和Cassandra的属性：

http://www.datastax.com/dev/blog/amazon-dynamodb

为了变得更加可用，需要对DynamoDB进行改进的东西是可以索引除主键之外的列。

更新1（06/04/2013）

2013年4月18日，亚马逊宣布支持本地二级索引，这使得DynamoDB非常出色：

http://aws.amazon.com/about-aws/whats-new/2013/04/18/amazon-dynamodb-announces-local-secondary-indexes/

Answer 4

我认为要考虑的关键区别是MongoDB是一种可以安装在任何地方（包括AWS或其他云服务或内部）的软件，其中DynamoDB是一种SaaS，专门作为亚马逊的托管服务（AWS） 。如果您希望保留在内部托管应用程序的选项，则不能选择DynamoDB。如果不考虑在AWS之外托管，那么DynamoDB应该是您的默认选择，除非更多考虑非常具体的功能。

Answer 5

我必须诚实;当我听说新的DynamoDB并且昨天参加网络研讨会时，我感到非常兴奋。然而现在做出决定是如此困难，因为他们所说的一切仍然很模糊;我不知道将通过他们的服务允许/使用的功能。

我知道的一件事是自动处理缩放;这真是太棒了，但还有很多未知数，在所有事实都存在之前很难真正做出很好的分析，我们可以开始使用它。

到目前为止，我仍然认为mongo对我（个人）在我一直在努力的项目中的工作要好得多。

与大多数数据库决策一样，通过项目决定最适合您需求的项目，确实可以归结为项目。

我焦急地等待有关该产品的更多信息，就像现在虽然它处于测试阶段而且我不会跳槽采用最新且最好的只是作为测试人员：）

Answer 6

我认为DynamoDB和其他NoSQL产品之间的主要区别之一是预配置吞吐量 - 您需要为表上的特定吞吐量级别付费，并且只要保持数据分区良好，就可以始终期望满足吞吐量。因此，随着应用程序负载的增长，您可以扩展并保持性能或多或少不变。

Answer 7

Amazon DynamoDB似乎是一个相当不错的NoSQL解决方案。它很快，而且很容易使用。除了拥有AWS账户外，实际上不需要任何设置或维护。与MongoDB / CouchDB / Cassandra相比，现在功能集和API相当小，但我可能希望随着时间的推移，随着开发人员社区的反馈的增加而增长。现在，所有official AWS SDKs都包含一个DynamoDB客户端。

Answer 8

赞成

1. Lightning Fast（内部使用SSD）
2. 真的（非常）可靠。 （写入失败的可能性更低）
3. 无缝缩放（无需手动分片）
4. 用作webservices（无服务器，无配置，无安装）
5. 与其他AWS功能轻松集成（可将整个表存储到S3或使用EMR等）
6. 复制是在内部管理的，因此意外丢失数据的可能性微不足道。

缺点

1. 非常（非常）有限的查询。
2. 扫描很痛苦（我记得一次通过Java扫描运行了6个小时）
3. 预定义的吞吐量，这意味着超出设定吞吐量的突然增加将受到限制。
4. 对表进行分区，因为表在内部进行分片。 （这意味着如果您的吞吐量为1000且其分区为2，如果您只读取最新数据（来自一个部分），那么您的读取吞吐量仅为500）
5. 没有加入，允许有限的索引（基本上是2）。
6. 没有视图，触发器，脚本或存储过程。

作为可扩展应用程序中会话存储的替代方案，它确实很好。另一个很好的用途是在广泛的系统中进行日志/审计。不适用于频繁增强或更改的功能丰富的应用程序。