AWS MySQL RDS vs AWS DynamoDB
现在我一直在使用MySQL，所以我对它的结构和SQL查询很感兴趣。
目前在AWS中构build一个新的系统，我一直在看DynamoDB。 目前我只知道一点。
一个比另一个更好吗？
DynamoDB有什么优势？
从MySQL查询等到这个平面样式数据库的过渡是什么？
你可以在这里阅读AWS的解释。
总之，如果您主要查找查询（而不是Join查询），则DynamoDB（和其他NoSQL DB）更好。 如果您需要处理大量数据 ，那么在使用MySQL（和其他RDBMS）时将受到限制。
您不能重复使用您的MySQL查询或您的数据模式，但是如果您花费精力学习NoSQL，则会在工具箱中添加一个重要的工具。 DynamoDB提供最简单的解决scheme的情况很多。
真的DynamoDB和MySQL是苹果和橙子。 DynamoDB是NoSQL存储层，而MySQL用于关系存储。 您应根据应用程序的实际需要select要使用的内容。 事实上，一些应用程序可能会同时使用这两个。
例如，如果您存储的数据不能很好地适用于可以针对单个键或键/范围组合查找的关系模式（树结构，无模式JSON表示等），那么DynamoDB（或其他一些NoSQL商店）可能是你最好的select。
如果您的数据有一个定义良好的模式，可以很好地适应关系结构，并且您需要灵活地以多种不同方式查询数据（当然，根据需要添加索引），那么RDS可能是更好的解决scheme。
使用DynamoDB作为NoSQL存储的主要好处是，无论您需要什么级别，都可以保证读/写吞吐量，而无需担心pipe理集群数据存储。 因此，如果您的应用程序每秒钟需要1000次读取/写入，那么您可以将DynamoDB表configuration为该吞吐量级别，而不必担心底层基础架构。
RDS具有与不必担心基础架构本身相同的好处，但是如果最终需要进行大量的写入操作，以使最大的实例大小不再保持不变，那么您可能会遇到一些问题选项（您可以水平缩放以使用只读副本进行读取）。
更新说明：DynamoDb现在支持全局二级索引，因此您现在可以在散列或散列和范围键组合以外的数据字段上执行优化查找。
我们刚刚将所有的DynamoDB表迁移到RDS MySQL。
虽然使用DynamoDB进行特定任务可能有意义，但是在DynamoDB之上构build新系统实际上并不是一个好主意。 最好的计划等，你总是需要从你的数据库的额外的灵活性。
以下是我们从DynamoDB中移除的原因：
- 索引 – 无需创build新表即可更改或添encryption钥。
- 查询 – 查询数据非常有限。 特别是如果你想查询非索引数据。 连接当然是不可能的，所以你必须在你的代码/caching层上pipe理复杂的数据关系。
- 备份 – 与RDS的华丽备份相比，这样冗长乏味的备份过程令人失望
- GUI – 用户体验差，search有限，没有乐趣。
- 速度 – 与RDS相比，响应时间有问题。 您会发现自己正在构build精心devise的caching机制，以便在您为RDS内部caching解决的地方进行补偿。
- 数据完整性 – 虽然stream体数据结构的概念听起来不错，但您的一些数据更适合“一石二鸟”。 当一个小错误试图破坏你的数据库时，强打字是一件幸事。 有了DynamoDB，任何事情都是可能的，事实上任何可能出错的事情都会发生。
我们现在使用DynamoDB作为某些系统的备份，我相信我们将来会使用它来执行特定的，明确定义的任务。 这不是一个坏的数据库，它只是服务于你的核心系统100％的数据库。
就优点而言，我会说可扩展性和耐久性。 它的尺寸令人难以置信和透明，总是（总是）。 这些确实是很棒的function，但是它们对于不好的方面并没有任何补偿。
使用DynamoDB时，您还应该知道DynamoDB中的项目/logging限制为400KB（请参阅DynamoDB限制 ）。 对于许多用例来说，这是行不通的。 所以DynamoDB对于很less的东西，但不是全部。 其他许多NoSQL数据库也一样。
