Dynamo 数据存储的成功激励了亚马逊机器学习副总裁 Swami Sivasubramanian（右上）、Amazon.com 首席技术官 Werner Vogels（右下）和同事撰写 Dynamo 研究论文，并在 2007 年 ACM 操作系统原理研讨会（SOSP 会议）上分享。Dynamo 论文被认为是 NoSQL 的开篇之作。Amazon DynamoDB，云托管 NoSQL 数据库服务于10年前的今天走上历史舞台。

为纪念 Amazon DynamoDB 推出 10 周年，我们向 Swami 询问了三个关于 Amazon DynamoDB 的起源、前身以及未来的问题。

Swami：提到 2007 年，我必须从 2004、2005 年回顾开始。即使我正在攻读博士学位（Swami 于 2006 年从阿姆斯特丹自由大学获得计算机科学博士学位），我也在考虑我将在哪里工作。最终说服我以研究工程师实习生的身份加入亚马逊，是因为我看到了亚马逊正在快速成长，突破规划的界限。

我承认我作为一个局外人有点怀疑。那时，亚马逊云科技甚至还不存在。但是当我加入时，很快就有了一个“瞬间”——亚马逊是一家电子商务公司，但实际上它是一家也从事电子商务的科技公司。看到亚马逊必须发明如此多的新技术来支持其电子商务工作量，这对我来说是一个有趣的启示。

作为一名实习生，我在 Amazon.com 担任工程师，在假期流量高峰期间，由于数据库事务死锁问题，我们经历了严重的扩展失败。这个问题是由我们当时使用的商业供应商的关系数据库引起的。一群工程师聚在一起编写了我们所说的 COE（correction of errors document），这是一份错误更正文档，我们在其中说明发生了什么、我们学到了什么、我们如何解决问题以及如何避免再次发生。

我不知道是我太天真还是只是对只有 20 岁的实习生有信心，但我问了一个问题‘我们为什么要为这种负载使用关系数据库？这些工作负载不需要 SQL 级别的复杂性和事务保证。

这让我们开始重新思考如何设计底层数据存储。当时还没有一个可伸缩的非关系数据库。这就是我们着手搭建 Amazon Dynamo 原始版的原因，也是我们撰写论文的原因。Amazon Dynamo  并不是我们当时唯一在思考研究的架构。我们意识到我们还需要一个可扩展的存储系统，Amazon S3 就诞生于此，我们还意识到我们需要一个更易于管理的关系数据库，能够进行自动复制、故障切换和备份/恢复，这也是我们创建 Amazon RDS 的初衷。

我们最初写 Dynamo 论文时定了一条规则，即“在我们开发原始设计时不要发布”，而是首先让 Dynamo 在支持多个 Amazon.com 服务的生产环境中运行，这样 Dynamo 论文将是一种端到端的撰写与经验背书。Werner 和我对此感觉非常强烈，因为我们不希望仅仅撰写一篇学术论文。这就是为什么当 10 年后那篇论文获得ACM的时间考验奖（由 ACM 主办的 The SIGOPS Hall of Fame Award，从 2016 年开始评选过去十年科技圈最具影响力的论文名人堂）时，我感到非常自豪。

Swami：Amazon DynamoDB 背后的想法来自于与 SmugMug 和 Flickr 的首席执行官 Don MacAskill 等客户的讨论。其实，他们就是最早带有互联网属性的公司，而在当时像这样的互联网公司也在快速走向市场。在线用户数量呈爆炸式增长，数据模式不固定，追求快速交付，轻运维，是他们的特征。将所有数据存储在一个盒子中的传统关系数据库模型无法很好地扩展，它迫使用户重新分片他们的关系数据库，然后管理所有的分区和重新分区等等。

这对我们来说并不新鲜。这些挑战是我们构建原始 Amazon Dynamo 的原因，当时它还不是一项服务，还是一个由亚马逊工程师操作的软件系统。在我们的一次客户咨询会议上，Don 说：“你们都启动了 Amazon Dynamo，并展示了可扩展的非关系数据库系统的可能性。为什么我们不能将其作为外部服务？”

当时，所有高级亚马逊云科技高管都在场，这也是我们当时问自己的一个问题。Don 不是唯一需要它的客户，越来越多的客户想要那种无需处理分区和重新分区的可扩展数据库，而且他们还想要极高的可用性。逐渐的，我们开始认真思考构建一个不受 SQL 限制的可扩展云数据库。

Amazon DynamoDB 与原始 Amazon Dynamo 不同，因为它实际上是通过几个原始 Amazon Dynamo 组件搭建了一易于使用的云服务。我们的客户不再需要配置集群，通过创建一个表（Table）存储数据，就可以实现并无缝缩放；他们不必任何操作，甚至无需安装单个库来操作数据库。

Amazon Dynamo 到 Amazon DynamoDB 的这种演变非常重要，因为我们真正以前所未有的方式拥抱云，以及它的弹性和可扩展性。

我们于 2012 年 1 月 18 日推出它，一经推出就大受欢迎。Don MacAskill 的公司和其他几家公司开始使用它。从发布之日起，不仅弹性，而且个位数的延迟性能都与客户产生了非常好的共鸣。我们进行了相当多的创新，从协议层一直到 SSD 存储的底层存储层，以及我们启用的各种其他功能。最早的生产项目之一是有一个有趣用例的客户；他们在做超级碗（Super Bowl：全国橄榄球联盟决赛，全美直播的体育界春晚）广告。 

因为 Amazon DynamoDB 非常有弹性，它可以无缝地扩展到每秒 100,000 次写入，然后在超级碗结束后缩减，这样他们就不会再产生额外成本。

这在技术领域也是个大事件，现在我们司空见惯的横向扩展与弹性，对当时的数据库来说还不具备这样的想象空间。但是 Amazon DynamoDB 为云而构建的架构使所有这些横向扩展用例成为可能，这也是 Amazon DynamoDB 现在支持多个高流量 Amazon 站点和系统（包括 Alexa、Amazon.com 和所有 Amazon）的履行中心的原因之一。

去年，在我们 66 小时的 Prime Day 期间，这些来源进行了数万亿次 API 调用，而 Amazon DynamoDB 以个位数毫秒的性能保持了高可用性，达到每秒 8920 万个请求的峰值。

自 2012 年以来，我们增加了许多创新，不仅是因为它的基本可用性、耐用性、安全性和规模，而且还因为它的易用性功能。

我们不止步于键值存储，还支持基于哈希的分区和基于范围的分区，并且我们增加了对二级索引的支持，以支持更复杂的查询功能——同时不影响规模或可用性。

我们现在还支持通过适用于 Amazon DynamoDB 的 Amazon Kinesis Data Streams 捕获可扩展的流式数据。我坚信任何数据库的工作都不应该是一个孤岛，更不可能是死胡同。它应该生成变化的数据流，然后使用它来将其连接到分析应用程序或其他数据存储。

我们继续在备份和恢复等功能上进行全面创新。对于像 Amazon DynamoDB 这样具有数百万个分区的大型数据库系统，进行备份和恢复并非易事，许多伟大的创新都致力于让客户轻松体验这种体验。

我们还添加了创建全局表（Global Table）的功能，以便客户可以实现数据库负载的全球覆盖的同时，具备本地读写性能。然后我们增加了使用 Amazon DynamoDB 进行事务的能力，所有这些都着眼于您如何继续保持 Amazon DynamoDB 围绕可用性和可扩展性的使命。

最近，我们还致力于更强的成本优化。客户通常需要长期存储数据，虽然这些旧数据可能很少被访问，但它必须保持高度可用。

例如，社交媒体应用程序的最终用户很少访问较旧的帖子和上传的图像，但应用程序必须确保在请求时可以立即访问这些工件。这种不经常访问的数据可能会给客户带来巨大的存储费用，因为它们的数量不断增长，并且存储这些数据的成本相对较高，因此客户在这些情况下通过编写代码将较旧、访问频率较低的数据从 Amazon DynamoDB 移动到成本较低的存储来优化成本 Amazon S3 等替代品。

因此，在最近的 re:Invent 大会上，我们推出了 Amazon DynamoDB Standard-Infrequent Access 表类，这是一个新的经济高效的表类，用于存储不经常访问的数据，同时保持 Amazon DynamoDB 的高可用性和性能。

我们将保持 Amazon DynamoDB 的最初愿景作为指引，持续创新，以帮助客户提供更易于查询的用例、进行复杂的全局事务复制的能力，同时继续管理成本。

Swami：当我们十年前开始使用 Amazon DynamoDB  时，客户才刚刚开始更好地理解云本身——它的好处以及他们可以做什么。

现在，我们生活在这样一个世界中，就客户如何 IT 应用程序而言，云是新常态，而规模也是新常态，每个应用程序都要基于不确定性构建。Amazon DynamoDB 本身将在这个持续的旅程中，我们将继续代表客户进行创新。我们将继续朝着端到端的现代化数据战略使命迈进。因为正如我之前提到的，“没有数据库是孤岛”。

客户不再只想在他们的数据库中存储和查询数据。然后，他们想要分析这些数据以创造价值，无论是更好的个性化或推荐引擎，还是可以使用机器学习运行预测分析的预测系统。

将点对点连接起来，并继续使 Amazon DynamoDB 更安全、更可用、更高性能和更易于使用，这将是我们永无止境的旅程。