通过DynamoDB再次入门NoSQL

1 年 ago

韵, 科

5 minutes

我之前只是稍微接触过DynamoDB，但看到一篇说DynamoDB数据不一致性的文章后，一直怀疑DynamoDB到底有什么好的地方。这是我试图解开这个疑问时的总结。

请用中文概括

本投稿旨在加深对NoSQL的理解。

Non-Relationalなデータモデル
RDBMSのShardingの何が問題だったのか

分散システム

CAP Theorem
Scalabiilty (Replication / Sharding)

DynamoDB

額外談及：《設計數據密集型應用》是一本經典之作。

《名著名著》已成为所有应用工程师必读的级别了。如果想要深入理解数据库，我认为绝对应该阅读它。据说还有日语翻译版本，非常推荐阅读。

NoSQL的兴起

首先, 我们将来看一下NoSQL是指什么，它为什么诞生。

NoSQL是什么？

NoSQL指的是“Not Only SQL”的缩写，它是指采用非关系型数据模型的数据库，以摆脱SQL的限制。虽然我们统称为NoSQL，但它们具有多种不同的数据模型和采用的技术也各有不同。在本篇文章中，我们主要讨论DynamoDB。

为什么出现了NoSQL？

NoSQL的起源是Amazon的”Dynamo”和Google的”BigTable”的论文。随后在旧金山举行了一系列的NoSQL聚会。

通过关注Dynamo和NoSQL聚会，我们可以看到在数据库的主流中，RDBMS有何不足之处。

魔术师

Dynamo的动机在AWS首席技术官的博客中记录着。

通过对我们现有数据库的深入挖掘，我们发现它们经常不会用于其关系能力。大约70%的操作是键值操作，只使用了主键并返回单行数据。约20%的操作也会返回一组行数据，但仍只在单个表上操作。
【引用】《Dynamo十年之回顾：推动下一波高性能、互联网规模的应用》

许多情况下并不需要使用关系型数据库来管理数据，Dynamo的动机是因为其中大部分是简单的操作。

三藩市无SQL聚会

这是在2009年在旧金山举办的 meetup。在这次 meetup 中诞生了 NoSQL 这个术语。在 meetup 的介绍资料中，有一个幻灯片介绍了 NoSQL 的前提和时代背景，其中提到了 “数据规模”、”可靠性” 和 “性能” 这三个方面。

performance：リアルタイム性のためにパフォーマンスが必要となった。

幻灯片中提到，在那个时代的主流数据库——关系型数据库管理系统（RDBMS）中，满足这些要求是困难的。

换句话说

RDBMS+Sharding被认为是原罪，也是由于有了一些无需关系管理的用例而诞生了NoSQL。因此，要更深入地了解NoSQL，需要对以下三个方面有更深入的了解。

分散システム

因此，我想逐一讨论上述三个点。

顺便提一下，我们使用了“Sharding”这个术语，它似乎与“Partitioning”意思相同。

我们在这里所称之为分区，在 MongoDB、Elasticsearch 和 SolrCloud 中被称为分片；在 HBase 中被称为区域，在 Bigtable 中被称为表格，在 Cassandra 和 Riak 中被称为虚拟节点，在 Couchbase 中被称为虚拟分区。然而，分区是最常用的术语，所以我们将坚持使用它。

关系数据库管理系统（RDBMS）+ 分片（分区）

分片（Sharding）是指…

dn589795.a60dc6b05d547b9b397aa04c37f3c644(en-us,pandp.10).png

分库分片是指将数据库分割成多个部分，并将分割后的数据库分配到不同的节点上。（Shared-nothing）
由于数据大小和写入请求的增加，需要进行分库分片。通过利用分库分片，可以有效地管理数据大小，并且实现读写负载均衡。

关系型数据库管理系统+分片的问题点

使用Sharding引入RDBMS作为分布式系统是可行的，但这样做会完全削弱RDB的优势。原本RDBMS是以单个节点保持单一数据库的整体形式存在的，不考虑将数据库分散到多个节点上。

由于在《NoSQL Distilled》中对RDBMS+Sharding进行了简洁的总结，因此我们引用如下：

关系型数据库也可以作为不同数据集的独立服务器运行，从而有效地对数据库进行分片（“分片”，第38页）。虽然这样可以分散负载，但所有的分片都必须由应用程序控制，应用程序必须追踪每个数据片段需要与哪个数据库服务器通信。此外，我们还会失去跨分片的查询、引用完整性、事务或一致性控制。我们经常听到做过这样操作的人在这个语境中说的一句话是“不自然的行为。”

在上述描述中列出了RDBMS+Sharding的以下4个问题。

アプリケーション側のロジックの複雑化

我們按照順序來看。

失去加入

在关系数据库中，引入了数据的规范化处理。通过这种规范化处理，数据被分散管理在多个表中。为了将这些多个表的数据进行合并，提供了JOIN功能。

由於JOIN操作在單個節點上運行RDBMS，因此能夠保持性能並執行成功。如果對RDBMS進行分區，表將跨越多個節點，造成表的連接通過網絡進行，從而導致性能大幅下降。（有關事務問題將在稍後解釋。）

RDBMS+Sharding的问题经常被指出，然而，这实际上是一个可以通过设计注意而避免的问题。

选择分区键时，尽量选择可以尽量避免跨分片查询的内容，但同时要确保分片足够小，以免出现数据不均衡的问题。希望分片尽量均匀小，如果不行，至少要确保分片足够小，以便可以通过将不同数量的分片进行分组来平衡。

如果你能够仔细设计partition，并确保相关的表能够收纳在单个节点上，就不需要执行跨shard的查询了。因为在aws的文档中有一个很明显的图解说明了这一点，所以我在这里附上它。

丧失交易

「经常可以看到关于执行分区操作会导致事务无法进行的说法，但这是不准确的。在《设计数据密集型应用》一书中也有提到这一点。」

许多分布式数据存储系统放弃了多对象事务，因为在不同分区上实现它们很困难，并且在某些需要非常高的可用性或性能的场景中可能会妨碍操作。然而，并没有任何根本上阻止分布式数据库中的事务，我们将在第9章中讨论分布式事务的实现方式。

在MySQL中，实际上可以使用XA Transaction作为分布式系统版本的事务。XA Transaction允许在存储引擎之间通过网络来使用事务，而不仅仅在存储引擎内部使用。

正如MySQL文档中所述，该XA事务使用了两阶段提交。

全局事务的执行过程使用了两阶段提交（2PC）机制。此机制在全局事务的分支执行完毕后进行。【引用】13.3.8 XA事务

在分散系统中实现事务时，每个存储引擎需要同时执行事务，而用于此的机制就是两阶段提交。

在每个节点上执行或放弃事务等决策并进行管理的事务管理器是必需的。然而，在 MySQL 中，这个事务管理器的角色是由应用程序负责的。

对于“外部XA”，MySQL服务器充当资源管理器，客户端程序充当事务管理器。【引用】13.3.8.3关于XA事务的限制。

看上面的图就很容易理解，关系数据库管理系统（RDBMS）提供了下方的块，并不提供对其进行管理的要素。也就是说，虽然MySQL可以在自己的存储引擎内保证事务，但跨多个节点的事务保证成为应用程序的责任，这一点需要注意。

此外，由于此分布式事务的性能非常差，基本上最好不要使用。

有些分布式事务的实现会带来很大的性能损失，例如，在MySQL中的分布式事务被报道比单节点事务慢10倍以上[87]，所以当人们建议不要使用它们时并不令人惊讶。两阶段提交所固有的许多性能成本是由于崩溃恢复所需的额外磁盘强制写入(fsync)，以及额外的网络往返所导致的[88]。
【引用】《数据密集型应用的设计》

总结起来，如果将MySQL用作分布式系统，那么事务并不是不可能的，但基本上需要避免使用它。换句话说，这意味着会失去ACID特性。

失去参照完整性

在使用分区时，MySQL文档中明确提到外部约束键不受支持。如果无法使用外部约束键，则无法保证引用完整性。

不支持在分区的InnoDB表上使用外键【引用】23.6 分区的限制和限制

由于存储引擎在后台负责确保外部约束键的一致性，因此工程师很少需要关注。在后台，首先锁定要更改的行，然后锁定被外部约束键引用的另一个表的行，然后在完成事务之后解除锁定以更改目标行。

换句话说，参照完整性是由跨越多个表的事务来实现的。并且我们之前已经提到，当使用分区时，实现事务变得困难。

换句话说，利用分区是无法确保引用一致性的。然而，并不是说它是“不可能的”。通过在应用程序中编写代码来确保引用一致性，可以实现引用一致性的保持。

在分片中进行查询不是唯一的困难之处。保持数据一致性也很困难。跨分片使用外键将不起作用，所以通常的解决方案是根据需要在应用程序中检查参照完整性，或者在分片内使用外键，因为分片内的内部一致性可能是最重要的。虽然可以使用XA事务，但由于开销较大，实际上并不常见。

应用程序代码的复杂化

虽然到这一步就可以理解了，但是如果使用单节点运行的MySQL来使用分区，会使应用程序的代码变得复杂。

MySQL仅负责管理由其自身的存储引擎处理的数据库，不提供管理多个存储引擎的功能。换句话说，如果使用分区功能，就需要在应用程序中实现管理分区的功能。

首先，需要实施哪种查询应该发送到哪个分区的路由逻辑。此外，还需要进行分区本身的管理。如果出现了访问特定节点过多的热点现象，则需要改变分区方式。可能还需要添加新节点。如果要添加/删除分区，还需要执行数据迁移。

此外，应用程序还需要实现管理事务的功能。如果要使用XA事务，似乎需要使用两阶段提交，这可能导致在不具备容错性设计的情况下，同步处理无法完成并导致停机的情况发生。

此外，还需要应用程序本身来确保获得参考一致性。此外，MySQL本来就是默认的单节点管理，将管理代码转移到分布式系统将需要非常大的工作量。

非关系型数据模型

鉴于许多情况下可以不保存关系数据，非关系数据模型被引入。在这里我们将看一下非关系数据模型的特点。

汇总

对于RDB的情况，通过规范化来管理关系型数据。而NoSQL（DynamoDB）采用了一种数据模型，可以将相关数据组合在一起进行存储。

在《NoSQL精粹》一书中，它被称为本地化（类似于日语中的“参照局部性”）。

在20年前的路由表优化研究中发现，将相关数据集中存放在一个地方以实现”引用局部性”是缩短响应时间最重要的因素。这个理论同样适用于今天的NoSQL系统。将相关数据放置在附近对成本和性能有着重大影响。而不是将相关数据项分散在多个表中，需要将NoSQL系统内的相关项尽可能地放置在附近。【引用】与DynamoDB相适应的NoSQL设计。

不需要连接多个表，可以一次性获取相关数据。（当然，如果Aggregate被拆分，就需要类似JOIN的处理。因此，NoSQL的设计（数据建模）变得非常重要。）

不需要方案

在关系数据库（RDB）中，我们需要事先定义数据模型的结构，但在NoSQL中，数据模型是无模式（schema-less）的，不需要事先定义模式。

在DynamoDB中，只需指定表名和主键/排序键就可以创建表。无需考虑后续项的模式定义，可以随时进行大量数据的插入。

这个特点”schemaless”给人一种非常灵活的印象。但实际上，需要注意的是，当应用程序读取数据时，必须指定数据结构，这就是所谓的”scheme-on-read”。

在传统的关系型数据库中，模式定义是数据库端的责任，并且根据预先定义的模式来构建应用程序逻辑。然而，在无模式的数据模型中，模式定义成了应用程序端的责任。

在应用程序中构建逻辑是可行的，但在此过程中，如果不事先了解项名称和模式，就无法构建逻辑。而麻烦的是，“假设的模式”在整个应用程序代码中随处可见。关于这一点，马丁将无模式数据结构称为“隐藏方案”，并指出这导致了开发的困难。

顺便提一下，在MongoDB的文档中，对于这一点有以下的陈述。

MongoDB是一种关注开发者需求的文档数据库（还有相同的主题吗？）。维护MongoDB集群不需要一支由数据库管理员组成的军队，而且数据库的灵活性允许应用程序开发者自行定义和操作模式，而不依赖于专门的工程团队。【引用】Ruby、Rails、MongoDB和对象关系不匹配

在中国的一个选项中直接解释如下：通过无模式，应用程序团队可以自由地更改模式，而无需与数据库团队合作，并且这被认为是一个优点。

如果只考虑无模式化，如果使用自定义字段或者只管理非一致性数据的表格，那么无模式化具有优点，但如果不是这种情况，我们应该考虑到缺点，并采用非关系型数据模型。

尽管无模式（Schemaless）的设计需要根据访问模式进行精心设计，但需要注意的是，即使在最初看似适合非关系型数据模型的应用程序中，随着时间推移可能会出现需要采用关系型管理的情况。

设计分散系统

為了理解NoSQL，我認為需要深入了解分散系統的設計。在這裡，我們將依次討論「CAP原理」和「可擴展性」。

CAP 定理

CAP定理是关于在设计分布式系统时需要考虑到的三个性质之间的权衡的定理。

需要注意的是，由于使用了令人困惑的表达或者忽略了许多要点等原因，该定理受到了相当大的批评。就连《设计数据密集型应用》一书中也对其进行了严厉的批评。

一个在实践中没有实用价值，并且被广泛误解的理论结果。

尽管受到批评，但在考虑分散系统设计时，我认为理解这三个特性非常重要，因此我们将逐一研究每个特性。

Partition-tolerance

一致性

在CAP定理中，一致性指的是通过线性化来实现强一致性。

这相当于要求分布式共享内存的请求像在单个节点上执行一样，按照顺序响应操作。原子读/写共享内存的一个重要特性是，任何在写操作完成后开始的读操作必须返回该值或之后写操作的结果。

从强一致性角度来看，在某个write操作之后的read操作将始终获取到该write操作写入的最新数据。

供应情况

要使分布式系统持续可用，系统中每个没有发生故障的节点在接收到的每个请求后必须产生一个响应。也就是说，服务使用的任何算法都必须最终终止。

无论何时何地，只要有请求发送到活动节点，就会立即返回响应，这就是所说的意思。

分区容错

即使网络中的其他节点全部失败（即节点处于其自己独特分区的组件中），系统必须生成一个有效（原子）的响应。不允许任何小于完全网络故障的故障集导致系统错误地响应。5

即使除了该节点之外的所有节点都失败，也要确保服务能够正常运行。也就是说，不能有单一故障点。

CAP定理是关于分布式系统的理论。

看起来在原论文中，关于分布系统只能获得这三个属性中的两个，这样的说法，但实际上并非如此。

在分散系统中，网络分割是迟早会发生的，并因此必须放弃分区容忍性。换句话说，CAP理论并不是要从三个中选择两个，而是要考虑在网络分割发生时是优先保持一致性还是优先保持可用性。

同样，一定要注意的是，一致性和可用性这两个特性并不是只能取得其中之一，而是调整它们的平衡非常重要。

此外，需要注意的是，在分散系统中可能发生的故障不仅限于网络分割，并且在使系统具有容错性而不是为了获得性能而放宽了一致性（线性一致性）的情况也很常见。

可扩展性

在考虑分散系统时，了解扩展方法非常重要。基本上，扩展方法有两种：复制和分区，现在我们来看看它们。

复制

将相同的数据复制并存储在多个节点中。与在单个节点上持有单个副本的情况不同，可以提供冗余性，并且可以获得读取的可扩展性。此外，通过在地理上分散节点，还可以获得地理上的优势。

在维护的数据库中，通过写入请求对其进行更改。但是，根据向哪个节点发送写入请求，复制机制将会有所不同。

我认为可以大致将其分为三类：拥有单个执行write操作的节点的Single Leader（Master-Slave），允许多个节点执行write操作的Multi Leader，以及没有Leader的Leader Less。

在这里，我们将探讨MySQL和DynamoDB中使用的单一主节点模式。

顺便提一下，Multi Leader 可以增加 Leader 的冗余性，但同时也会导致具有写入功能的节点增加，从而引发并发问题，因此这种缺点更大，所以很少被使用。

单一领导者

dn589787.52ba8389da4cf346753f0cadc5980212(en-us,pandp.10).png

因为有一个Leader，所以没有冗余性，可能成为单点故障。有同步复制和异步复制两种方法来传播从Leader到Replica的写入操作。

在同步复制的情况下，有一个优点是可以获得对写操作的冗余性，但同时也存在一些缺点，比如对方节点发生故障或网络分割等情况下，可能无法执行和完成对Leader的写操作处理。

在异步复制的情况下，尽管不受其他节点或网络的影响，可以执行和完成数据更新。但是，如果在向其他节点共享日志之前，领导者在完成写操作后发生故障，将导致更新的数据丢失，这是一个缺点。

因此，采用了半同步的副本复制方法，即只将数据复制到一个Follower节点上进行同步复制，而对于其他节点则采用异步复制。后面我们将看到，DynamoDB也采用了这种方法。

当涉及到异步复制时，就需要考虑一致性问题。这是因为在异步复制中，存在复制滞后，我们无法确定跟随者何时会更新到最新的数据。因此，我们将异步复制中的一致性称为“最终一致性（Eventual Consistency）”。

在同步复制的情况下，直到写操作完成复制到Follower节点之前，写操作将不会完成，而完成指的是复制操作完成。通过阻塞对Replica的读操作，所有节点都将保持最新的数据库，这一点被称为”强一致性（Strong Consistency）”。

根据MongoDB的文档，MongoDB的默认设置是强一致性（strong consistency）。MongoDB也是单领导者（Single Leader）的，但读取请求不是发送到副本（Replica），而是发送给领导者（Leader），这样无论复制延迟（Replication Lag）如何，都可以随时获取最新的状态。副本作为领导者发生故障时的备份起到了作用。

请注意，在这种情况下，没有使用同步复制以获得强一致性。正如前面所述，使用同步复制会导致只要有一个节点发生故障，写入就变得困难，可用性就会丧失，或者由于网络延迟导致写入性能下降。因此，它没有被使用。

最終的な一貫性とは、話を戻しましょう。レプリケーションの遅延により、強力な整合性ではなく結果的な整合性が生じていますが、これは通常は問題にならないようです。レプリケーションの遅延は非常にわずかなものであるためです。

在使用只提供弱保障的数据库时，你需要不断意识到它的限制，并且不要意外地假设太多。由于应用程序大部分时间都能良好运行，所以错误往往隐微且难以通过测试找出。只有当系统发生故障（如网络中断）或是高并发时，才会暴露出最终一致性的边界情况。

然而，如果出现网络分割、延迟等情况，将会出现结果一致性的问题。这是因为复制延迟变大。领导者无法将最新数据反映到副本中，或者反映的延迟导致向该副本发送的 read 请求可能读取到旧值。（如果对同一数据存在多个并发访问的情况，同样会引发问题。）

这里所说的就是先前提到的CAP定理的意思。“如果发生网络分区，从副本中读取可能会返回旧值，但你仍然可以进行读取。”这是优先考虑可用性吗？还是“在这种情况下，禁止从副本读取。” 这是优先考虑一致性（线性化：始终返回最新值）吗？这是一个权衡。

只要读取旧的值没有问题，就采用结果一致性系统。但是，如果不是这样的情况，即在需要始终返回最新值并要求一致性的情况下使用结果一致性系统，则需要考虑复制滞后并注意数据访问。

现在，我们已经看到了结果一致性和强一致性，重要的是注意到使用哪个并不是说哪个更好，而是在使用时要灵活选择。如果使用场景需要强一致性，那就使用强一致性；如果不需要强一致性，为了可扩展性和性能，尽量使用结果一致性。

分片/分区

Sharding的方法

在设计应用程序时，重要的一点是要考虑如何将数据分片并确定存储节点。虽然有各种分片策略，但只要理解了哈希策略和范围策略，在这方面应该没有问题。

看起来DynamoDB和Cassandra默认使用Consistent Hash Sharding，而Google Spanner和Apache HBase默认使用Range Sharding。

Range Sharding使用分区键的值范围来确定Shard。然而，Consistent Hash Sharding将分区键的值哈希化，并使用一致性哈希将数据存储在相应的Shard中。通过一致性哈希，可以实现增量可扩展性。

toptal-blog-image-1551794781664-ce4274caf801db26b828400a8cfde967.png

关于一致性哈希算法，上面的博客对其进行了非常详细的解释。虽然我简单粗略地尝试解释一下，但如果你想要详细了解，请参考上面的博客。

通过将哈希的上限值和下限值连接成一个环，并且对数据和节点进行随机哈希化，我们可以确定每个数据属于哪个节点。这样，即使移除一个节点，只需将该节点中的数据分配给相邻节点即可，无需重新分配其他节点和数据。当添加或删除节点时，会影响到相邻节点和数据，但不会影响其他节点。我们希望在添加或删除节点时不停止服务，为此需要尽量减少节点之间数据的迁移量，而一致性哈希算法可以通过最小化数据迁移来实现重新分片。

选择Range Sharding和Consistent Hashing Sharding中的哪种方法取决于具体情况。如果需要根据分区键进行范围搜索，那么选择Range Sharding可以保持性能。另一方面，需要考虑到分区键可能导致热点问题。

在一致性哈希分片的情况下，根据哈希值确定分片，因此热点出现的可能性较低，但会增加哈希函数的开销。在Dynamo的白皮书中，提到将MD5用作分区的哈希函数。这不是基于节点数量的哈希函数，所以可以轻松地添加或删除节点。

Dynamo将调用者提供的键和对象都视为一个不透明的字节数组。它对键应用MD5哈希生成128位标识符，用于确定负责存储该键的存储节点。

DynamoDB：亚马逊公司的一种全托管的NoSQL数据库服务。

DynamoDB 是什么？

Amazon DynamoDB是一种全托管的NoSQL数据库服务，具有快速可预测的性能和无缝可伸缩性。通过使用DynamoDB，可以将分布式数据库的运营和扩展的管理工作交给它来处理，省去了硬件配置和部署、设置和配置、复制、软件补丁应用、集群扩展等任务。

最初，人们常常将NoSQL的先驱Dynamo和DynamoDB混淆在一起，但实际上DynamoDB和Dynamo的机制是不同的。

DynamoDB是亚马逊的一个结合了SimpleDB（Amazon的NoSQL数据库）和Dynamo的服务。

我们得出结论，理想的解决方案应该将原始Dynamo设计的最佳部分（增量可伸缩性，可预测的高性能）与SimpleDB的最佳部分（易于管理云服务，一致性以及基于表的数据模型比纯键值存储更丰富）相结合。这些架构讨论最终产生了亚马逊DynamoDB，这是一种新的NoSQL服务，我们今天非常兴奋地发布。

我认为DynamoDB是一种NoSQL数据库，它所追求的是”可扩展性”，因此我希望能先来看看这一方面。首先，我们将讨论复制和分片，然后再来看自动扩展。

复制和分片

amazon-dynamodb-deep-dive-advanced-design-patterns-for-dynamodb-dat401-aws-reinvent-2018pdf-12-638.jpg

每个Partition（Shard）都会自动在三个可用区（AZ）之间进行复制。由于Dynamo使用的是无Leader副本（quorum），可能会误以为DynamoDB也是相同的，但实际上DynamoDB使用的是单Leader副本。

除了亚马逊之外，用户无法使用Dynamo。令人困惑的是，AWS提供了一种名为DynamoDB的托管数据库产品，它采用了完全不同的架构：基于单leader复制。

amazon-dynamodb-under-the-hood-how-we-built-a-hyperscale-database-dat321-aws-reinvent-2018-24-638.jpg

位于节点前端的请求路由器（Request Router）会向随机选定的节点发出读请求。由于已知有3个节点中的2个节点完成了写操作，因此有1/3的可能性选择那些未被更新的节点。如果在该节点上值没有被更新，则会读取旧值。

DynamoDB的文件中也有记载，默认情况下使用Eventual Consistent Reads，但可以通过使用Consistent Read选项来改为Strongly Consistent Reads。（在这种情况下，数据不是随机选择节点，而是从Leader读取。）

amazon-dynamodb-under-the-hood-how-we-built-a-hyperscale-database-dat321-aws-reinvent-2018-29-638.jpg

分区元数据组件负责管理哪个节点是Leader。此外，如果Leader节点发生故障，就必须从Follower节点中选择新的Leader，但如果没有达成一致，就会导致脑裂问题。关于Leader的选举采用了Paxos共识算法。似乎Auto Admin负责处理Leader的选举和节点故障时的应对措施。

分片

DynamoDB支持分片，因此表的大小没有限制。

表格的大小
表格的大小没有实际限制。表格在项数和字节大小方面没有限制。
【引用】Amazon DynamoDB的服务、帐户和表格限制

在DynamoDB中，在创建表时需要指定分区键和排序键。通过对分区键的值进行哈希处理，确定将该聚合存储在哪个分区中。另外，通过设置排序键，可以在该分区内进行范围查询。

正如之前所提到的，DynamoDB使用一致性哈希来进行分片。使用哈希功能进行分片可以有效地分散数据访问量，但是在某些数据上存在大量访问的情况下，会出现热点问题。DynamoDB通过后面介绍的自适应容量(Adaptive Capacity)，可以自动解决热点问题。

自动伸缩

如果提前创建Application Auto Scaling策略，CloudWatch会监控并根据流量自动发送查询来操作表格。Application Auto Scaling策略可以在创建表格时指定。您可以指定预期的读取/写入量以及允许的扩展程度。

热分区问题得到了适应能力机制的解决。

自适应能力 – DynamoDB会智能地根据表格的存储需求进行自适应，通过将表格水平分区到多台服务器上来扩展存储空间，或通过过期标记自动删除项目的Time To Live（TTL）功能来缩小存储空间。 DynamoDB提供自动缩放功能，根据实际流量自动调整表格的吞吐量上升或下降。所有新的表格和索引默认开启自动缩放功能。
【引用】《Dynamo十年：为下一波高性能、互联网规模的应用提供动力》

有了这个功能，就不需要以最大流量来预配。

amazon-dynamodb-deep-dive-advanced-design-patterns-for-dynamodb-dat401-aws-reinvent-2018pdf-20-638.jpg

交易

如《DynamoDB 事务》的文章中所述，在DynamoDB中，事务被作为新功能加入。通过事务实现，可以在多个分区和表之间进行事务操作。

根据以下内容显示，似乎使用了两阶段提交来实现事务。需要注意的是，由于请求数量的增加，费用也会增加。

对于要求在每个请求中始终可用的最后写入的事务应用程序，默认选择事务API是最好的选择。为了支持事务并简化开发人员体验进行整体或无操作（All-or-Nothing）的表更改，DynamoDB将对所有事务项执行两个基本的读取和写入操作。其中一个用于准备事务，另一个用于提交事务。每个读取和写入的成本相同，但由于会增加每个事务更改的读取和写入总数，因此它将成为最昂贵的表更新选项和读取一致性模型。
【引用】判断Amazon DynamoDB是否符合需求并计划迁移的方法

最后

在这个话题下，我本来想要介绍各种NewSQL，但是我现在有点累了，就留到下次再说吧。比如，MySQL Cluster使用InnoDB代替NDB来实现分布式系统，AWS Aurora通过重新定义传统关系数据库（RDB）并引入服务导向架构（SOA），以及以redo Log为核心来提高性能等等。此外，Google Spanner等还引入了True Time等各种可扩展的关系数据库管理系统（RDBMS）。我认为，通过了解NewSQL，我们可以从不同的角度来看待NoSQL。

如果本投稿有任何错误之处，请指出，我会非常感激?‍♂️

请参考

书籍 (shū jí)

https://www.amazon.co.jp/dp/B0090J3SYW/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

分区/分片

https://blog.yugabyte.com/four-data-sharding-strategies-we-analyzed-in-building-a-distributed-sql-database/

一致性

https://cloud.google.com/datastore/docs/articles/balancing-strong-and-eventual-consistency-with-google-cloud-datastore?hl=ja

CAP定理

https://cloud.google.com/blog/ja/products/gcp/inside-cloud-spanner-and-the-cap-theorem

无SQL普遍

https://www.ibm.com/downloads/cas/3BAWY9RW

NoSQL聚会

https://blog.oskarsson.nu/2009/06/nosql-debrief.html

Dynamo / DynamoDB: 动力学 / 动力学数据库

https://aws.amazon.com/jp/blogs/aws/new-auto-scaling-for-amazon-dynamodb/