亚马逊首席技术官Werner Vogels曾表示：“我们非常高兴推出Amazon DynamoDB，一种快速、可靠且具有成本效益的 NoSQL 数据库服务，专为互联网规模的应用程序而设计。” Amazon DynamoDB代表了亚马逊在大型非关系型数据库和云服务技术领域15年持续投入的成果。

Vogels表示：“我们早在2007年就发表了有关亚马逊Dynamo技术细节的论文，并以此奠定了首批非关系型数据库的雏形。最初的Dynamo基于一套强大的分布式系统原则设计，并生成了一个可随意扩展和高可靠的数据库系统。Amazon DynamoDB继续基于这些原则构建，也是亚马逊多年运行大规模非关系型数据库和云服务（如Amazon SimpleDB和Amazon S3）的经验积累。很高兴看到我们的探索和经验转化为易于使用的托管服务，并提供给我们的客户。”

亚马逊云科技数据库、数据分析、机器学习副总裁Swami Sivasubramanian和Vogels同为2007年Dynamo论文的合著作者之一。Swami是Amazon DynamoDB开发的主要贡献者，那时他是一名从事分布式系统技术设计、实施和分析相关工作的亚马逊研究工程师。

Amazon DynamoDB发布十年之际，Swami表示：“我们正在经历数据和机器学习的‘文艺复兴’时代。如今企业可以将数据存储在这些数据库中，并快速开始在 Amazon S3 中构建自己的数据湖，然后就可以立刻开展数据分析，并在几周甚至几天时间内就能通过Amazon SageMaker实现人工智能赋能，这真的非常了不起。我非常期待现在能有机会帮助客户更快地从数据中获得洞察。客户真的希望将数据‘物以致用’，实现数据驱动的决策。越来越多的CIO和企业意识到这将成为数据使用者的‘生存法则’，那些有能力将数据应用于实际工作的人将披荆斩棘，无往不利。”

以下Swami与我们分享了Amazon DynamoDB的起源、前身以及未来。

关于Dynamo的起源 

Swami：我们在2007年发表了Dynamo论文，探讨这个话题之前，我们需要先追溯到2004、2005 年。那时我正在攻读博士学位，（并随后于2006年从阿姆斯特丹自由大学获得计算机科学博士学位），也在考虑我将在哪里工作。看到亚马逊正在快速成长，并不断突破常规，打破界限，我选择了以亚马逊研究工程师实习生的身份加入亚马逊。

那时亚马逊云科技还不存在，加入亚马逊后，我很快意识到作为一家电子商务公司，亚马逊实际上也是一家科技公司。为了支持自身电子商务业务相关的各类运营场景和工作负载，亚马逊涌现出了大量创新技术、专利和发明，这种情形在全球任何一家公司都难得一见。

在亚马逊担任工程师时，我和团队曾在假期流量高峰期间经历过一次严重的扩展失败。这是由数据库事务死锁而导致的，其背后正是亚马逊当时使用的商业关系型数据库。故障发生后，我们一群工程师们一起编写了一份错误更正文档，对发生了什么、学到了什么、如何解决问题以及如何避免问题再次发生等进行了详细说明。

我当时问了一个问题：“为什么我们要为这些工作负载使用关系型数据库？本质上，它们并不需要 SQL 级别的复杂性和事务保证。”

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

最初撰写Dynamo论文时，我们就定了一条规则，即“在开发原始设计时不对外发布”，而是先将Dynamo运行于支持多个Amazon.com服务的实际生产环境中。这样，Dynamo论文就会是一种端到端的可用方案，并有实际应用经验。Werner和我对此感受非常强烈，因为我们不希望仅仅撰写一篇学术论文而已。10年后，我们非常荣幸的是Dynamo论文还获得了ACM的时间考验奖，这是由ACM主办的The SIGOPS Hall of Fame Award，从2016年开始评选过去十年科技圈最具影响力的论文名人堂。

构建Amazon DynamoDB的初衷及其过去十年的演进 

Swami：Amazon DynamoDB背后的想法来自于与SmugMug、Flickr等客户首席执行官的对话和讨论。他们是最早带有互联网属性的公司，而在当时类似这样的互联网公司正在快速走向市场。他们的典型特征包括在线用户数量呈爆炸式增长、数据模式不固定，追求快速交付和轻运维等。传统关系型数据库将所有数据存储在一个盒子中，无法高效地扩展，这迫使用户需要对其数据库重新分片，然后还需要管理所有的分区和重新分区等，这让用户面临巨大的运维挑战和压力。

这对我们来说并不新鲜，构建原始Amazon Dynamo的初衷正是应对这些挑战。当时，Amazon Dynamo还不是一项服务，而是一个由亚马逊工程师构建的软件系统。在一次客户咨询会议上，时任Flickr 首席执行官Don MacAskill表示：“你们已经启用了 Amazon Dynamo，验证了可扩展非关系型数据库系统的可行性，为什么不能把它作为外部服务提供给我们使用？”

当时，所有亚马逊云科技的相关管理人员都在场，实际上，这也是我们问自己的一个问题。Flickr并不是唯一需要它的客户，越来越多的客户想要可扩展的数据库，无需处理分区和重新分区等复杂的运维工作，同时他们还需要极高的可用性。于是，我们开始认真思考构建一个不受SQL API限制的、可扩展的云数据库。

Amazon DynamoDB与原始Amazon Dynamo不尽相同，它实际上是通过几个原始Amazon Dynamo组件搭建的一项易于使用的云服务。客户不再需要配置集群，只需创建一个表存储数据，即可轻松实现无缝缩放。管理员不必执行任何操作，甚至无需安装单个库来操作数据库。

Amazon Dynamo到Amazon DynamoDB的演变非常重要，亚马逊真正以前所未有的方式拥抱云，获得它的弹性和可扩展性。

我们在2012年1月18日正式发布Amazon DynamoDB，该服务一经推出就大受欢迎，Flickr等公司率先使用该服务。Amazon DynamoDB强大的弹性、个位数毫秒的延迟性能等深受客户青睐。我们进行了大量创新，从协议层一直到SSD存储的底层存储层等各项功能。

这里不得不提的一个有趣的用例，也是最早将DynamoDB投入生产的客户之一，他们做的是超级碗（Super Bowl：全国橄榄球联盟决赛——全美直播的体育界春晚）广告投放。 因为Amazon DynamoDB具备强大的弹性，可以无缝地扩展到每秒100,000次写入，并在超级碗活动结束后缩减，这样客户就不会担心产生额外的成本。当年，这在技术领域是个大事。现在大家习以为常的横向扩展与弹性，对当时的数据库而言，那是无法想象的.

那是一个大胆的设想。Amazon DynamoDB专为云而构建的架构让所有横向扩展用例成为可能。现在，Amazon DynamoDB正为多个高流量Amazon站点和系统提供支持，包括 Alexa、亚马逊全球电商网站和所有亚马逊运营中心。2021年，在亚马逊长达66小时的Prime会员日大促期间，上述站点和系统进行了数万亿次API调用，Amazon DynamoDB以低至个位数毫秒延迟的高性能表现，无感支持峰值达每秒8,920万个请求，同时确保系统的高可用性。

Amazon DynamoDB自2012年问世以来，我们为其增加了大量创新功能，不仅涉及底层可用性、持久性、安全性和规模等特性，还包括易用性等。

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

现在，Amazon Kinesis Data Streams也适用于Amazon DynamoDB，捕获可扩展的流式数据。我认为任何数据库都不应该是孤岛，更不能是死胡同。它应该支持生成变化的数据流，然后将这些数据流连接到分析应用程序或其他数据存储。

同时，我们也针对备份和恢复等功能全面创新。对于像Amazon DynamoDB 这样具有数百万个分区的大型数据库系统而言，备份和恢复并非易事，我们致力于通过创新让客户获得更好的体验。

我们还为Amazon DynamoDB添加了创建全局表的功能，以便客户可在轻松实现数据库负载全球覆盖的同时，获得近乎本地运行的读写性能。此外，Amazon DynamoDB还扩展了事务处理能力。所有这些创新都致力于不断提升Amazon DynamoDB的可用性和可扩展性。

我们同时致力于为客户提供更高的成本效益。客户通常需要长期存储数据，虽然这些旧数据可能很少被访问，但它必须保持高度可用，以便不时之需。例如，社交媒体用户很少访问旧的内容和图片，但一旦有这类访问请求，需要确保可以立即为用户提供这些内容。这种不经常访问的数据可能会给客户带来高昂的存储费用，而且这类数据的数量还在不断增长。过去，为了优化成本，客户会通过编写代码的方式，将旧的、访问频率较低的数据从Amazon DynamoDB 移动到存储成本较低的如Amazon S3中。

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

不忘初心，我们始终将DynamoDB的最初愿景作为指引，持续创新，为客户提供更易于查询的用例，支持进行复杂全局事务复制等，不断扩展能力范围，同时持续优化管理成本。

展望Amazon DynamoDB的未来十年

Swami：十年前，当我们推出Amazon DynamoDB 时，客户才刚刚开始对云本身有了更好的理解，它的好处是什么，可以做什么。

如今，就客户构建IT应用程序而言，云已经成为的新常态，规模也是新常态，每个应用程序都需要基于不确定性构建。我们将继续代表客户进行创新，Amazon DynamoDB本身也在这个持续变革的旅程中。我们将继续朝着端到端的现代化数据战略迈进。正如之前提到的，数据库不应该是孤岛。

客户将不再只想在数据库中存储和查询数据，他们需要分析这些数据来创造价值，无论是通过创建更好的个性化推荐引擎，还是使用机器学习运行预测分析的预测系统。将数据流点对点无缝连接，并继续让Amazon DynamoDB更安全、高可用，性能更强且易于使用，这些都将是我们永无止境的追求。

这里必须感谢Aslett全力以赴的为我们呈现这个数据库领域视觉盛宴。

因此，选择一个合适的数据库对于游戏的成功就格外重要了。许多数据库都能支持少量的DAU。但是，当游戏玩家暴涨时，最好能有一个始终传递高性能同时支持更大量DAU的数据库。否则，如果你的游戏会因不能拓展而被玩家抛弃，那么你制作出这么一款有趣的游戏的努力就付诸东流了。

因为性能和延展性的优势，NoSQL数据库越来越多地用于社交游戏。但开源代码的NoSQL数据库项目似乎就像雨后春笋，在世界各地萌发，要从中做出选择可能是件棘手的工作。为社交游戏选择正确的NoSQL数据库可能非常困难，因为有各种各样的分类，如key-value、文件和纵列等。但哪一类才是最适合社交游戏的呢？

zynga-chart(from devopsangle.com)

key-value和文件型数据库可以增强大多数NoSQL对社交游戏的资源配置能力，这很大程度上是因为它们平衡以下4个关键指标：

1、NoSQL支持高性能。文件和key-value数据模式在内存和硬盘（文件）的单一物理空间中保存相关数据。这使用户可以始终快速地获取数据——避免读取和写入时时发生延迟。现在的游戏玩家不能忍受哪怕是最短的中断时间，否则他们就会认为程序很失败，然后就不再使用了。你要寻找的就是一种可以稳定维持毫秒读取和写入的数据库。

2、NoSQL具有动态弹性。因为文件方法将记录保存在“单独的地方”（一个文件放在邻近的物理位置中），所以要从一个服务器把数据转移到另一个上，同时保持连贯性、不发生中断，就要容易得多了。为了使数据库的工作能力与程序的总体性能要求有效匹配，必须在服务器之间转移数据，数据库必须能够增加或移除群集。如此操作的同时又不中断游戏的收益流，这对游戏的盈利性有重要影响。只需轻轻点击一个按扭就把服务器添加到数据层中，不需要改变程序本身，你要寻找的就是这样的数据库。

3、NoSQL具有架构灵活性。虽然所有NoSQL数据库都具有架构灵活性，但key-value和文件型数据库在这方面的优势更明显得多。在增加新纵列和分类时，纵列型数据库仍然需要维护。key-value或文件型数据库不需要数据库维护就能改变数据库架构。

4、NoSQL支持询问变更。用询问表现力（向数据库发问的能力，比如，“返回一份记录玩家于去年购买向日葵种子的所有农场的列表”）平衡架构灵活性往往是很重要的。文件型数据库在数据库层上提供索引和查询，而key-value型数据库只允许访问与给定键相关的数据记录。

如果你在考虑开发一款社交游戏，请考虑一下支持游戏成长的基础设施要求。正如我们所说的，管理社交游戏中的数据是最重要，也是很灵活的事。并行随机读取和吞吐率、数据格式灵活性都是NoSQL文体型数据库能应对的。你的数据库技术是最重要的基础建设组成部分。

via：游戏邦/gamerboom.com

在过去的一年中，围绕着NoSQL和Hadoop，基本的存储与数据处理引擎方面的改进工作得到了加强并且日趋工程化。毫无疑问，这种态势将会持续 下去，因为我们看到了Hadoop世界中有越来越多形态各异的产品融入到了各种发布包、设备和按需的云服务当中。我衷心希望在不远的将来Hadoop能够 成为必要的基础设施。

现在，已经出现了一些面向程序员与数据科学家的工具（例如Karmasphere和Datameer），此外，还有面向已经建立起来的分析工具的Hadoop连接器（例如Tableau和R）。但还有一种方式可以让大数据变得更为强大，那就是降低实验的成本。

下面两种方式可以使大数据变得更为强大。

• 更好的编程语言支持。因为我们将数据而非业务逻辑作为程序中的主要实体，所以必须要创建或再去探索一些方言，使我们能够将精力放在数据而非底层 Hadoop设施所透露出来的抽象上面。换句话说，编写更简短的程序，能够更清晰地表达出我们对数据所做的处理。这些抽象将有助于为非程序员创建更好的工 具。
• 需要提供更好的交互支持。如果说Hadoop有缺点，那么其缺点也在于它所孕育的批量化处理的计算本质。数据科学的敏捷本质决定了它钟爱于能够提供更好交互性的工具。

流线化的数据处理

Hadoop批量化的处理对于很多场合都足够用了，特别是数据报告的频率不需要达到分钟级别的场合。然而，批量化处理并非总能满足我们的要求，特别是对于移动和Web客户端等在线需求，或是财务和广告等需要实时变化的市场。

在未来几年中，用于处理流线化或接近实时的分析与处理的可伸缩框架和平台将会得到采用。Hadoop将会支持大规模的Web应用，这些平台将会由大规模位置感知的移动、社交和传感器应用所推动。

对于某些应用来说，已经没有足够的空间来存储业务接收到的所有数据：在某一时刻，你需要扔掉一些东西。凭借流线化的计算能力，你可以对数据进行分析 并决定扔掉哪些数据而不必查看map/reduce的“存储—计算”循环。在实时框架领域中，新涌现的竞争者有来自Twitter的Storm和 Yahoo!的S4。

数据市场的兴起

当与其他数据集混合到一起时，你自己的数据会变得更有说服力。比如说，将天气状况添加到客户的数据中，检查是否有与客户购买模式相关的天气模式。获 取这些数据集是个让人头疼的问题，特别是在IT部门之外做这件事，并且要求一定的精度时更是如此。数据市场的价值在于为这种数据提供了一个目录，以及流线 化、标准化的交付方法。微软将其Azure市场集成到分析工具中的做法预示了我们今后能更加方便地访问数据了。

数据科学工作流与工具的开发

随着数据科学团队不断为各个公司所认可和接受，其角色和流程将会变得更加正规化。成功的数据科学团队的驱动力之一就是其与公司经营活动的集成程度，这与成为边缘的分析团队截然相反。

软件开发者已经拥有了大量富于逻辑与社交性质的基础设施，这包括wiki与源代码控制，以及用于将其流程和需求公开给企业主的各种工具。集成的数据 科学团队需要自己的一套工具才能高效协作。其中之一就是EMC Greenplum的Chorus，它提供了针对数据科学的一个社交软件平台。使用这些工具有助于组织中数据科学处理的不断涌现。

数据科学团队将会逐渐开始一些重复的流程，我们希望这是敏捷的。相比诸如The Guardian和NewYork Times之类的新闻组织的新闻数据团队所做的开创性工作：只要给定一个不长的时间表，这些团队就可以将原生格式的数据转换为成品，这需要与记者携手来完 成。

对可视化的理解和需求的提升

可视化在数据工作流中能够实现两个目的：解释与探索。虽然业务人员可能将可视化看作是最终结果，但数据科学家还会将可视化作为寻求问题以及探索数据集新特性的一种方式。

如果说成为数据驱动的组织需要培养所有员工拥有更好的数据感觉的话，那么可视化在将数据操纵能力传递给那些不会编程或缺乏统计分析技巧的员工的过程中就扮演着重要角色。

过去的整整一年，业务对数据科学家的需求一直都是如此。我不断地听到数据科学家说，他们最想要的是：懂得创建可视化的人才。

Via Programmer