从单一数据库服务器到根本没有数据库服务器。无服务器计算模式能否改变关系数据库技术的格局？
无服务器计算在过去两年中开始获得推动，这一概念全部关注于将应用程序转移到不需要管理的基础架构，并且仅在运行时间内消耗资源。在公有云中，无服务器通常转换为提供者根据工作负载需求动态管理服务器资源分配的解决方案。 AWS Lambda领先，微软Azure功能（及其他）迅速迎头赶上。无服务器计算框架的定价通常基于应用程序消耗的实际资源量，而不是预先购买的容量。随着无状态应用程序的这些无服务器计算解决方案在下一代软件体系结构中得到普及和采用，那么这些解决方案会离开关系数据库？对于很多（如果不是大多数）应用程序来说仍然是一个关键组件。
在过去的几年中，当涉及到部署关系数据库时，你已经拥有了几个可靠且经过验证的模型：从庞大的微服务到微服务，再到平台即服务解决方案。你可以部署单个“大型”服务器，运行可为数十种应用程序供电的单片或统一数据库。还可以选择依靠面向微服务的架构和一套独立的小型模块化服务，每个服务都可以实现独特的流程并实现特定的业务目标。云解决方案的采用还为你提供了通过基础架构即代码部署数据库的能力，甚至可以利用平台即服务解决方案，从而大大降低了我们数据库的运营开销和复杂性。
但是，所有这些模型仍然依赖数据库服务器的供应。无论是在本地，在云中还是使用PaaS.你可以根据预测的工作负载特征来调配数据库容量，这些特征决定了服务器的大小和配置。当然，可以扩展，缩小或扩展数据库以响应工作负载（取决于所使用的数据库技术），但此过程并不意味着经常进行。
相反，应该根据周期性事件进行扩展，例如即将到来的假日季节，这将为你的电子商务应用程序生成额外的交易，或者为你的公司的SaaS产品添加一个新的大客户作为回应。拥有专用数据库服务器对于工作负载多少有点可预测且相对稳定是最有意义的。可能会出现高峰和低谷，但它们通常遵循可预测的模式。你可能需要在一年中多次调整数据库的大小，但整天不会多次。不常用的数据库缩放是最适合传统应用的模型。
下一代应用程序引入了下一代挑战。其中一些工作负载可能是零星的，间歇性的，而且难以预料。例如，数据库查询或事务的突发可能每天（甚至每个月）只能持续几分钟或几小时。使用与之前相同的电子商务应用程序示例，为了防备，你的数据库如何提供对闪存销售事件的支持，而不必事先过度配置数据库服务器？对于其他工作负载也存在类似的挑战，从在线游戏，股票交易甚至分析（如果每天只有几个小时的分析套件产生大量数据库负载，该怎么办）？大多数数据库管理员将声明，您应该根据预测的高峰工作负载调整数据库的大小。如果可能的话，扩展数据库的过程是一件苦差事，这是传统的智慧和正确的范例。
无服务器计算数据库意味着什么？
为了利用数据库空间的无服务器计算模式，首先需要分离数据体系结构的存储层和处理层。解耦存储和计算并不完全是一个新概念。这个想法已经在一定程度上在NoSQL和大数据分析空间（Amazon EMR，微软的Azure DLS和DLA等）以及各种关系数据库技术（Oracle RAC，NuoDB）中实现。
然而，纯粹的存储和计算解耦并不完全是你称之为无服务器的。为了完全无服务器计算，计算不应该存在于不处理数据的时段，同时也提供按需自动缩放。
实质上，部署一个数据架构，数据库层将根据应用程序工作负载自动启动，关闭和扩展/缩减，同时还抽象出服务器，实例或群集的概念。您只需要定义数据库端点并连接您的应用程序；底层数据库技术将根据应用程序需求扩展存储和计算资源。
除了性能和灵活性方面的优势外，无服务器计算数据库模型还可提供高水平的成本效益。例如，每秒支付使用的数据库容量，并且仅在数据库处于活动状态时才支付，而不是事先选择数据库实例的大小。
无服务器计算数据库技术的当前状态
有大量可扩展的关系数据库技术提供读取或读/写扩展（Oracle RAC，Amazon Aurora，Percona XtraDB，ClustrixDB，NuoDB等）。但是，这些不是本地无服务器计算产品。还有针对无服务器计算数据库的创新解决方案，其中包括诸如FaunaDB（无服务器和全局复制的NoSQL数据库），Google Cloud Spanner（全球分布式和强一致的关系数据库）或MicrosoftCosmos DB（模式不可知的多模式数据库）模型）。但是想要使用这些数据库技术的传统应用程序将不得不大量重写或进行大量重新平台化。例如，尽管Google Spanner是一个具有完整ACID功能的关系数据库（并且拥有独特的数据库技术），但它依赖于定制客户端库来实现连接，并提供了一种SQL变体，其中事务由自定义API处理。