从单一数据库服务器到完全没有数据库服务器，无服务器计算也能改变关系数据库技术的布局吗？
作为在过去两年时间中才开始获得欢迎的一个概念，无服务器计算的关键在于，将关注焦点转移到对基础设施管理和消费资源没有要求的应用程序上，而这些资源在处于激活状态时都是按秒计费的。在公有云空间，无服务器通常都可以看作是这样一些解决方案：供应商基于工作负载的要求对服务器资源的配置进行动态管理。AWS Lambda是这方面的领导者，微软的Azure Functions（以及其他）紧随其后。无服务框架的价格通常基于应用程序所消耗的实际资源总量，而不是预先购买的容量。随着这些针对无状态应用程序的无服务器在下一代软件架构中广为普及和应用，它对关系数据库又会产生何种影响？即使对于大多数应用程序来说，它并不是一个关键的组成部分，但是对于许多应用程序来说，它仍至关重要。
过去几年时间以来，提到部署关系数据库时，从通过微服务的整体式到平台即服务解决方案，你都有一些强劲的、行之有效的模型可供选择。你可以部署一个“大的”服务器，运行一个单一的或整合的数据库来为应用程序提供动力。你也可以选择一个以微服务为导向的基础架构，连同一系列独立的、小的和模块化的服务，而每个服务都能启用一个独特的流程并服务于一个特定的业务目标。云解决方案的采用也能帮助你通过基础设施即一个代码来部署你的数据库，并且甚至能利用平台及服务解决方案，从而从本质上最大程度降低运营费用和数据库的复杂性。
然而，所有这些模型仍旧需要依赖数据库服务器的提供。或者是本地的，云端的，或者使用PaaS。你能够基于预测的、决定你的服务器的大小和配置的工作负载特征来提供数据库容量。确实，根据工作负载的不同，你能够扩展，缩减或向外扩展你的数据库（取决于使用的数据库技术），但这一过程并不意味着能够经常进行。
你也应该基于定期事件进行扩展，如一个即将到来的、将为你的电子商务应用程序生成额外事务的节假日，或者在一个新的客户购买了你公司的SaaS产品时进行相应的扩展。工作负载或多或少是可以预测的，并且是相对稳定的，这样，预测专用的数据库便说得通了。工作负载总量可能会有高峰和低谷，但是它们通常都遵循着一个可预测的模式。你可能需要全年对你的数据库进行几次扩展，但是并不会在一天之内扩展多次。很少扩展数据库这样一种模型只适合传统的应用程序。
然而，下一代的应用程序必然会带来属于下一代的挑战。一些这些工作负载可能是零星的、间断的和高度不可预测的。比如，数据库查询或交易可能突然增多，但它们每天（或者甚至每月）仅持续几分钟或几小时。如果仍使用与之前相同的电子商务app，在不采取预先措施，提前超额配置数据库服务器以防止意外的情况下，你的数据库如何能够为突然出现的销售事件提供支持？从网游，股票交易到甚至是分析学（如果在几个小时或几天内，你的分析学套件产生了大量的数据库负载，情况会怎么样？），其他工作负载也存在着类似的挑战。大多数数据库管理员都规定你应当根据你事先预测的高峰工作负载估计数据库的大小。如果可能的话，当扩展你的数据库的流程是一件十分繁重的工作时，这就是人们通常会采用的明智而正确的做法。
无服务器数据库意味着什么？
为了在数据库空间中应用服务器计算，你首先需要解耦你的数据库基础架构的存储和处理层。解耦存储和计算并不是一个新的概念，在NoSQL和大数据分析空间中（Amazon EMR，微软的Azure DLS & DLA，等等），这一理念就已经得到了执行；同时，各种关系数据库技术（Oracle RAC，NuoDB）在一定程度上也有应用。
然而完全解耦存储和计算并不完全是你称之为的无服务器。为了完全达到无服务器化，在数据未进行处理时，不应当进行计算，但同时也要能够提供按需自动扩展。
从本质上来说，你会部署一个数据库架构，而在这个架构中，数据库层能够基于应用程序的工作负载自动开始、关闭和扩展，同时也要将服务器、实例或集群的概念进行抽象。你只需要自定义一个数据库终端并连接你的应用程序；根据应用程序需求的不同，底层数据库技术将对存储和计算资源进行扩展。
除性能和灵活性方面的好处，无服务器数据库模型也能提供较大的成本效益。比如，仅在数据库处于激活状态时，才为你使用的数据库容量按秒付费，而不是预先选择数据库实例的大小。
无服务器数据库技术的现状
现在，市场上有大量提供读或读/写扩展的可扩展关系数据库技术（Oracle RAC，Amazon Aurora，Percona XtraDB，ClustrixDB，NuoDB等等）。然而，这些都不是原生的无服务器产品。同时，也有各种无服务器数据库的创新解决方案，比如FaunaDB（无服务器和全球可复制的NoSQL数据库），Google Cloud Spanner（全球分布的和强一致关系数据库），或者微软Cosmos DB（模式不可知的多模型数据库，连同一个灵活一致的数据库）。但是，那些想要使用这些数据库技术的传统的应用程序必须经过大量重写或广泛的平台再造。比如，尽管Google Spanner是一个拥有全数据库事务正确执行（ACID）功能（以及一个自主研发的非常棒的数据库技术）的关系数据库，但是它的连接必须依赖自定义客户库，并且提供SQL的一个变异，而在该SQL中，交易是由一个自定义的API来处理的。
启用真正的无服务器和真正的关系数据库，同时一方面利用完整的服务器抽象/扩展，另一方面完全支持ANSI SQL和ACID，是一个已经相对成熟的新的想法；这在来自公有云空间的供应商（Amazon、Microsoft、Google和Oracle）之中尤其引起了关注。
比如，亚马逊在去年的Re:Invent会议上宣布的一个十分振奋人心的消息便是，它们将在2018年推出一个Aurora MySQL数据库的无服务器版本。亚马逊表示，Aurora无服务器“为高度可变和易受快速变化的影响的工作负载而设计，这一新的配置允许你按秒为你所使用的数据库资源支付费用。”亚马逊提到，Aurora无服务器用户将只在数据库处于激活状态时才为流程付费（也为使用的存储）。亚马逊本质上是在建立等同于一个受事件驱动的计算平台的数据库。当用户提供了一个终端时，后者便会充当一个代理，将查询发送到可快速进行扩展的数据库资源那里。基于亚马逊提供的信息，Aurora无服务器将允许你的连接保持激活状态，即使当进行扩展业务时。扩展也应该是快速的，新的资源几秒内便可使用。
未来会是怎样？
技术上的变化将对研发和应用程序部署模式带来怎样的改变，这是十分值得期待的。支持受API驱动的操作和扩展正变得对下一代数据架构越来越重要，同时无服务器数据库也正在成为一个固有的重要组成部分。
当前RDBMS技术的一个重点是，将无服务器计算的好处与开发人员所了解的灵活的关系数据模型，以及现有应用程序与之兼容的全面ANSI SQL和ACID支持结合起来。现在，情况似乎是，无论哪个数据库供应商最先推出全关系和无服务器库，都将在市场上产生深远影响。因此，现在的情况是，Amazon、Oracle、Microsoft、Google以及其他供应商，正在竞相争夺数据库创新大赛的冠军。
