用于计算数据库延迟的真实框架
几乎所有现代应用程序都需要存储和访问数据，但选择正确的数据库来支持应用程序是一项艰巨的任务，涉及对一组复杂的权衡进行推理。开发人员通常需要考虑以下问题：
数据库将存储数据的地理区域以及由此产生的实际延迟配置文件是否允许他们创建快速响应的应用程序。
数据库的操作模型以及隐含的总拥有成本和可用性特征。
数据库的一致性模型以及是否满足要求，而无需向应用程序推送复杂的事务支持。
数据库的开发者体验以及未来是否会赋能快速高效的创新。
数据库的可扩展性以及随着工作负载随时间变化而快速调高或调低容量的能力。
这些维度都很重要，但延迟与其他维度不同，因为它是最难推理的，而且通常不可能进行设计。随着业务逻辑移动到边缘，低延迟也变得越来越重要，这使得本地和远程 API 调用之间的差异对用户来说更加刺耳和破坏。
简单定义，延迟是数据库接收请求、处理底层事务并返回正确响应所需的总时间。这个定义意味着你只能通过应用程序的视角来确定特定数据库的延迟：它将从哪里发送请求，它需要运行的事务类型等。你无法评估一个数据库是否将满足您的延迟目标，而无需在您的应用程序上下文中考虑它，从而使综合或最佳情况下的基准测试无用。
在这篇文章中，我将分享一个我们在帮助开发人员考虑延迟问题时使用的高级框架。然后我将评估 Fauna 在该框架方面的表现。
延迟始于应用程序
数据库的存在是为了为应用程序提供动力，因此数据库评估必须从考虑应用程序架构开始。在过去的几十年里，大多数应用程序都是使用三层架构构建的，其中网站或移动应用程序（称为表示层，但可以被认为是在客户端上运行的软件）与应用程序服务器（称为应用程序或业务逻辑层）处理来自支持应用程序的数据库（称为数据层）的聚合数据。但是现代应用程序越来越多地转向新的无客户端服务器表示逻辑在客户端运行，业务逻辑封装在通过 API 访问的数据库中的架构（与其他后端服务一起）。这种架构通过消除通过集中式应用服务器的需要并允许数据库将数据推送到更靠近边缘的地方，提供了减少延迟的机会。
无论体系结构如何，对数据库的请求的延迟始于从应用程序到数据库的网络旅行，通过所有中间机器，包括应用程序服务器（如果存在）。我将此称为外部延迟，因为它发生在请求到达数据库之前。
一旦请求到达数据库边缘，即数据库供应商拥有或提供的基础设施处理请求的第一个点，数据库需要解码有线协议、验证用户并解析查询表达式。在此之后，数据库通常会在返回响应之前执行许多查询处理步骤，包括处理与底层事务关联的计算操作、将数据复制到其他区域或副本以及从存储中提取所需的数据。我将在接收请求和返回响应之间调用这个时间，其中数据库正在处理查询内部延迟。请注意，并非每个数据库都执行所有这些步骤。
例如，收到写入请求的内存中缓存节点可能不会同步复制或根本不会复制到其他区域，甚至可能不会写入其本地磁盘。但是，分布式事务数据库需要在响应应用程序之前持久且半同步地复制到多个远程区域，因为它保证了更高级别的可用性和一致性。
最后，数据库返回的响应必须通过中间机制返回到应用程序，这也会导致外部延迟。
为什么区分内部和外部数据库延迟很重要？
首先，尽管大多数基准测试仅测量内部延迟，但实际上数据库延迟比内部延迟要大。如果您正在为全球客户群构建应用程序并使用单区域应用程序服务器和数据库为其提供支持，则即使数据库本身的速度无限快，某些客户也可能会看到每个请求的延迟超过 500 毫秒。
其次，不同的架构会权衡其他重要的数据库选择标准，例如一致性、可用性、可扩展性和差异，以实现不同的延迟。例如，跨区域异步复制数据的最终一致性数据库可能具有较低的内部延迟数，但它让应用程序负责边缘情况的正确性。如果应用程序必须发出额外的请求来仔细检查数据的持久性和正确性，或者如果应用程序未能这样做，客户可能会收到不正确的响应，这可能会产生增加延迟的矛盾效应。
在另一个示例中，简单的键/值存储可以提供非常低的平均延迟。但它无法处理请求中的计算的事实可能会导致更高的整体延迟，因为应用程序需要多次往返来执行具有较少约束 API 的数据库可以在接近于单个事务中执行的相同工作数据。
比较延迟的框架
我建议不要依赖简单的基准测试，而是应用以下框架来帮助您考虑延迟：
想想您的应用程序：它将在哪里运行？它将如何架构？数据将如何从应用程序流向数据库？
通过对外部和内部延迟进行建模，得出您自己的延迟预测。在预测外部延迟时，请查看您的用户所在的位置以及对数据库的请求和响应将采用的路径。查看ping 表以帮助了解各个跃点之间的网络延迟。对于内部延迟，请避免使用过度合成流量的基准测试，除非您确信它代表了您的应用程序流量。相反，尝试查找供应商提供的实际报告的延迟指标。
通过运行您自己的反映您的应用程序流量的测试来验证这些指标。
仔细考虑数据库为实现内部延迟配置文件所做的权衡，并确保一致性模型和其他数据库属性符合您的应用程序的要求。
更具体地说，您可以通过查看用户并应用以下公式来计算预期延迟：
如果您的应用程序流量分布在n 个不同的地理区域，xi是给定区域的平均预期外部延迟，ti是给定区域的平均预期内部延迟，wi是访问您的应用程序的活跃用户的权重或百分比在那个地区。
应用延迟框架
让我们将我们的延迟框架应用于Fauna——一个无服务器、地理分布、高度一致、作为 API 使用的事务数据库。在幕后，Fauna 使用Calvin来批量处理事务并将它们应用于跨区域。这意味着写入可能比单节点数据库花费更长的时间，因为它们必须应用于区域组内的大多数区域，但一致读取比单节点数据库更快，因为它们可以在最近的区域之外提供服务。
为了评估 Fauna 的延迟，让我们考虑一个假设示例，我们正在为美国各地的客户构建一个应用程序，其中 50% 的用户位于西雅图，50% 的用户位于迈阿密；一对具有代表性的西海岸和东海岸城市。我们的应用程序将使用客户端-无服务器架构部署到移动设备上，其中应用程序逻辑在客户端上运行，客户端直接调用数据库。假设我们正在考虑使用 Fauna 的美国区域组中的数据库，并且延迟是我们对数据库的主要评估标准。
Fauna 的美国地区组目前在三个地区复制数据。这意味着在请求到达俄勒冈州或弗吉尼亚州的数据库边缘之前，两岸的客户将看到平均外部延迟小于 20 毫秒。
Fauna 允许对您的数据进行任意计算，因此内部延迟是高度可变的，具体取决于支持请求的事务的性质。但是，简单的读取和写入很容易推理。对于读取，Fauna 只是从本地区域返回请求的值。对于写入，Fauna 通过将其写入全局事务日志来同步为事务分配订单，这需要往返拓扑中下一个最近的区域，以便大多数区域已经识别出写入。
Fauna 会在状态页面上发布客户在实践中看到的平均内部延迟。在撰写本文时，在美国区域组中，读取的服务时间为 11 毫秒，写入的时间为 66 毫秒。
Fauna 的外部延迟取决于数据库调用的来源以及到入口点到数据库边缘的距离。在实践中，从迈阿密和弗吉尼亚州的入口发出请求的客户应该看到大约 24 毫秒的外部延迟才能到达边缘，而从西雅图和波特兰的入口发出请求的客户应该看到大约 5 毫秒的延迟。对于写入请求，从迈阿密和弗吉尼亚州的入口发出请求的用户应该会看到大约 13 毫秒的额外内部延迟，因为交易被发送到俄亥俄州并应用于该地区，而西雅图的用户在波特兰发出请求和入口应该会看到大约 13 毫秒的额外内部延迟看到大约 62 毫秒。
我们可以将这些值代入上面提供的公式中，得出以下平均预期延迟：
来自迈阿密和西雅图的 Fauna 的简单读取平均需要 ((24+ 11) .5) + ((5+ 11) .5)= 26ms。
从迈阿密和西雅图向 Fauna 的简单写入平均需要 ((24+ (13+ 11)) .5) + ((5 + (62+ 11)) .5)= 63ms。
让我们考虑一下这些指标如何与我们将在弗吉尼亚州运行的称为 FloraDB 的假设数据库相比较。FloraDB 是传统的单区域数据库。假设它在单个物理节点上运行，并在读取和写入时提供 5 毫秒的平均内部延迟，这对于 RDBMS 来说是典型的。
由于 FloraDB 是单个区域，因此对数据库的请求的外部延迟变化很大，并且取决于客户的位置。从迈阿密发出读取或写入的客户将看到大约 24 毫秒的网络延迟到达弗吉尼亚，但从西雅图发出读取或写入的客户将看到每个请求的网络延迟约为 70 毫秒。
同样，我们可以应用上面的公式来生成预计的平均延迟：
来自迈阿密和西雅图的 FloraDB 的简单读取平均需要 ((24+ 5) .5) + (( 70+ 5) .5)= 52ms。
从迈阿密和西雅图向 FloraDB 的简单写入平均需要 (((24+ 5)+ 10) .5) + (( 70+ 5) .5)= 52ms。
请注意，从西雅图读取到 FloraDB 的时间大约是读取到 Fauna 的时间的 5 倍，因为请求必须穿越全国。由弗吉尼亚节点驱动的综合写入基准测试不会给出使用任一数据库的用户体验的准确印象；它会降低使用 FloraDB 时外部延迟的负面影响，以及默认情况下 Fauna 跨区域组中的区域应用事务的积极影响，尽管该基准在技术上会使 FloraDB 的写入速度提高 10 倍。
概括
延迟是开发人员需要考虑的一个重要但复杂的主题。在分布式世界中，没有单一的指标可以准确地表示所有用例的特定数据库的延迟。
我建议首先考虑您正在构建的应用程序，根据已发布的指标和用户的位置对您的应用程序可能遇到的内部和外部延迟进行预测，然后通过您自己的测试验证这些预测。
对于大多数现实世界的应用程序，使用使数据在边缘用户附近可用的数据库是一个有吸引力的提议，从而降低平均延迟和延迟差异。
