本文深度参考了以下这些文章的真知灼见！特此说明，并表示感谢：
• The Dynamo Paper[1]
• The DynamoDB paper[2]
• Key Takeaways from the DynamoDB Paper[3]
• DynamoDB 2022 论文解读[4]
2004 年，Amazon.com 发展迅速，并开始达到其 Oracle 数据库的扩展上限。它开始考虑在内部构建自己的数据库。在这个实验中，工程师创建了 Amazon Dynamo 数据库，该数据库支持主要的内部基础设施，包括 Amazon.com 网站上的购物车。
Amazon Dynamo 数据库背后的一群工程师于 2007 年发表了Dynamo 论文[5]。它描述了构建内部高可用键值存储的经验教训，旨在满足 Amazon.com 网站的苛刻要求。
该论文极具影响力并启发了许多 NoSQL 数据库，包括 Apache Cassandra（最初在 Facebook 开发）和 AWS 产品 SimpleDB 和 DynamoDB。2012 年，Amazon Web Services 推出了 DynamoDB，这是一种以 Dynamo 背后的原理为蓝本的托管数据库服务。
关系数据模型是对许多类型的数据进行建模的有用方法。通常，对关系数据进行规范化以提高数据的完整性。您可以将其存储在一个位置并使用从一个表到另一个表的 JOIN 操作来引用它，而不是在多行中复制一条特定的数据。你可以更新单个位置，并且引用该数据的所有的item也将获得更新的收益。
然而，Amazon.com 工程师在收集数据库需求时最有趣的发现之一是他们的工程师如何使用他们的关系数据库：
大约 70% 的操作属于键值类型，仅使用主键并返回单行。大约 20% 会返回一组行，但仍然只对单个表进行操作。——沃纳·沃格尔斯
90% 的操作没有使用关系数据库的核心 JOIN 功能！
JOIN 操作很昂贵。在足够大的规模上，工程师经常对他们的数据进行非规范化，以避免进行昂贵的join和减慢响应时间。这种响应时间的减少伴随着应用程序复杂性的增加——现在您需要在代码中而不是在数据库中管理更多的数据完整性问题。
Amazon.com工程师已经在权衡非规范化以缩短响应时间。意识到亚马逊工程师不需要关系模型，Dynamo 设计人员可以重新评估关系数据库的其他方面。
大多数关系数据库对其数据使用高度一致的模型。简而言之，这意味着如果同时查询，服务器的所有客户端将看到相同的数据。
让我们以 Twitter 为例。想象一下，弗吉尼亚州的 Bob 在下午 2:30 发布了一张猫的照片。在 Bob 发布照片后，有两个用户查看了 Bob 的个人资料：他的邻居 Cheryl 和住在新加坡的叔叔 Jeffrey。如果 Twitter 使用强一致性模型，那么 Cheryl 和 Jeffrey 都应该在 Bob 的操作提交到数据库后立即看到 Bob 的最新推文。
由于几个原因，这可能并不理想。首先，考虑一下这个场景所涉及的地理环境。Twitter 可以选择使用单个数据库实例来实现这种强一致性。此数据库实例可能位于弗吉尼亚州，靠近 Bob 和 Cheryl。这会导致对 Bob 和 Cheryl 的快速响应，但对 Jeffrey 的响应非常缓慢，因为每个请求都必须从新加坡穿越海洋到弗吉尼亚州以请求数据，然后从弗吉尼亚州返回新加坡以将其返回给 Jeffrey。这会导致某些用户的读取时间变慢。
与维护单个数据库实例不同，Twitter 可能希望拥有两个完全相同的实例——一个在弗吉尼亚州，一个在新加坡。如果我们仍然想保持强一致性，这意味着如果她同时查询弗吉尼亚实例或新加坡实例，用户必须得到相同的答案。这可以通过一个更复杂的数据库写入系统来实现——在 Bob 的推文提交到数据库之前，它必须同时提交给弗吉尼亚实例和新加坡实例。现在 Bob 的请求需要跨越大洋并返回。这会导致某些用户的写入时间变慢。
在 Dynamo 论文中，亚马逊指出，强一致性并非在所有场景中都很重要。在我们的示例中，如果 Jeffrey 和 Cheryl 看到我的个人资料的版本略有不同，即使他们同时查询也是可以的。有时您可以满足于最终的一致性，这意味着不同的用户最终会看到相同的数据视图。Jeffrey 最终会在新加坡看到 Bob 的推文，但可能是下午 2:32 而不是 2:30。
强一致性对于某些用例很重要——想想银行账户余额——但对于其他用例来说则不太重要，例如我们的 Twitter 示例或亚马逊购物车，这是 Dynamo 的推动力。对于这些用例，速度和可用性比一致更重要。通过削弱关系数据库的一致性模型，Dynamo 工程师能够提供更符合 Amazon.com 需求的数据库。
Dynamo 的最后一个关键方面是它可以无限扩展，不会对性能产生任何负面影响。这方面是放宽先前数据库的关系和一致性约束的结果。
当扩展系统时，您可以垂直扩展（使用具有更多 CPU 或 RAM 更大的服务器实例），也可以通过将数据拆分到多台机器来水平扩展，每台机器都有完整数据集的一个子集。垂直扩展很昂贵，并最终达到硬件的上限瓶颈。水平缩放更便宜但更难实现。
要考虑水平扩展，假设您有一个用户数据集，您希望将其分布在三台机器上。您可以选择根据用户的姓氏将它们拆分到机器上——A 到 H 进入机器 1，I 到 Q 进入机器 2，R 到 Z 进入机器 3。
如果您只有一个用户，这很好——检索 Linda Duffy 的调用可以直接转到机器 1——但如果您的查询跨越多台机器，则可能会很慢。获取所有 18 岁以上用户的查询将必须访问所有三台机器，从而导致响应速度变慢。
同样，我们在上一节中看到了强一致性要求如何使其难以横向扩展。我们将在写入期间引入延迟，以确保在返回写入用户之前将写入提交给所有节点。
放宽这些要求可以让 Dynamo 在不牺牲性能的情况下更轻松地进行水平扩展。DynamoDB 使用一致的散列将item分布在多个节点上。随着 DynamoDB 表中数据量的增加，AWS 可以在后台添加额外的节点来处理这些数据。
DynamoDB 通过本质上要求所有读取操作使用主键（扫描除外）来避免多机问题。在我们之前的用户示例中，我们的主键可以是姓氏，亚马逊会相应地分发数据。如果确实需要通过 Age 进行查询，则可以使用二级索引通过不同的键应用相同的分布策略。
最后，由于 DynamoDB 允许最终一致性，它允许更轻松的数据复制策略。您可以将您的item复制到三台不同的机器上并查询其中任何一台以提高吞吐量。由于最终一致性模型，其中一台机器在不同时间对item的视图可能略有不同，但对于许多用例来说，这是一个值得接受的权衡。此外，如果您的应用程序需要，您可以显式指定强一致性读取。
这些变化使 DynamoDB 能够为几乎无限量的数据提供几毫秒的查询延迟——100TB+。
十五年后（也就是前不久），亚马逊的人发布了一篇关于 DynamoDB 的新论文[6]。大多数作者都发生了变化（除了AWS VP Swami Sivasubramanian ，他同时出现在两篇上），但令人好奇的是 Dynamo 的核心概念是如何更新和更改以提供完全托管、高度可扩展的多租户云数据库服务。
论文公开了一些数据：
2021 年，在 66 小时的 Amazon Prime Day 购物活动中，亚马逊系统……对 DynamoDB 进行了数万亿次 API 调用，峰值达到每秒 8920 万次请求
从任何标准来看，每秒 8900 万个请求都是一个大型数据库（这只是 Amazon 对 DynamoDB 的使用）！
在这篇文章中，我想讨论我从新的 DynamoDB 论文中获得的主要收获：
• DynamoDB 服务的产品级“用户需求”学习；和
• 多年来的技术改进使服务得到进一步发展。
Dynamo 论文和 DynamoDB 论文都描述了一些令人难以置信的技术概念，但对用户需求的讨论同样给我留下了深刻的印象。在这两篇论文中，都对现有实践进行了深入调查，以了解什么是重要的，以及应该围绕核心用户需求重新考虑什么。
在 Dynamo 论文中，我们清楚地看到了这一点：即 RDBMS 提供的许多高级查询功能并未被 Amazon 的服务使用。70% 的数据库操作是使用主键的单记录查找，另外 20% 读取一组行但只访问一个表。
Dynamo 论文还指出，传统的强一致性保证虽然在某些情况下至关重要，但并非所有应用程序都需要。在许多情况下，通过放宽一致性要求来提高可用性和减少写入延迟是非常值得的。
正如 Dynamo 论文重新审视了传统数据库系统中的一些陈词滥调一样，DynamoDB 论文围绕使 Dynamo 学习更广泛适用的用户需求。通过这样做，DynamoDB 能够制定一组明确的产品优先级，将 DynamoDB 与许多其他数据库产品区分开来。
我从论文中获得了关于用户需求的三个重要说明：
• 恒定可预测性能的重要性
• 完全托管优于自管理
• 用户数据分布不均
DynamoDB 论文反复强调的一点是，对于许多用户来说，“任何规模的一致性能通常比中值请求服务时间更重要。” 换句话说，最好在中值和尾部延迟之间设置更窄的范围，而不是减少中值（甚至 p90 或 p95）延迟。
对于一些认为“DynamoDB 超级快”的人来说，这是一个令人惊讶的观点。以下是DynamoDB 跟 RDBMS 在数据规模与性能之间关系的对比图：
在此图表中，我们看到 RDBMS 延迟会随着数据库中数据量的增加而变差，而 DynamoDB 会随着数据的增加提供一致的性能。随着并发请求数量的增加，同样的关系也成立。
上面的图表是一个粗略的草图，但总体而言是站得住脚的。在特定级别的数据和事务量下，RDBMS 将比 DynamoDB 具有更快的响应时间。从概念上讲，这很容易理解。对 DynamoDB 的请求将通过多个系统（请求路由器、元数据系统、身份验证系统），然后再到达保存请求数据的底层物理存储节点。虽然这些系统都经过了高度优化，但它们中的每一个都为整体请求增加了延迟。相反，单节点 RDBMS 可以跳过很多工作，直接对本地数据进行操作。
所以 MySQL 可能会在中位数上击败 DynamoDB，但这还不是全部。出于两个原因，您还应该全面考虑数据库的性能。
首先，尾部延迟很重要，尤其是在具有大量组件和子组件的架构中。如果对后端的一次调用导致对底层服务的大量调用，那么每个请求更有可能经历来自某些服务的尾部延迟，从而导致响应速度变慢。
其次，DynamoDB 性能的一致性和可预测性可减少您的服务的长期维护负担。由于您的应用性能不可避免地下降，您不必回来进行调查、调整和重构。您知道您将在测试环境中获得与发布五年后相同的性能，从而使您能够专注于为用户创造更多价值的功能。
总结一下，DynamoDB 的可预测性能的核心在于：
• 对 Workload 准确抽象（WCU/RCU）
• 对 Partition 预分配配额，并严格限流
• 在 Node 上留出余量作为应对突发场景的临时资源池（Burst）
• 使用全局信息进行流量调度，在各个层面上都流控
在无服务器世界中，我们尽可能专注于构建我们业务的关键差异化因素，同时将无差异的繁重工作卸载给其他人。但是亚马逊的内部经验和 Dynamo（不是 DynamoDB）的创造者真正推动了它的发展。
回想一下，Dynamo 论文在业界具有巨大的影响力，而亚马逊的内部 Dynamo 系统在可用性和可扩展性方面对亚马逊的巨大运营规模来说是一个巨大的改进。
尽管有这种改进，许多内部工程师还是选择避开运行 Dynamo，转而使用Amazon SimpleDB，这是 AWS 首次涉足托管 NoSQL 数据库市场。
如果你从未听说过 Amazon SimpleDB，那么你并不孤单。DynamoDB 本质上是 SimpleDB 的继任者，几乎在各个方面都更胜一筹，AWS 很少再推销它。
SimpleDB 有一些真正令人惊讶的缺点，例如整个数据库的大小不能超过 10GB。对于大多数应用程序来说，这是一个巨大的限制，对于拥有如此庞大的应用程序以至于不得不设计一个全新的数据库的公司（Amazom）来说尤其如此。然而工程师选择使用多个 SimpleDB 表批量处理他们的需求，可能在应用程序层进行分片以将每个数据库保持在 10GB 以下。这不得不大大增加应用程序逻辑的复杂性。尽管如此，工程师仍然选择使用 SimpleDB 而不是操作自己的 Dynamo 实例。
Amazon 工程师的这种偏好刺激并促进了 Amazon DynamoDB 的开发，这是一个将 Dynamo 的可扩展性与 SimpleDB 的完全托管性质相结合的数据库。
最后的用户要点是，您必须与给定的用户合作，而不是与您想要的用户合作。在理想情况下，用户将拥有稳定、可预测的流量，将数据访问均匀地分布在表的键空间中。实际情况大不相同。
最初的 Dynamo 论文使用一致性哈希的概念将数据分布在大约 10GB 大小的独立分区中。（分区将在下面更深入地讨论）。它使用item的分区键跨分区放置数据，从而实现可预测的性能和线性水平扩展。
此外，与原始 Dynamo 系统不同，DynamoDB 是一个多租户系统。你的分区可能与其他 DynamoDB 用户表中的分区位于同一位置。
最初，DynamoDB 团队构建了一个系统来避免嘈杂的租户干扰问题，即一个分区的高流量会导致同一存储节点上不相关分区的体验降低。然而，随着系统的发展，他们意识到管理这个问题的初始系统会导致那些工作量激增、不平衡的workload。
随着 AWS 团队构建 DynamoDB，他们意识到他们需要改进访问控制系统，以管理是否允许分区为请求提供服务。下面我们将更多地研究这种演变的技术方面。
产品级的学习很吸引人，但这最终是一篇技术论文。DynamoDB 团队正在大规模开展的工作令人印象深刻，许多技术知识甚至适用于那些没有 DynamoDB 规模的人。
我从这篇论文中获得了三个最有趣的技术要点：
• 使用日志副本来提高持久性和可用性；
• 为改善对不平衡工作负载的服务而采取的增量步骤；
• 使用异步缓存机制来提高底层服务的性能、可用性和弹性
更有趣的一点是 DynamoDB 如何使用称为日志副本的设计在实例故障期间提供帮助。要了解日志副本，我们首先需要了解 DynamoDB 存储的底层架构的一些背景知识。
DynamoDB 存储背景部分的开始
在后台，DynamoDB 将您的数据拆分为分区，这些分区是大小约为 10GB 的独立存储段。DynamoDB 使用分区键将您的item分配给给定的分区，这允许 DynamoDB 随着数据库的增长水平扩展，同时仍将相关item保持在一起。DynamoDB 运行大量存储节点，这些节点处理来自许多不同用户表的分区。
单个分区实际上是一组位于不同可用区的三个分区实例，它们形成一个复制组。其中一个实例是该分区的leader，负责处理所有写入。当有数据写入时，leader将其写入本地，并确保在返回给客户端之前将其提交到至少一个额外的副本。这增加了发生故障时的持久性，因为丢失一个节点不会导致数据丢失。
一个分区的副本构成一个复制组。复制组使用 Multi-Paxos 进行领导者选举和共识。只有领导者副本可以服务写入和强一致性读取请求。收到写入请求后，正在写入的密钥的复制组的领导者会生成一个预写日志记录并将其发送给其对等方（副本）。...复制组的任何副本都可以提供最终一致的读取。
每个存储分区上都有两个数据结构 - B-Tree 包含分区上的索引数据以及预写日志 (WAL)，其中包含应用于该分区的更新的有序列表。预写日志是数据库中常用的策略，用于提高写入操作的持久性和延迟。更新 B-Tree 比较慢，因为它涉及随机 I/O，并且可能涉及在磁盘上重写多个页面，而更新预写日志是一个仅追加的操作，速度要快得多。
请注意，除了针对这些结构的单个操作的性能差异之外，这两个结构的大小也存在巨大差异。B-Tree的大小可以超过 10 GB（考虑到分区的 10 GB 大小以及索引开销），而预写日志只有几百兆字节（预写日志的完整历史记录是定期同步到 S3，用于支持时间点恢复和其他功能）。
DynamoDB 存储背景部分结束
当您运行像 DynamoDB 这样大的系统时，实例总是会失败。当存储节点发生故障时，您现在可能有数千个分区副本需要重新定位到非故障节点。在此故障期间，在该节点上具有副本的每个复制组现在都减少到两个副本。因为需要两个副本来确认给定的写入，所以您现在正在增加写入的延迟分布以及如果另一个副本发生故障时降低可用性的概率。
为了减少只有两个副本处于活动状态的时间，DynamoDB 使用日志副本。日志副本是仅包含预写日志的复制组的成员。通过跳过分区的 B-Tree，DynamoDB 子系统可以通过复制最后几百 MB 的日志来快速启动日志副本。此日志副本可用于确认写入，但不能用于读取。
当此日志副本在帮助复制组时，DynamoDB 子系统可以在后台运行以启动一个完整的副本成员来替换失败的成员。
看到团队为不断突破持久性、可用性和延迟的极限而进行的增量调整非常有趣。其中大部分都不会改变系统做出的核心承诺，例如在 CAP 定理上做出不同的选择。相反，它们是对数据库可靠性和性能的稳定改进。
首先，DynamoDB 使用预写日志与索引存储的标准组合来提高持久性并减少写入请求的延迟。
其次，DynamoDB 放弃了 RDBMS 的典型单节点设置，并转移到分区系统。这减少了恢复时间（这意味着可用性的提升），因为恢复 10GB 分区比恢复 200GB 表要快得多。此外，此复制跨越三个不同的可用区 (AZ)，因此整个 AZ 可以不可用而不会影响系统的可用性。
然后，DynamoDB 放宽了一致性要求，要求复制组中的三个节点中只有两个节点确认写入。以一些偶尔过时的数据为代价，DynamoDB 能够提高可用性并减少写入延迟。
最后，DynamoDB 使用日志副本来提高节点故障期间的可用性。
在上一节中，我们讨论了如何使用分区来分割表中的数据并允许水平扩展。此外，我们还看到了 DynamoDB 如何将来自不同客户的分区放在同一存储节点上，以提高 DynamoDB 服务的效率。
第二个有趣的技术要点是对这些分区的“准入控制”系统进行缓慢而稳定的改进。准入控制是指 DynamoDB 根据可用容量确定请求是否可以成功的过程。在确定这一点时，DynamoDB 正在检查两个轴的容量：
• 根据为表预置的容量，是否有可供客户使用的容量？
• 根据分区所在存储节点的总容量，分区是否有可用容量？
第一个是成本决策，因为 DynamoDB 希望确保您为他们提供的服务付费。第二个是性能决策，因为他们希望避免来自同位分区的嘈杂邻居问题。
跨分区的吞吐量均匀分布是基于这样的假设：应用程序一致地访问表中的键，并且根据大小划分分区会平均分配性能。
准入控制的第一次迭代纯粹是在分区级别。DynamoDB 会将预配置的总吞吐量除以分区数，然后将该数量平均分配给每个分区。这是最简单的系统，因为您不必逐秒协调大量分区。但是，它导致了工作负载不平衡和“吞吐量稀释”[7]问题。这可能会导致对热分区的请求受到限制。
但是，我们发现应用程序工作负载经常具有随时间和键范围的非统一访问模式。当表中的请求率不均匀时，拆分分区并按比例划分性能分配会导致分区的热点部分具有比拆分前更少的可用性能。由于吞吐量是静态分配的并在分区级别强制执行，这些非统一的工作负载偶尔会导致应用程序的读取和写入被拒绝，称为限制。
为了解决这个问题，DynamoDB 想要将准入控制与分区解耦，但意识到这将是一个很大的提升。为了解决这个问题，他们分阶段进行。
一是完善分区级准入控制系统。虽然每个分区都受到限制以防止过度消耗单个节点上的资源，但他们也意识到存储节点经常在满负荷下运行。为了帮助解决各个分区的临时流量高峰，DynamoDB 添加了短期突发，如果它可用于给定的存储节点，则可以让分区使用额外的吞吐量。这种改进主要集中在访问控制的第二个轴上——防止嘈杂的邻居。
Burst 思路很简单，在分配配额的时候， DynamoDB 会给各个 Partition 预留一部分 Capacity，就是在短期流量 spike 的时候，用这些预留的 Capacity 扛一扛；
第二个初始改进有助于访问控制的另一个轴——单个表的预置吞吐量。如前所述，具有倾斜访问模式的表可能会消耗一个分区的所有吞吐量，但仍低于表的总预置吞吐量。为了解决这个问题，DynamoDB 增加了自适应容量，Adaptive Capacity[8]，可以将稀疏使用分区的吞吐量转移到高度使用的分区。
Adaptive Capacity 就是在用户的 Workload 在其 Partitions 上出现倾斜后，动态的调整不同 Partition 的配额（但是总量不能超过原来的总配额）。
这两个变化在保持通用的基于分区的访问控制方案的同时，减轻了基于数据访问模式不均匀的大量痛苦。
后来，DynamoDB 迁移到全局访问控制系统，将吞吐量与分区完全解耦。这将自适应容量从较慢的“尽力而为”系统更改为几乎即时的系统，以将吞吐量分散到各个分区。这种灵活性带来了惊人的其他改进，包括能够将特别热点的item分离到它们自己的分区上、提供按需计费、以及根据底层分区的可预测工作负载“超载”存储节点。
所有这些都在论文的第 4 节中进行了更详细的叙述，值得您自己阅读以了解详细信息。
最后一个技术要点是 DynamoDB 对异步缓存的使用。我所说的“异步缓存”是指一个系统在本地缓存数据，然后在后台异步对缓存进行再更新，以确保其保持最新状态。
我们都知道缓存是一种通过存储高昂调用的结果来减少延迟的方法。在论文中提及，单个请求路由器实例都在本地存储外部调用的结果，以避免缓慢的网络请求。在回顾这些时，我们应该注意 DynamoDB 如何从“内部”系统处理“外部”系统（也称为“依赖项”）。
DynamoDB 使用其他 AWS 服务，例如 IAM 来验证请求或使用 KMS 来加密和解密数据。这两项服务都是外部依赖项，因为它们不受 DynamoDB 团队的控制。在这里，DynamoDB 将缓存对这些服务的调用结果，作为提高可用性的一种方式。这些结果会定期异步刷新以确保新鲜度。即使这些外部服务本身存在问题，这也允许 DynamoDB 继续工作（在某种程度上）。如果没有这个，DynamoDB 的可用性必然低于 IAM 和 KMS。
DynamoDB 还为“内部”系统使用异步缓存。DynamoDB 有一个元数据系统，用于跟踪每个 DynamoDB 分区的表信息和位置。当请求到达 DynamoDB 请求路由器时，它需要找到给定item的相关分区以将请求转发到存储节点。
此元数据信息不会经常更改，因此请求路由器会大量缓存此数据。论文指出，缓存命中率为99.75%（！！），相当不错。但是，高缓存命中率也可能导致一个问题[9]：流量轻微减少可能导致底层服务负载显著增加。将元数据缓存命中率从 99.75% 降低到仍然惊人的 99.5% 会导致对底层元数据服务的请求数量增加一倍。
DynamoDB 团队发现元数据服务必须根据请求路由器服务进行扩展，因为新的请求路由器有空缓存，导致对元数据服务的大量调用。这导致了整个系统的不稳定。
在 Request Router 和 Metadata Service 中间加了一级分布式内存缓存 MemDS，Router 的本地缓存失效后，并不直接访问 Meta Service，而是先访问 MemDS，然后 MemDS 在后台批量的访问 Metadata Service 填充数据。通过添加一层缓存进行削峰操作，相当于再加一层保险，属于常见的手段。
为了提高其内部系统的弹性，DynamoDB 使用异步缓存刷新来为底层元数据系统提供恒定负载。虽然请求路由器将以高命中率在本地缓存，但每次命中都会导致对元数据服务的关联请求以刷新缓存的数据。
第二个手段比较巧妙，刚才提到 Router 事实上是通过 MemDS 获取元信息，当请求在 MemDS 的时候没命中的时候好理解，但是 MemDS 巧妙地方在于：即使缓存命中，MemDS 也会异步访问 Meta Service。1) 尽可能保证 MemDS 中已有缓存能被及时更新; 2) 给 MetaService 带来一个’稳定‘的流量；
通过将本地缓存命中与对元数据服务的异步请求配对，它可以确保元数据服务的流量更加一致。缓存命中和缓存未命中都会导致对元数据服务的请求，因此增加具有冷缓存的请求路由器的数量不会导致元数据服务的新流量激增。
亚马逊再次帮助推动了我们对深层技术主题的理解。正如 Dynamo 论文在设计新的数据库架构方面具有革命性意义一样，DynamoDB 论文是运行和发展大规模托管系统的重要课程。
在这篇文章中，我们从 DynamoDB 论文中的用户需求角度研究了核心设计要素。然后，我们研究了论文中的一些技术设计点。
该论文还有许多没有涉及的其他有趣点，例如Serverless、存储的 GC 策略、分布式事务等、DynamoDB 如何通过检测内部 Amazon 服务来监控客户端可用性、用于针对大量实例部署新版本 DynamoDB 的策略以及用于防止数据错误机制，无论是在inflight还是在静止时。让我们对未来保持期待！
[1]The Dynamo Paper:https://www.dynamodbguide.com/the-dynamo-paper
[2]The DynamoDB paper:https://brooker.co.za/blog/2022/07/12/dynamodb.html
[3]Key Takeaways from the DynamoDB Paper:https://www.alexdebrie.com/posts/dynamodb-paper/
[4]DynamoDB 2022 论文解读:http://blog.0xffff.me/posts/dynamodb-2022/
[5]Dynamo 论文:http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
[6]关于 DynamoDB 的新论文:https://www.usenix.org/system/files/atc22-elhemali.pdf
[7]“吞吐量稀释”:https://hackernoon.com/beware-of-dilution-of-dynamodb-throughput-due-to-excessive-scaling-4df51063edae
[8]自适应容量，Adaptive Capacity:https://aws.amazon.com/blogs/database/how-amazon-dynamodb-adaptive-capacity-accommodates-uneven-data-access-patterns-or-why-what-you-know-about-dynamodb-might-be-outdated/
[9]高缓存命中率也可能导致一个问题:https://www.gomomento.com/blog/the-biggest-miss-in-your-cache-hit-rate
| 留言与评论（共有 0 条评论） “” |
