41

我们将 Heroku 上的 MongoDB 数据库插件用于我们的 SaaS 产品。既然亚马逊推出了云数据库服务 DynamoDB，我想知道这将如何改变 NoSQL 产品的格局？

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

4

8 回答 8

10

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

此外，由于它由 Amazon 构建和管理，您可以假设他们将其设计为可以很好地与他们的基础设施配合使用，因此您可以假设性能将是一流的。除了专门为他们的基础设施构建之外，他们还选择使用 SSD 作为存储，因此从一开始，磁盘吞吐量将显着高于 AWS 上由 HDD 支持的其他数据存储。

我还没有看到任何驱动程序，我认为现在判断社区对此有何反应还为时过早，但我怀疑亚马逊将拥有所有最流行语言的驱动程序，社区可能会很好地接受这一点 - 进而创造额外的驱动程序和工具。

于 2012-01-19T14:34:03.067 回答
5

以下链接中有一个表格总结了 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/

于 2012-03-07T16:52:59.457 回答
5

我认为要考虑的关键区别在于 MongoDB 是一种可以安装在任何地方（包括在 AWS 或其他云服务或内部）的软件，因为 DynamoDB 是一种 SaaS，专门作为 Amazon (AWS) 的托管服务提供。如果您想保留在内部托管应用程序的选项，DynamoDB 不是一个选项。如果不考虑在 AWS 之外托管，那么 DynamoDB 应该是您的默认选择，除非非常具体的功能需要更高的考虑。

于 2012-09-20T16:11:12.290 回答
5

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

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

这很难做到。每个提供商将在不同的价位上提供不同级别的服务，人们可以考虑将其在本地硬件上运行以用于开发目的，这是一个受欢迎的选择。

于 2012-01-20T23:02:58.973 回答
3

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

我知道的一件事是缩放是自动处理的。这真是太棒了，但是仍然有很多未知数，以至于在所有事实都已经掌握并且我们可以开始使用它之前，很难真正做出很好的分析。

到目前为止，我仍然认为 mongo 在我一直从事的项目中对我（个人）工作得更好。

像大多数数据库决策一样，它实际上将归结为一个项目一个项目的决策，即最适合您的需求。

我焦急地等待有关该产品的更多信息，因为目前虽然它处于测试阶段，但我不会跳船采用最新最好的产品，只是为了成为一名测试人员 :)

于 2012-01-19T16:58:54.500 回答
3

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

于 2012-07-26T06:45:43.503 回答
1

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

于 2012-02-02T17:41:03.027 回答
0

优点

  1. Lightning Fast（内部使用 SSD）
  2. 真的（真的）可靠。（写入失败的可能性较低）
  3. 无缝伸缩（无需手动分片）
  4. 作为网络服务工作（无服务器、无配置、无安装）
  5. 轻松与其他 AWS 功能集成（可以将整个表存储到 S3 或使用 EMR 等）
  6. 复制在内部进行管理，因此数据意外丢失的可能性可以忽略不计。

缺点

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

作为可扩展应用程序中会话存储的替代品，它确实非常好。另一个很好的用途是在广泛的系统中进行日志记录/审计。对于具有频繁增强或更改的功能丰富的应用程序而言，这不是优选的。

于 2016-11-16T21:56:11.500 回答