在我们定义什么是无服务器数据库之前，也许我们应该谈谈为什么这种总体范式背后似乎正在形成一种势头。 虽然市场动态很复杂，但有两个主要因素在推动我们走向无服务器。
- 首先，很少有开发者真正喜欢管理他们的服务和应用。操作是一种必要的罪恶，但无服务器可以承诺脱离这些任务，或者至少是一种将其抽象到后台的方法。
- 第二，事实证明，云的经济模式对大多数人来说都是困难的。谁不想把他们从公共云供应商那里得到的账单减少到恰好是他们所消耗的？
无服务器计算范式的出现似乎是一个非常自然的进展，甚至是我们在过去几年中看到的自动化和协调的最终状态。而当应用于数据库时，这种范式可以为所有的应用提供巨大的价值--无论是否无服务器。
无服务器数据库是体现无服务器计算范式核心原则的任何数据库。应用程序的确切风味并不重要；无论是无服务器数据库、云数据仓库，甚至是CRM应用的定制后端，任何自称为无服务器的东西都应该在构建时考虑到以下原则。
- 几乎不需要手动管理服务器
- 自动、弹性的应用/服务扩展
- 内置的弹性和固有的容错服务
- 始终可用和即时访问
- 基于消费的评级或计费机制
还有一些额外的、明确的原则，有助于定义无服务器数据库。数据应该是准确和高度完整的，但同样重要的是，数据还必须在任何地方都可以使用，而且延迟非常低。无服务器的本质是多区域性的：永远不会被束缚在一个地区，能够在任何地方提供所有这些价值。这四个附加原则是
- 在包括区域在内的任何故障域中生存
- 地理上的规模
- 事务性保证
- 关系型SQL的优雅性
当所有这些元素结合在一起时，我们就能看到我们的数据库将成为下一代的样子。一个熟悉的数据库，以服务的形式提供，消除了操作，并将成本降低到你的应用程序使用的交易和所需的存储的数量。
关键的无服务器功能
现在我们已经定义了无服务器应用的核心原则，让我们来研究一下这些东西的含义，以及它们在无服务器数据库中是如何具体实现的。
1.几乎不需要手动管理服务器
无服务器是一个相当错误的名称；它实际上是一堆被抽象化和自动化的服务器，因此你不必管理它们。配置、容量规划、扩展、维护、更新等人工任务仍然发生，但都在幕后。使用它们几乎不需要人工干预，只需要非常有限的思考。
无服务器数据库消除了部署、容量规划、升级和管理的操作开销。 它在不停机的情况下完成这一切，使开发人员能够专注于重要的事情--编码业务逻辑。
2.2.自动、弹性扩展
在无服务器范式中，弹性扩展允许你的服务或应用在任何时候为你的工作负载需求消耗必要的适量资源。这种弹性扩展是自动化的，不需要对你的应用进行任何改动，并有助于优化计算成本。
无服务器数据库允许存储和读/写交易量的弹性扩展。它将根据工作负载进行扩展和收缩，而无需开发人员或运营人员的互动。它将为流量的突然激增进行扩展，并在事件发生后进行缩减，以确保你只为你实际需要/使用的计算量付费。
3.内置的弹性和固有的容错性
无服务器应用程序将在任何后端计算实例或其他网络或物理问题的故障中生存。这种弹性使你的服务即使在你升级时也能始终可用。
无服务器数据库将在后端故障中幸存下来，即使发生这些问题也能保证数据的正确性。 它甚至可以让你在数据库的多个实例中实施在线模式变更和滚动软件更新，所有这些都没有问题，同时始终保持可用。它消除了计划内和计划外的停机时间。
4.始终可用和即时访问
任何无服务器计算平台的一个关键挑战是，不仅要确保服务是可用的，而且还要确保在服务处于休眠状态但突然需要时，你能迅速 "唤醒 "它。让不使用的服务进入休眠状态可以节省计算成本，但只要你再次需要它，它就应该立即出现。
你的应用和服务将依赖于你的无服务器数据库，使其始终处于开机状态并始终可用。更重要的是，它应该尽量减少任何 "唤醒 "时间，以便及时为所有客户请求提供服务。
5.基于消费的评级或计费机制
上述几个核心的无服务器功能有助于节约计算。然而，它们只有在其内置的跟踪活动的机制下才会有效果。一个无服务器应用需要能够捕捉到它的消耗量。
对于一个数据库来说，消耗的两个向量是存储和交易量。无服务器数据库应该捕捉这两方面的信息，以便应用所有者只需为他们所消耗的东西付费。大型应用的成本可能高于小型应用，但无论如何，每个应用都可以相应地增加容量和相对支出。它是无服务器的，所以你只需为你使用的资源付费，当你使用它们时。
定义无服务器数据库
接下来的三个要求是无服务器数据库所特有的，因为普遍性和可用性的概念对如何思考数据和交易有非常深刻的影响--特别是在无服务器中，尤其是在全球范围内。如果你同意无服务器概念应该让我们摆脱对服务器的担忧，那么这难道不应该延伸到对我们运行无服务器的地方的担忧？
对于无服务器数据库来说，"哪里 "会带来很大的问题，因为光速会影响我们执行交易的速度，特别是如果我们想保证数据的正确性。我们不能简单地设置异步复制来完成这个任务，因为无服务器系统的流动性太强，太复杂。
6.在任何故障域（包括整个区域）中生存下来
在幕后，一个无服务器平台很可能会在多个区域内可用。当你不需要持久化任何东西时，这就相对简单。 但是，如果你希望对数据的正确性和可用性有任何形式的保证，这对应用程序来说是一个巨大的挑战。为了让无服务器数据库在任何故障域（实例、机架、AZ、区域、云提供商等）的崩溃中存活下来，它应该坚持多个数据副本，然后智能地控制数据的驻留位置以避免这些故障。数据的放置应该能够被控制，但默认情况下是自动化的，以最大化可用性。
7.地理上的规模
在数据库的范围内，规模通常被认为是所需的总存储量，但这也延伸到了必要的交易规模。对于无服务器数据库来说，规模也可以扩展到地理上，因为各地都需要数据。
数据库应该自动进行地理分区，在全球范围内动态地移动数据，以最大限度地减少数据访问延迟问题。而且，在更成熟的无服务器数据库中，它将能够自动放置跨区域的数据，以帮助解决区域数据归属要求（如GDPR）。
8.交易保证
如果我们想在无服务器数据库内进行交易，我们需要对其跨板块地域的性能给予很大的关注。毕竟，如果你有一个在亚洲的用户和另一个在欧洲的用户在打你的服务，而他们都试图访问同一个记录，谁会赢呢？交易保证和数据完整性在单一地区不那么复杂，但当我们谈到无服务器的最终定义时，我们并不是在谈论单一地区。无服务器是没有界限的。
9.关系型数据库（SQL）的美丽与优雅
最后，在迄今为止的所有这些要求中，我们一直在谈论数据库。 有许多类型，但最复杂的是提供参考完整性、jopines、二级索引等的关系数据库。
提供这种优雅的SQL可能不是每个无服务器数据库的要求，但它应该被视为一种辅助和类型，因为它对我们大多数的操作工作负载都很重要。
所有分布式事物
看似很久以前，我们写了一篇文章，帮助定义了分布式SQL的概念。无服务器只是这些相同原则的延伸，其交付方式完全消除了操作，使采用变得容易，并使成本最小化。 一个建立在另一个之上。
我们提出这个问题，是因为上面的要求为无服务器数据库应该意味着什么制定了计划和准则，最终它是基于分布式系统的相同原则。 没有一个，你就无法拥有另一个。
在软件供应商中，也有一种向这种新方法转变的趋势，许多人正在将其系统架构为无服务器。这种模式已经被一些领先的公司所确立。
如果你能把存储从计算中剥离出来，你就能创造一个无服务器环境。在一个计算和存储分离的架构中，你的计算或服务可以独立于事物的存储方式进行扩展。它们可以循环使用，也可以在 "热 "状态下等待驻留。我们相信这种无服务器的基线架构是正确的，因为它提供了固有的可扩展性和基于消费的能力，这在一定程度上定义了无服务器原则。
未来是熟悉的
最终，我们觉得无服务器数据库的概念最终会成为一个实施细节，而开发者一旦熟悉并适应这种方法，就不会在意。我们相信，数据库最终会成为云中的SQL API，其终端遍布整个地球，是一种不需要开发者关心的服务。相反，他们可以简单地对它进行编码。这应该像用Okta在应用程序中建立认证一样简单。它应该像用Twilio API向你的应用程序添加消息一样。
开发人员知道他们想要什么，不想要什么。 我们非常确定他们不想要运营。世界正在变得无服务器......包括数据库。
