亚马逊 CTO：为什么提供这么多数据库产品？因为宝藏就在数据库中

6月21日，亚马逊(Amazon.com)首席技术官(CTO) Werner Vogels发表博文，对亚马逊为何要在数据库领域重金投入，并打造如此之多的数据库产品的原因进行了解析，并列举了大量的案例。

在今年的AWS峰会上，AWS又发布了一系列新的服务，毫无疑问，数据库服务绝对是AWS投入的重点之一。虽然没有像去年11月份的AWS re：Invent大会上那么丰富，但依然占有很大比重。

从下图可以看到，AWS 所提供的数据库服务品类丰富程度。

6月21日，亚马逊 CTO Werner Vogels发表博文，对亚马逊为何要在数据库领域重金投入，并打造如此之多的数据库产品的原因进行了解析。

此前，他在就曾表示，数据是大部分企业业务的核心，而使业务独特的原因所在，是所拥有的数据、数据的质量以及如何利用这些数据，这使得数据存储越来越重要，宝藏就在数据库中。两年来，AWS通过其数据库迁移服务迁移了超过60000个数据库。

他指出，亚马逊提供众多数据库产品供用户选择，是因为一刀切的数据库时代已经成为过去式，尽管目前关系数据库保持活跃，并且仍然适用于许多应用场景，但针对键值，文档，图形，内存和搜索等应用场景的专用数据库却能更高效的解决问题，更为重要的是，客户体验会更好。

以下为Werner Vogels博客原文：

我经常被人问到一个问题，为什么亚马逊要提供这么多的数据库产品?对我来说，答案很简单，开发者希望他们的应用程序能够很好的被构建和有效扩展，为此，他们需要能够在同一应用程序中使用多个数据库和数据模型。

很少有一个数据库能够满足多个不同应用场景的需要，一刀切的数据库时代已经过去，开发人员正在使用大量的专用数据库来构建高度分布式的应用程序。开发人员正在做他们最擅长的事情：将复杂的应用程序分解成更小的部分，然后选择解决每个问题的最佳工具。工作中的最佳工具通常因应用场景而异。

过数十年来，因为唯一的数据库选择只有关系数据库，无论应用程序中的数据类型或功能如何，数据都被建模为关系数据，而不是应用场景驱动对数据库的需求。关系数据库是否专为非规范化模式构建，并在数据库中强制引用完整性?当然，最关键的一点是，并非所有应用程序的数据模型或应用场景都与关系模型匹配。

正如我之前谈到的那样，我们构建Amazon DynamoDB的原因之一，是因为当时亚马逊正在突破商业数据库的极限，我们无法维持不断增长的亚马逊业务所需要的可用性，可扩展性和性能需求。我们发现大约70%的操作是键值查找，其中仅使用主键并返回单行。在不需要引用完整性和事务的情况下，我们意识到，使用不同类型的数据库可以更好的服务于这些访问模式。此外，随着Amazon.com的增长和规模的扩大，无限的横向扩展需要成为一个关键的设计点 - 扩大规模根本不是一种选择。这最终导致了DynamoDB，这是一种非关系数据库服务，构建的目的是扩展关系数据库的范围。

但这并不意味着关系数据库不能在当今的开发中不可用，恰恰相反。事实上，我们的客户已经证实这一点，因为Amazon Aurora仍然是AWS历史上增长最快的服务。我们在Amazon.com网站上看到的是超出其预期目的使用数据库。这篇博文的核心就是学习 - 数据库是为了某个目的而构建，将应用场景与数据库相匹配将有助于您更快地编写高性能，可扩展且功能更强大的应用程序。

专用数据库

世界仍在变化，非关系数据库的种类不断增加。我们越来越多地看到客户想要构建需要各种数据模型的互联网级应用程序。针对这些需求，开发人员现在可以选择关系，键值，文档，图形，内存和搜索数据库。每个数据库都解决了一个特定问题或一系列问题。

让我们仔细看看每个数据库的目的：

· 关系：关系数据库是自描述的，因为它使开发人员能够定义数据库的架构以及数据库中行和表之间的关系和约束。开发人员依赖关系数据库的功能(而不是应用程序代码)来强制执行架构并保持数据库中数据的引用完整性。关系数据库的典型应用场景包括Web和移动应用程序，企业应用程序、在线游戏。Airbnb是使用Amazon Aurora构建的高性能和可伸缩应用程序的一个很好的例子。Aurora为Airbnb提供了一种完全管理，可伸缩且功能强大的服务来运行他们的MySQL工作负载。

· 键值：键值数据库具有高度可分区性，并允许在其他类型的数据库无法实现的级别上进行水平扩展。诸如游戏，广告技术和物联网等使用案例特别适合于键值数据模型，这种模型中，访问模式需要低延迟的get/put已知的键值。DynamoDB的目的是为任何规模的工作负载提供一致的单位毫秒级延迟。这种一致的性能是Snapchat Stories功能(包括Snapchat的最大存储写入工作负载)转移到DynamoDB的重要组成部分。

· 文档：文档数据库对于开发人员来说是很直观的，因为应用层中的数据通常表示为JSON文档。开发人员可以使用他们在应用程序代码中使用的相同文档模型格式来保存数据。Tinder是使用DynamoDB的灵活模式模型来实现开发人员效率的一个示例。

· 图形：图形数据库的目的，是使构建和运行具有高度连接数据集的应用程序变得容易。图形数据库的典型应用场景包括社交网络，推荐引擎，欺诈检测和知识图谱。Amazon Neptune是一个完全托管的图形数据库服务。Neptune同时支持属性图模型和资源描述框架(RDF)，可选择两个图形API：TinkerPop和RDF / SPARQL。目前Neptune的用户正在建立知识图，提供游戏内推荐建议以及检测欺诈行为。例如，Thomson Reuters正在帮助他们的客户通过使用Neptune来驾驭复杂的全球税收政策和法规网络。

· 内存：内存数据库在金融服务，电子商务，网络和移动应用程序都有应用场景，如排行榜，会话存储和实时分析，这些场景需要微秒级的响应时间，并且随时可能出现大量流量高峰。我们提供Memcached和Redis的Amazon ElastiCache，以服务于低延迟，高吞吐量的工作负载，如麦当劳，而基于磁盘的数据存储是无法满足这些工作负载的。Amazon DynamoDB加速器(DAX)是专用数据存储的另一个示例。DAX的构建是为了让DynamoDB的读取速度提高一个数量级。

· 搜索：许多应用程序输出日志，以帮助开发人员解决问题。Amazon Elasticsearch Service(Amazon ES)旨在通过索引，汇总和搜索半结构化日志和指标来提供机器生成数据的近实时可视化和分析。Amazon ES还是一个强大的、高性能的全文搜索引擎。Expedia正在使用150多种Amazon ES域、30 TB的数据和300亿个文档，用于各种关键任务应用场景，从操作监控和故障排除到分布式应用程序堆栈跟踪和定价优化。

用专用数据库构建应用程序

开发人员正在构建高度分布式和解耦的应用程序，而AWS使开发人员能够通过使用多个AWS服务构建这些云本地应用程序。

例如 Expedia，虽然Expedia的网站看起来就像是一个单一的应用程序，但在后台，Expedia.com由许多组件组成，每个组件都有特定的功能。通过将一个应用程序(如Expedia.com)分解为具有特定任务的多个组件(例如：微服务，容器和AWS Lambda函数)，开发人员可以通过增加规模和提高性能，减少操作，提高部署灵活性，并使不同的组件能够独立的演化来提高生产率。在构建应用程序时，开发人员可以将每个应用场景与最适合需要的数据库进行匹配。

为了实现这一点，请看看我们的一些客户正在使用多种不同类型的数据库来构建他们的应用程序：

· 作为个性化搜索的一部分，Airbnb使用DynamoDB来存储用户的搜索历史记录以进行快速查找。Airbnb还使用ElastiCache在内存中存储会话状态以加快网站呈现速度，并将Amazon RDS上的MySQL 用作其主要事务数据库。

· Capital One 使用Amazon RDS存储状态管理的事务数据，Amazon Redshift存储为需要聚合分析的Web日志，并使用DynamoDB存储用户数据，以便客户可以使用Capital One应用程序快速访问他们的信息。

· Expedia 通过使用Aurora，Amazon Redshift和ElastiCache构建了一个实时数据仓库，用于内部市场分析和市场定价。数据仓库使用ElastiCache for Redis执行 multistream 联合和自联接, 并带有一个24小时回望窗口。数据仓库还将处理后的数据直接保存到Aurora MySQL和Amazon Redshift中，以支持操作和分析查询。

· Zynga 将Zynga扑克数据库从MySQL迁移到DynamoDB，获得了巨大的性能提升。过去需要30秒的查询现在只需要一秒钟。Zynga还使用ElastiCache(Memcached和Redis)来代替它们自己管理的内存缓存。Aurora的自动化和无服务器可扩展性使 Zynga 成为使用关系数据库的新服务的首选。

· 强生公司使用Amazon RDS，DynamoDB和Amazon Redshift来最大限度地减少花费在收集和配置数据上的时间和精力，并允许快速推导洞察力。AWS数据库服务正在帮助强生改善医生的工作流程，优化供应链并发现新药。

就像他们不再编写单一应用程序一样，开发人员也不再使用单个数据库来处理应用程序中的所有应用场景 - 他们正在使用多个数据库。

尽管关系数据库保持活跃，并且仍然适用于许多应用场景，但针对键值，文档，图形，内存和搜索应用场景的专用数据库可以帮助您优化功能，性能和规模，更重要的是，您的客户体验会更好。

来源：IT168