121

我已经使用 MySQL 一段时间了,我对它的结构和 SQL 查询等感到满意。

目前在 AWS 中构建一个新系统,我一直在研究 DynamoDB。目前我只知道一点。

一个比另一个好吗?

DynamoDB 的优势是什么?

从 MySQL 查询等到这个平面样式数据库的过渡是什么样的?

4

4 回答 4

294

真的 DynamoDB 和 MySQL 是苹果和橘子。DynamoDB 是 NoSQL 存储层,而 MySQL 用于关系存储。您应该根据应用程序的实际需求来选择使用什么。事实上,某些应用程序可能会同时使用两者。

例如,如果您存储的数据不适用于关系模式(树结构、无模式 JSON 表示等),可以针对单个键或键/范围组合进行查找,那么 DynamoDB (或其他一些 NoSQL 存储)可能是您最好的选择。

如果您的数据有一个定义明确的模式,可以很好地适应关系结构,并且您需要以多种不同方式查询数据的灵活性(当然,根据需要添加索引),那么 RDS 可能是一个更好的解决方案.

将 DynamoDB 用作 NoSQL 存储的主要好处是,您可以在所需的任何级别上获得保证的读/写吞吐量,而不必担心管理集群数据存储。因此,如果您的应用程序每秒需要 1000 次读取/写入,您只需为该级别的吞吐量配置您的 DynamoDB 表,而不必真正担心底层基础设施。

RDS 具有不必担心基础架构本身的许多相同好处,但是如果您最终需要执行大量写入操作,以至于最大的实例大小将不再跟上,那么您就没有办法了选项(您可以使用只读副本水平扩展读取)。

更新说明:DynamoDb 现在支持全局二级索引,因此您现在可以对除散列或散列和范围键组合之外的数据字段执行优化查找。

于 2012-12-20T16:33:16.377 回答
170

我们刚刚将所有 DynamoDB 表迁移到 RDS MySQL。

虽然将 DynamoDB 用于特定任务可能很有意义,但在 DynamoDB 之上构建新系统确实是个坏主意。最好的计划等,您总是需要数据库提供额外的灵活性。

以下是我们从 DynamoDB 迁移的原因:

  1. 索引 - 如果不创建新表,就不可能即时更改或添加键。
  2. 查询 - 查询数据极为有限。特别是如果您想查询非索引数据。连接当然是不可能的,因此您必须在代码/缓存层上管理复杂的数据关系。
  3. 备份 - 与 RDS 的流畅备份相比,如此繁琐的备份过程令人失望
  4. GUI - 糟糕的用户体验,有限的搜索,没有乐趣。
  5. 速度 - 与 RDS 相比,响应时间是有问题的。您会发现自己在为 RDS 的内部缓存解决问题的地方构建了复杂的缓存机制来补偿它。
  6. 数据完整性——虽然流体数据结构的概念一开始听起来不错,但您的一些数据最好“一成不变”。当一个小错误试图破坏您的数据库时,强类型是一种祝福。使用 DynamoDB,一切皆有可能,而且确实发生了任何可能出错的事情。

我们现在使用 DynamoDB 作为某些系统的备份,我相信我们将来会将它用于特定的、明确定义的任务。这不是一个糟糕的数据库,它只是不是为您的核心系统提供 100% 服务的数据库。

就优势而言,我会说可扩展性和耐用性。它的扩展令人难以置信且透明,并且(某种程度上)总是向上。这些确实是很棒的功能,但它们并不能以任何方式弥补不利方面。

于 2013-07-30T07:46:58.033 回答
72

您可以在此处阅读 AWS 关于它的说明。

简而言之,如果您主要有Lookup查询(而不是 Join 查询),DynamoDB(和其他 NoSQL DB)会更好。如果需要处理大量数据,在使用 MySQL(和其他 RDBMS)时会受到限制。

你不能重用你的 MySQL 查询和你的数据模式,但是如果你花精力学习 NoSQL,你会在你的工具箱中添加一个重要的工具。在许多情况下,DynamoDB 提供了最简单的解决方案。

于 2012-12-20T15:25:17.993 回答
16

使用 DynamoDB 时,您还应该知道 DynamoDB 中的项目/记录限制为 400KB(请参阅DynamoDB 限制)。对于许多用例,这将不起作用。所以 DynamoDB 对少数事情有好处,但不是全部。许多其他 NoSQL 数据库也是如此。

于 2013-01-29T09:14:47.970 回答