本文来自All Things Distributed，本文作者Werner Vogels是Amazon现任CTO。本文英文原文链接可以在底部看到。
为什么市面上会有这么多数据库产品？我觉得答案很简单：开发者们希望他们的应用程序采用优秀的架构同时具有良好的扩展性。为此，他们需要希望在同一个应用程序中使用多种数据库和数据模型。
单一数据库很难能完全满足多种不同用例的需求。一个数据库包打天下的时代已经过去了，现在，开发者们越来越多地使用大量专业数据库构建高度分布式应用程序。他们使用各个击破的策略，将复杂的应用程序分解成更小的部分，然后选择最佳工具来满足每个部分的需求，而采用的最佳工具通常根据实际情况(use case)选择。
几十年来，关系型数据库几乎是数据库唯一的选择，因此无论应用程序中数据的形态或功能如何，数据模型都被局限在关系型架构中。一直以来，业界并没有因为不同的实际使用情况而对数据库的产生不同的需求，恰恰相反，是数据库决定了实际使用情况。
正如我前面谈到的，我们开发Amazon DynamoDB的原因之一是Amazon当时正在尝试突破当时领先的商业数据库的极限。随着Amazon.com业务需求不断增长，现有的数据库无法支撑Amazon对可用性、可扩展性和性能的需求。我们发现大约70％的操作是key-value查找，他们只使用了一个主键并且返回了一行数据。由于不需要引用完整性和事务，我们意识到这些访问方式可以通过不同类型的数据库更好地提供服务。此外，随着Amazon.com规模的扩大，无限的横向扩展需要成为一个关键设计点。最后，DynamoDB诞生了，这是一种非关系型数据库，它可以在扩展性上突破传统关系型数据库的限制。
当然，这并不意味着关系型数据库在当前的开发中不再适用或者说或不能提供可扩展性和高性能。事实上，AWS的用户已经证明了这一点，因为Amazon Aurora仍然是AWS历史上成长最快的服务。我们在Amazon.com上遇到的问题是由于我们使用的数据库超过了其自身的设计预期。本文的核心是为实现一个特定目标而选择合适的数据库，将实际使用场景与数据库相匹配将有助于你更快地编写高性能，可扩展且功能更强的应用程序。
专用数据库(Purpose-built databases)
世界仍在变化，非关系型数据库的类别也一直在增长。我们看到越来越多的客户希望开发采用不同数据模型的互联网级别可扩展(Internet-scale)应用程序。为了满足这些需求，开发人员现在可以选择关系型数据库，key-value数据库，文档数据库，图形数据库，内存数据库和搜索数据库。这些数据库中都可以解决某些特定问题。
让我们看看每类数据库的用途：
关系型数据库：关系型数据库是自描述的(self-describing)，因为它使开发人员能够定义数据库的模式以及数据库中行和表之间的关系和约束。开发人员依赖关系型数据库（而不是应用程序代码）的功能来强制执行模式并保留数据库中数据的引用完整性。关系型数据库的典型用例包括Web和移动应用程序、企业应用程序和在线游戏。Airbnb是客户使用Amazon Aurora构建高性能和可扩展应用程序的一个很好的例子。Aurora为Airbnb提供了完全托管、可扩展且功能齐全的服务来承载MySQL的运行。
key-value数据库：key-value数据库具有高度可分区性，允许在远超其他类型的数据库的级别进行水平扩展。游戏、广告技术和物联网等用例特别适合于key-value数据模型，在这种模型中，访问模式需要对已知的键值进行低延迟的Gets/Puts。DynamoDB的目的是为任何规模的负载提供稳定的毫秒级延迟。这种稳定的性能表现使是Snapchat Stories功能（包括Snapchat最大的存储写入工作负载）迁移到DynamoDB的重要原因。
文档数据库：文档数据库对于开发人员来说非常直观，因为应用程序层中的数据通常表示为JSON文档。开发人员可以使用他们在应用程序代码中使用的相同文档模型格式来储存数据。Tinder就是使用DynamoDB的灵活模式模型来提高开发人员效率的一个示例。
图形数据库：图形数据库的目的是使开发和运行具有高度连接数据集的应用程序变得容易。图形数据库的典型用例包括社交网络、推荐引擎、诈骗检测和知识图谱。Amazon Neptune是一个完全托管的图形数据库服务。Neptune支持Property Graph模型和Resource Description Framework(RDF)，有两个图形API可供选择：TinkerPop和RDF SPARQL。目前的Neptune用户正在构建知识图谱，制作游戏内推荐以及检测欺诈行为。例如，Thomson Reuters 通过使用Neptune帮助他们的客户了解全球复杂的税收政策和法规。
内存数据库：金融服务，电子商务，Web和移动应用程序具有排行榜都有一些用力，如排行榜、会话存储和实时分析等用例，这些用例要求微秒级别的响应时间，并且随时可能出现大量流量峰值。我们构建了Amazon ElastiCache，提供Memcached和Redis，以提供低延迟服务和支持高吞吐量的负载，例如麦当劳，而基于磁盘的数据存储无法满足这些工作负载。Amazon DynamoDB Accelerator（DAX）是专用数据存储的另一个示例。DAX的出现是为了使DynamoDB读取速度更上一层楼。
搜索数据库：许多应用程序会输出日志来帮助开发人员定位并解决问题。Amazon Elasticsearch Service（Amazon ES）旨在通过索引，聚合和搜索半结构化日志和指标，提供近乎实时的可视化和机器生成的数据分析。Amazon ES也是一款功能强大的高性能搜索引擎，可用于全文搜索用例。Expedia正在使用150多个Amazon ES域，30 TB数据和300亿个文档，用于处理各种关键任务用例，包括运营监控和故障排除，分布式应用程序堆栈跟踪和定价优化。
使用专用数据库构建应用程序
开发人员正在开发高度分布式和解耦的应用程序，AWS使开发人员能够使用多个AWS服务构建这些云原生(cloud-native)应用程序。以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执行多流联合以及使用24小时回顾窗口进行自连接。数据仓库还将处理后的数据直接保存到Aurora MySQL和Amazon Redshift中，以支持操作和分析查询。
Zynga将Zynga扑克数据库从MySQL服务器场迁移到DynamoDB后，获得了巨大的性能提升。过去需要30秒的查询现在只需要一秒钟。Zynga还使用ElastiCache(Memcached和Redis代)替他们自己管理内存缓存。Aurora的自动化和无服务器扩展性(serverless scalability)使其成为Zynga使用关系型数据库的新服务的首选。
强生公司使用Amazon RDS，DynamoDB和Amazon Redshift来最大限度地减少收集和配置数据所花费的时间和精力，并允许快速推导出结论。AWS数据库服务正在帮助强生公司优化医生的工作流程，改善供应链并发现新药。
就像这些公司不再编写单体应用(monolithic application)一样，开发人员也不再使用单一数据库来处理应用程序中的所有用例，取而代之的是使用的是多个数据库。虽然关系型数据库仍适用于许多用例，但是用于key-value，文档，图形，内存和搜索用例的专用数据库可以帮助您优化功能，提升性能和扩展性 - 更重要的是 - 您的客户体验。
广告时刻：硅谷科技公司都在用的AWS你还不熟悉吗？点击阅读原文查看BitTiger CS502大数据开发实战精品课！报名即将结束！
英文原文链接：
https://www.allthingsdistributed.com/2018/06/purpose-built-databases-in-aws.html
