从软件设计的角度来看，NoSQL 只是 RDBMS 之上的营销热词吗？

Question

从架构的角度：能否请您帮我理解为什么 NoSQL DynamoDB 如此炒作。

DynamoDB 通过在任何规模上提供一致的个位数毫秒响应时间来支持一些世界上最大规模的应用程序。

我试图批评，以了解问题的原因。我们总是必须在检索时指定分区键和键属性以获得毫秒级的性能

如果我设计 RDBMS：

它是不是与 NoSQL 架构一样，没有任何营销嗡嗡声？

无论如何，我们正在转向 DynamoDB，但这是我无辜的好奇心，RDMBS 无法做到的一定有充分的理由。让我们跳过备份和维护优势等。

Answer 1

你把两种不同的东西混为一谈。

NoSQL的定义

没有一种，至少没有一种可以适用于所有情况。

在大多数用途中，NoSQL 数据库不会强制您的数据进入关系数据库的固定模式“行和列”。尽管现代关系数据库（例如 Postgres）支持数据类型（例如 JSONB），这会让 EF Codd 在他的坟墓中旋转。

DynamoDB 是一个文档数据库：它针对基于唯一键检索和更新单个文档进行了优化，并且不限制这些文档包含的字段（除了要求用于键的字段）。

分布式数据库将数据存储在多个节点上，并且能够在这些节点上执行并行查询并合并结果。

有分布式 SQL 数据库：Redshift 和 BigQuery 针对可能包括连接的大型数据集的查询进行了优化，而 MySQL（无疑还有其他）可以运行多个引擎并在它们之间分发查询。SQL 数据库可以执行联接，包括跨节点的联接，但此类联接通常性能不佳。

DynamoDB 根据项目的分区键在分片上分发项目。这使得检索单个项目非常快，因为查询可以定向到单个分片。扫描驻留在多个分片上的项目时，它的性能要低得多。

正如您在问题中所指出的，您可以在关系数据库之上实现一个分片文档数据库（使用本机 JSON 列或将所有内容存储在为每次访问解析的 CLOB 中）。但是已经有足够多的其他人这样做了（包括 DynamoDB），以至于重新实现（至少对我而言）没有意义。