Performance Predictionfor Concurrent Database Workloads （除相关工作外翻译）

ABSTRACT

当前数据管理系统(如云和多租户数据库)的趋势是并发执行异构查询工作负载的数据处理环境。同时，这些系统需要满足不同的性能要求。在这些新兴的环境中，避免潜在的服务质量(QoS)违规严重依赖于性能可预测性，即在不断发展的工作负载中，评估并发查询执行对单个查询性能的影响的能力。

本文提出了一种评估分析工作负载中并发性对查询性能影响的建模方法。 我们的解决方案依赖于对隔离查询行为的分析、成对查询交互和采样技术来预测各种查询混合和并发级别下的资源争用。 我们引入了一个简单而强大的度量，它可以准确地捕捉单个值中磁盘和内存争用对查询性能的联合影响。 我们还讨论了通过查询交互时间轴来预测时变查询工作负载的执行行为，即对在此期间将并发执行离散混合的时间段的细粒度估计。 我们在PostgreSQL/TPC-H上的实验评估表明，我们的模型可以在平均情况下提供实际值的20%以内的查询延迟预测。

INTRODUCTION

并发查询执行有助于提高资源利用率和聚合吞吐量，同时使准确预测单个查询的性能成为一项挑战。 当多个查询共享计算资源和数据时，对复杂交互的性能影响建模是困难的，尽管这对于许多任务是至关重要的，例如新兴的基于云的数据库平台中的服务质量(QoS)管理，对时间敏感的处理任务的有效资源分配，以及交互式数据库系统的用户体验管理。

考虑使用基于云的数据库即服务平台进行数据分析。服务提供者将与其用户协商服务水平协议(SLAs)。这样的SLAs通常用QoS(例如，延迟、吞吐量)要求来表示各种查询类，以及违反QoS目标时所应用的惩罚。服务提供商必须为用户查询分配足够的资源，以避免此类违规行为，否则将面临收入损失和声誉受损的后果。 因此，能够准确地预测传入查询在可用机器上的运行时，以及它对现有查询的影响是很重要的，以便查询的调度不会导致任何QoS违反。如果服务提供商认为现有资源不足以容纳传入的查询，那么它可能不得不扩大规模并分配更多的云资源。

本文讨论了非解析并发查询工作负载的性能预测问题。具体来说，我们研究了以下问题:“给定查询q1, q2, q3，…， qn，在执行的任意阶段并发地在同一台机器上执行，预测每个查询何时完成执行。

要预测QoS，我们以时间延迟，而不是吞吐量或资源利用率等指标为预测目标。 我们之所以选择执行延迟，是因为在实践中，它对用户体验的影响最大。 用户通常更关心查询何时返回其输出，而不是有多少人共享一个主机或需要多少物理I/O。

我们提出了一个两阶段的解决方案。

• 模型建立：我们构建了一个复合的、多元的回归模型，该模型可以捕捉并发条件下查询的执行行为。我们用这个模型来预测在给定的工作负载混合中，每个查询的逻辑I/O延迟。

• 时间轴分析：我们分析工作负载的执行时间轴，以预测单个查询的终止点。这个时间轴分析首先预测第一个查询将完成，然后对其余查询重复执行预测。

我们的关键想法之一是使用一个叫做BAL的基于I/O的逻辑指标，用于量化并发执行查询对性能的影响。这个简单但高度可预测的指标给我们提供了一个总体水平的成本，而不必单独建模更复杂的底层物理系统。

此外，我们扩展了我们的建模框架，通过计算离散混合发生时的执行延迟增量预测来支持时间变化的工作负载。 当将一个传入查询添加到一个混合中时，我们会预测它将如何影响当前正在运行的查询，并估计新添加的查询的执行延迟。 我们对该系统进行了扩展，通过对查询队列进行建模，从而允许进行长期的资源规划。

本文的创新贡献如下:

• 我们认为并通过实验证明，BAL是一个简单且能捕捉逻辑I/O的延迟的指标，即使在并发的情况下，也是查询性能的一个健壮指标。BAL简化了物理I/O延迟和内存争用单个值的联合影响的建模，该值在查询的执行过程中被规范化。

• 我们开发了一个多元回归模型，该模型预测了更高程度并发查询交互的影响主要来自孤立(度-1)和成对(度- 2)的并行执行样本。

• 我们展示了从PostgreSQL/TPC-H研究中获得的实验结果，支持我们的主张，并验证了我们的预测模型的有效性。我们的预测平均接近实际值的20%，而时间线分析带来了额外的改进，通过周期性预测重评估将我们的平均误差降低到平均9%。

本文的其余部分组织如下。 第2节通过检查逻辑I/O延迟的变化来研究查询交互的模型构建。 之后，我们将在第3节中考虑如何预测日志I/O延迟指标。 接下来，我们将在第4节中研究这些模型的训练技术。 紧跟在第5节之后，我们利用这些模型通过模拟查询的生命周期来生成端到端延迟估计。 第6节提供了这项工作的实验评价。 在第7节中，我们检查了相关的工作， 最后我们在第8节中总结。

QUERY LATENCY INDICATORS

我们的框架的目标是预测并发运行查询的响应延迟。

底层硬件的资源争用直接影响查询延迟。随着当前正在执行的查询数量的增加，它们的查询延迟也会增加——因为它们共享对磁盘、CPU时间和内存的访问。 因此，我们的第一步是在指示器中确定有效的查询延迟，即，可以捕获底层硬件中的资源争用的指标，并可以用于预测并发查询的延迟。在本节中，我们将讨论我们研究过的各种查询延迟指示器。我们还将更详细地探讨我们最有效的指标——缓冲区访问延迟(BAL)指标。

我们继续简要描述我们的工作负载。

2.1 Analytical Workload

在这项工作中，我们的目标是分析工作量。我们假设所有查询都来自一组已知的查询类(例如，TPC-H模板)，它们主要是I/O绑定的。我们使用中等分量的查询。对于这项工作，我们将中等权重的查询定义为TPC-H中的10个类，它们的延迟为所有查询类造成延迟的中位数。

工作负载中的查询类对系统的不同部分造成了压力，并发性对它们的延迟的影响有不同程度的波动。在表1中，我们研究了10个中等权重的TPC-H查询类的方差。这些表显示了在不同的多编程级别(即并发执行的查询数量)执行查询时，查询延迟的变化(及其平均延迟)。我们注意到，x的多编程级别意味着x个查询可以并发运行。对多数查询来说，它们的平均延迟随着并发程度的增加而增加。此外，延迟的方差也增加了。

此外，延迟的方差也增加了。一些查询类，如7和18，在并发性下的延迟表现出更多的不确定性。这些查询非常依赖I/O，需要复杂的级联连接和聚合数据访问模式。这使它们对正在运行的查询更加敏感，因为这将根据工作集中进行的共享量使它们加速或减速。相比之下，查询类6有一个简单的执行计划(由表扫描和轻聚合组成)。在这项工作中，我们基于每个查询的模板和它们所属的查询组合，对每个查询进行预测。

我们假设从磁盘读取块、缓冲池命中以及两者的多元模型与延迟密切相关。尝试使用线性回归模型来基于这些指标预测不同的多编程级别的查询延迟。我们的结果如表2所示。我们的实验设置在第6.1节中有详细说明。下表显示了每个指标的预测误差。通常，我们发现由于块与磁盘之间的延迟的内在差异，这些指标都被良好的性能破坏了。在接下来的段落中，我们将讨论每个指标的局限性。

2.2 I/O-Based Indicators

我们的框架解决了分析查询的并发查询性能预测。这些工作负载主要包括只读操作，通常涉及大量的I/O操作。

我们的第一个目标是确定一个与OLAP查询的查询延迟密切相关的指标，并能够捕捉并发性对查询性能的影响。由于I/O操作是查询延迟的主要因素，我们的目标是确定查询延迟指示器，它可以量化I/O操作的成本是如何由于并发运行查询而变化的。

我们可以把I/O操作看作一系列访问方法。在获取页面进行查询时，首先将请求发送到缓冲池，这是访问数据的最快方式。如果没有找到所请求的页面，查找将传递到操作系统级缓存，这是第二快的选项。最后，如果失败，请求将进入队列进行磁盘访问，以检索包含所请求数据的块。这种磁盘访问可能是寻道或顺序读，导致访问一个数据块的成本差异很大。鉴于这种访问方法的顺序，并发性会影响一个查询所需的I/O操作的数量，因为多个查询需要共享缓冲池、操作系统级缓存和物理磁盘。

块I / O读取。 我们考虑的第一个指标是计算查询读取的物理块的数量。 如果查询的执行速度与它完成I/O的速度高度相关(因为从内存中读取对延迟的影响很小)，那么读取的块数量可以告诉我们，随着时间的推移，查询完成了多少进度，需要多少时间来完成。

表2显示，在大多数情况下，基于读块的延迟预测的误差小于29%。这意味着在查询的执行时间中读取的块数量与查询的延迟之间存在相关性。但是，对于某些查询类，如3和5，这种预测较弱。预测的相关性较弱，因为这些查询在cpu上花费了相当多的时间，在此期间它们放弃了对I / O带宽。这些cpu密集型查询计划使得查询对它们的工作集之间的重叠程度以及它们同时执行的查询之间的重叠程度更加敏感。这是因为查询经常使较短的数据访问被较长时间的CPU使用打断。因此，如果磁盘臂大致保持在执行它们的相同区域，那么I/O的成本将保持相对统一。但如果数据访问模式更随机，这种不确定性将反映在I/O操作的成本上。

缓冲池命中率。我们还研究了缓冲池命中次数是否可以用作查询延迟指示器。我们的假设是，磁盘访问的延迟开销可能是相对固定的，我们可以从这个基本开销中减去每次缓冲池命中所节省的I/O操作，从而估计查询延迟。我们发现这个指标与延迟相关，但预测错误类似于I/O块读取指示器。我们发现这个指标与延迟相关，但预测错误类似于I/O块读取指示器。造成这种情况的因素有很多，包括整个系统有多层内存存储层(例如，缓冲池，操作系统缓存)，因此很难推断内存节省了多少。此外，这些节省并不能充分地捕捉I/O操作的变化行为，即物理块的读写。查找和顺序读取的混合并不是固定的，这使得获得持续良好的预测变得更加困难。

I/O块读取和缓冲池命中。最后，我们对这两个指标进行多元回归实验。在本例中，我们的假设是，这两个指标将相互补充，因为缓冲池命中会取代磁盘读取(即，缓冲池命中允许我们跳过磁盘访问)。表2显示，该模型并没有显著提高我们的预测误差。

表2中的结果表明，物理I/O块读和缓冲池命中的数量与查询延迟适度相关。 这主要是因为从磁盘导入单个块所需的时间存在很大的差异。 如果该块是顺序读取的一部分，那么它可能发生得很快。 然而，seek的成本变化很大。 每个块的物理I/O延迟与磁盘臂获取目标块的距离成正比。 因此，在实践中，读取单个数据块的速度可以有一个数量级的变化。 这将导致I/O计数和缓冲池命中在模拟平均I/O延迟时扭曲延迟预测，当数量具有未知(并且经常变化)的分布时。

2.3 Buffer Access Latency (BAL) as an Indicator

我们发现单独处理每个块访问方法的效用有限，因为交互太复杂了。为了简化这个问题，我们将对缓冲池的初始请求标识为一个门道，所有查询都必须通过该门道来接收数据。当查询请求一个数据块时，它将请求提交给缓冲池管理器。当缓冲池收到一个请求时，它会一个接一个地查询它的存储级别，直到它获得所需的磁盘块。从发出请求到返回所需的块之间的平均时间构成了逻辑I/O请求的平均延迟。

因此，我们不是单独建模缓冲池请求的每个步骤，而是使用逻辑I/O操作的平均延迟作为查询延迟指示器。我们称这个指标为缓冲区访问延迟(BAL)。在查询持续时间内平均这个指标，允许我们以规范化的方式捕获磁盘查找、顺序读取、操作系统缓存命中和缓冲池命中的交互。

每个平均BAL通常是超过一百万个逻辑I/O请求的集合，因此这允许我们推断单个查询的I/O类型混合(顺序读取、查找等)的变化。当查询单独运行时，平均BAL较低意味着我们拥有一个轻量级查询，它从内存中读取大部分数据。相比之下，高的BAL读数意味着查询请求的是不驻留在内存中的不同数据，比如真实表扫描或索引扫描，这就需要昂贵的查找。

为了测量BAL指标，我们修改了使用的数据库引擎(PostgreSQL 8.4.3)。具体来说，我们在缓冲池管理器中截取了查询执行器发出页面请求的点。当向缓冲池发出请求时，计时器开始。如果没有找到该页面，则进程将请求提交给存储管理器，存储管理器与磁盘和操作系统进行接口。当必要的页返回给查询执行程序时，计时器停止，而不管其来源是什么。 为了生成BAL指标，我们将每个页面请求所花费的时间相加，然后除以查询计划访问的逻辑页数。 在表2中，我们将BAL的质量与我们研究的其他基于I/ based的指标进行比较，以预测延迟。 大多数情况下，我们的预测误差会下降到3%-6%左右。

BAL是一个很好的延迟指示器的原因之一是——因为它是查询生命周期中许多样本的平均值。 因此，即使一个查询与操作系统以及其他查询进行了非常复杂的交互，它仍然会收敛到对总体延迟的准确预测。

在图1中，我们展示了隔离运行时，BAL的典型值在查询的整个生命周期中是如何变化的。我们所有的BAL测量都是平均1000个缓冲池请求。这个特定的查询(TPC-H模板14)在BAL中预热时(即加载所有数据库二进制文件)会经历一段短时间的低延迟。然后，它会达到一个相对稳定的状态，持续读取块并加入元组。在连接过程中，当查询通过查找和顺序读取循环时，BAL会周期性地波动。当我们考虑工作负载中的所有查询时，平均标准差大约为查询BAL平均值的33%。这种方差可以归因于BAL所捕获的指标的固有噪声(i..e，混合了缓冲池读取、查找和顺序物理I/O)。BAL是一个健壮的指标，因为它在许多逻辑页面请求中捕获这些复杂交互的聚合，聚合到一个稳定的平均行为上。

2.4 Predicting Query Latency using BAL (B2L)

我们使用一个线性回归模型，使用BAL指标来预测端到端查询延迟。直观上看，I/O限制的查询的延迟与它平均等待逻辑I/O的时间以及相对固定的开销成正比CPU时间和固定的数据库支持。 因此，如果查询α的平均BAL是Bα， Oα是其固定的CPU开销， 那么查询α l的延迟由以下公式给出:

我们的系统找到每个查询类的固定开销，这包括模型的y轴截距(Oα)。 Pα系数允许我们对查询计划所需的逻辑页面请求数建模。 因此，如果一个逻辑I/O的平均延迟(例如，BAL指标)在一个混合查询中运行的查询是已知的，我们可以使用上面的模型预测它的延迟。我们称这种端到端延迟预测模型为BAL到latency或B2L。

模型与数据的拟合度。R2是一种归一化的度量，它将模型的误差与数据集的总体方差联系起来。取值范围为0 ~ 1，值越大表示拟合越好。

它通过计算训练集中每个数据点的平方和误差来捕获模型的误差，SSerr，归一化数据的总可变性，SStot，通过从均值取单个数据点的方差平方和来计算。。

上述模型的强大之处可以从训练集中每个查询类的R2值中得到证明。我们在每个模板的平均259个示例上进行训练。R2系数变化范围为0.83-0.99用于TPC-H工作负载中的10个查询;我们所有的查询都非常符合这个模型。

我们发现TPC-H模板很好地符合这个模型。

同一个类中的查询很少更改它们的查询执行计划。我们捕捉这种一致性与我们的内耳模型的斜率。在实践中，我们发现，尽管使用范围谓词和索引操作，查询模板的I/O请求计数的变化并不超过5%。在某些情况下，例如倾斜的数据分布或高度变化的范围谓词，我们需要为每个查询模板创建多个模型。

在这种情况下，我们将模板细分为[1]中描述的谓词范围。 我们实验的更多细节见第6节。 总之，BAL是我们最强的查询性能指标。 在下一节中，我们将讨论如何为并发工作负载预测这个指标。

BUFFER ACCESS LATENCY PREDICTION

正如我们在上一节中所探讨的那样，查询的平均缓冲区访问延迟是一个始终如一的指示器，它反映了不断变化的查询混合和并发级别的延迟情况。在本节中，我们提出了一种技术，通过基于对之间的观察对查询模板的交互进行建模来预测这个指标。在较高的层次上，我们的目标是量化查询在与竞争进程共享资源时性能的变化。为了捕捉这种效果，我们首先描述查询类是如何隔离运行的。然后，我们推断与其他查询类的交互如何影响其性能。

3.1 Modeling Query Interactions

为了预测查询类的并发性能，我们需要量化它在争用情况下的平均BAL指标。在本节中，我们为BAL创建一个预测模型，用于轻度到中度的查询争用。 我们首先检查(a)查询类在最佳条件下的资源利用率(即，独立运行的查询)， 以及(b)并发查询预期消耗的资源。 就我们的目的而言，资源需求主要是指所使用的I/O带宽和内存，它们的联合影响被每个查询的BAL捕获。我们通过检查当它们成对交互时如何影响它们的BAL，来估计这些查询在一个模板一个模板的基础上相互竞争的程度。

例如，当TPC-H查询6与查询14一起运行时，两者的平均加速时间约为10秒。这是因为它们的两个查询执行计划都以事实表上的顺序扫描为主。相反，当Q19与Q7一起运行时，它们分别降低了大约50%和30%。在这种情况下，两个查询在其工作集中共享的重叠较少，并且都需要大量内存来执行开销较大的连接。

为了更好地描述查询的交互方式，我们首先研究了所有成对的交互。对于n个查询的工作负载，我们执行了所有唯一的组合(在10个查询类的情况下，总共有55个成对组合)。这些配对允许我们描述每个查询如何影响工作负载中的其他查询的大小和符号(正负分别表示减速或加速)。我们还研究了在多个、更高程度的交互作用上建立我们的模型的增量效用，这并没有产生任何一致的或显著的改进，而更昂贵。因此，我们得出结论，基于两两相互作用的模型，增强了额外的统计数据，在实用性和准确性之间取得了良好的平衡。

具体来说，通过分析成对如何相互影响，我们在更高的并发度上对BAL建模。为此，我们根据单独查询的各个BAL的基本成本构建一个BAL的组合。然后，我们将由查询之间直接和间接的交互所导致的BAL变化所表明的交互成本纳入其中。我们使用这种两两相互作用率和孤立运行来建立我们的多元回归模型。我们将这种BAL估计模型BALs称为并发BAL或B2cB，我们将在下文详细描述。

在我们预测并发BAL的模型中，我们区分了主查询和补查询。当我们预测一个查询的并发BAL时，我们称它为主查询。与主服务器同时运行的查询是它的补充。我们的模型背后的直觉是，当我们处理非过载状态时，争用成本是线性增加的，是混合查询中每个查询的固定成本以及查询之间每对交互(分为与主查询的直接和间接交互)的可变成本的函数。例如，假设我们采用轮询调度，那么获得一个具有并发性的数据块(即并发BAL)的成本(即延迟)等于在没有并发查询的情况下获得一个数据块的成本，加上每个互补并发查询平均一次页面读取的成本，加上工作负载中所有查询之间的交互成本。

我们的BAL预测模型由训练数据提供了以下四个自变量:

•隔离:此变量表示主查询隔离运行时的BAL。检查孤立的BAL可创建基线以评估并发的BAL。它为我们提供了在最佳情况下主查询的默认页面访问时间。我们将查询i的孤立BAL表示为Ti。

补语:类似地，我们需要考虑组合中补语查询的资源需求。补全变量是补全查询的孤立项之和BALs。将互补品的BAL相加，可以让我们估算出它们在公平调度条件下消耗I/O带宽的速率。这是一个粗略的估计补码查询的“成本”。

•Direct:这个变量是主变量与它的每个补体配对时BAL变化的总和。直接变量从直接查询交互中捕获主服务器BAL中的变化。我们将直接查询交互作用Ti/j量化为与查询j同时运行时测量的查询i的平均BAL。该测量值的变化为ΔTi/j = Ti/j−Ti。如果这个数字是正的，那么我们正在经历经济放缓。如果是负的，那么查询之间就有了有益的交互。

•间接:最后我们检查了补语查询之间的BAL变化。这让我们了解到它们产生了多少争用，以及它们的交互将在多大程度上影响主查询。注意，它们的交互可能不是对称的()。例如，同等连接需要专用的内存来有效地完成比较。如果它与表扫描同时运行，则表扫描不会受到联接的影响，因为它只使用每个元组一次。扫描查询不成比例地影响连接查询的延迟，因为它访问的内存更少。 我们将间接变量定义为每个补体在运行时的BAL变化。

我们发现所有这些自变量对于建立一个完整的模型都是必要的。如表3所示，一旦我们开始考虑具有相互作用的孤立成本，我们的预测模型的质量(由R2系数衡量)就会显著提高。此外，当解决四个变量时，而不是仅仅依靠孤立的BAL时，和平方误差的改善大于50%。

我们预测查询q在其补语c1..cn同时运行时的平均并发BAL为:

我们对训练集中的所有查询使用多元线性回归来求解系数α， β， γ1和γ2，每个多规划层次一次。我们选择在这个粒度上进行回归，以模拟不同程度的争用。回归利用最小平方和误差法得到系数。

预测的端到端延迟。图2的下面部分演示了预测不同并发级别的端到端查询延迟的步骤。给定一个查询和它的互补组合，我们可以使用B2cB模型快速地创建一个平均并发BAL估计。并发B2cB是我们的B2L模型的输入，它提供了最终的延迟估计。

不同BAL预测模型(变量:孤立(I)，补和(C)，直接(D)，间接(G))的R2值。多程序编制第3级训练。

举一个更具体的例子，如果我们预测查询a的BAL且它正在运行查询b和c，我们开始与以下输入:
Ta, Tb, Tc              a,b,c独自运行时的平均BAL
ΔTa/b, ΔTa/c         同时运行查询b或c时，a的BAL

我们使用公式2预测查询a的平均BAL Ba:

然后，我们可以使用公式1预测端到端查询延迟。我们将对这个查询类应用系数Pa(即逻辑页面效率系数)和a的固定开销Oa(即固定开销)。然后我们将通过计算来预测端到端延迟:

TRAINING THE PREDICTION MODELS

为了获得性能估计，我们需要训练我们的预测模型。培训阶段包括单独、成对运行我们的工作负载，以及在几个更高的多编程级别上运行工作负载。这提供了评估我们的B2L和的系数和B2cB预测模型。我们所有的样本都用于训练这两个预测系统。

为了灵活地建模查询交互，我们必须以一种与单个查询开始时间的偏移量无关并能代表查询模板内变化的方式总结它们的影响。我们通过临时修复查询所参与的混合，并随机化每个查询开始的偏移量来对此进行建模。我们称这种测量为稳态。稳态抽样允许我们推断查询将如何对连续级别的争用和一组固定的补语作出反应。图3显示了一个稳态的例子

此外，为了获得只捕获交互的测量结果，我们的实验是基于热缓存的。也就是说，我们省略了前几个样本。这允许我们忽略初始查询设置和小型支持结构缓存的开销。这种方法还允许我们从在执行的不同阶段重叠的查询中采样不断变化的交互。

在接下来的段落中，我们将描述如何获得我们在前面章节中描述的两个预测模型(B2L和B2cB)的训练集。

4.1 Sampling-Based Training Sets

在我们的框架中，我们通过对要创建预测的配置的子集进行抽样来构建预测模型。实验驱动的建模允许我们大致了解工作负载中的查询如何交互。我们的模型对查询进行了隔离、成对和更高程度的并发性训练。图2显示了我们训练运行的使用情况。

首先，我们根据每个查询的独立行为来描述我们的工作负载。这个基线允许我们估计什么构成了查询类正常的、不受阻碍的进度，以及在添加新查询时我们的速度有多快或有多慢。在我们的实验中，我们平均每个查询类使用热缓存隔离运行的许多示例，并记录每个查询类的延迟和BAL指标。BAL-latency pair用于B2L时延预测模型的训练，同时也是B2cB模型前两项的输入。

接下来，我们建立了大于2度的相互作用的模型系数。我们使用拉丁超立方抽样(LHS)在这个层次上进行抽样。LHS将我们的样本选择均匀分布在我们的预测空间中。这是通过创建与我们的多编程级别相同维度的超多维数据集来实现的。然后我们选择样本，使每个平面上的每个值都恰好相交一次。这种技术的每次抽样运行最多产生n个组合，其中n是工作负载中唯一查询的数量。图4显示了拉丁超立方体抽样的一个简单示例。这些示例运行用于在每个多编程级别上为B2cB创建系数。我们对一组拉丁超立方采样数据点进行多元B2cB线性回归。

这个中等数量的样本对于我们的BAL和延迟预测都是必要的。两两相互作用为我们提供了B2cB自变量的输入。它们也为我们的B2L模型提供了输入。B2L构建在许多并发级别之上，以便绘制随着争用增加而增加的延迟。每个多编程级别都帮助我们完成模型。

接下来，我们通过运行所有的成对组合(在我们的例子中是55个)来构建一个相互作用矩阵。 这使我们能够简洁地估计工作负载中的每个查询类对每个潜在补充的争用程度。 与我们的单独测量一样，我们得到了所有这些组合的端到端延迟以及平均BAL测量值。 这些BAL延迟对用于训练B2L模型。 此外，它们还作为B2cB模型的输入来估计BAL。

LHS是一种通用的抽样技术，并不是探索所有可能的查询组合空间的最佳选择。在探索我们的采样空间时，LHS没有考虑组合之间的差异和每个突变之间的差异。例如，对于采样器来说，(3,4)和(4,3)的组合都被认为是不同的样本。从数据库的角度来看，它们都只是同时运行的Q3和Q4的一个实例。我们消除了LHS，即相同的组合在训练集中不止一次出现，因为每次运行都会产生所涉及的所有查询的数据(即，当我们执行mix(3,4)时，我们记录了Q3和Q4的数据)。

在我们的训练阶段，我们对每个并发级别使用这种抽样技术三次。通过实验我们发现，随着采集的样本越多，我们自然就能对系统中的争用成本有一个更全面的了解。另一方面，更多的抽样需要更多的时间。我们发现，在每个多编程级别上运行3个LHS可以很好地权衡这些竞争目标。获取更多的样本并不能提高我们的预测精度。

每一次LHS训练由10个稳定状态组合组成，每个多程序级别抽取30个训练组合。最初这看起来像是很多样本，但与所有可能的组合相比并没有那么多。对于更高的多编程级别来说尤其如此，在这种级别中，每当添加查询时，组合集就会呈指数级增长。当我们的工作量变得更加复杂时，训练空间的复杂性会显著增加。如果我们在一组n个查询上进行训练，我们必须首先隔离地执行它，将它合并到所有对和更高级别的抽样中。对于配对，我们对所有组合进行样本替换，产生(n^2 + n)/2的稳态运行。

如果我们对m个大于2的多编程级别进行抽样，并运行l个LHS样本，那么所需的训练运行次数可以计算为n + (n^2 + n)/2 + lmn。在我们的情况下，这是155个抽样组合。

在实践中，在我们适度的设置下，整个训练周期大约花费了两天时间。这似乎需要相当长的时间，但我们只需要训练一次，然后就可以无限地将结果用于任意混合。同样值得注意的是，这个前期的训练使我们的模型在到达评估阶段(即，当它产生查询延迟估计时)时变得非常轻量级。一旦模型训练好了，创建一个估计的成本可以忽略不计。这只是应用B2cB模型(主要的、补充的、直接的和直接的I/O贡献的总和)和向B2L模型提供输出的成本(l = oα + pα * bα)。

TIMELINE ANALYSIS: PERFORMANCE PREDICTION FOR CHANGING MIXES

使用B2cB和B2L方法，我们可以预测在查询执行期间，如果混合没有改变，则执行单个查询的延迟。这个系统对于简单的情况很有用，我们只需要估计查询在非常均匀的混合中运行多长时间。然而，在大多数情况下，我们正在评估的查询混合是不断变化的，因为用户提交了新的查询，而已经存在的查询以不同的时间间隔终止。例如，在生产系统中，经理和其他决策者在工作时提交查询，并将从结果的估计到达时间中受益。通过建模，我们可以向他们提供实时反馈，即一个新查询将运行多长时间，以及它将在多大程度上影响他们当前执行的工作负载，使用“假设”风格的分析。

这种类型的系统需要对更大范围的情况进行增量评估。我们需要考虑在查询执行期间由于补码查询的数量和/或类型的变化而发生的所有混合。该系统必须量化这些混合造成的减速(或加速)，并估计在每种混合中完成查询工作的百分比

我们提出了两个公式来评估我们的预测。在第一个场景中，提交新的查询以立即执行。我们将其称为即时(JIT)建模。 在JIT中，随着当前正在执行的批处理的成员完成，查询的数量单调地减少。在第二个场景中，我们考虑一种基于队列的方法，其中我们的系统被赋予一个修复了多编程级别和要运行的查询的有序列表。在这种情况下，我们也通过投影来模拟将会发生的混合，当查询在执行期间从队列中开始查询时。接下来，我们将描述这些建模场景。

5.1 Just-in-Time Modeling

即时模型允许我们问这样的问题:“如果我现在计划一个查询，需要多长时间?”它将如何影响当前正在运行的查询的完成时间?”JIT评估更灵活，因为它们支持评估中的多个多编程级别，并对工作负载中的实时更改建模。

此外，这种更增量的方法允许我们随着时间的推移改进我们的估计。当我们预测每次添加查询的延迟时，我们可以通过检查查询自上次预测其端到端延迟以来的进展情况来纠正过去的估计。在SLA的上下文中，这可以让我们通过随着时间的推移进行干预和负载平衡的能力来防止发生违反QoS的情况。通过实验，我们发现使用这种方法估计的QoS平均误差约为10%。

总之，我们从n个查询开始，并为n个分段中的每个查询规划完成时间。每个片段比前一个片段少包含一个查询，因为我们减去了我们预测接下来将终止的查询。在每个大于2的并发级别上，我们使用B2cB和B2L模型来创建QoS估计。对于孤立的和成对的情况，我们使用训练阶段记录的延迟。

5.2 Queue Modeler

这个系统的另一个有用的场景是，如果我们有一个固定的多编程级别，估计查询将花费多长时间。在[14]中，作者讨论了多编程级别如何成为调度并发资源时优化DBMS性能的一个常见“按钮”。

在此之后，我们对稳态估计进行排序，并选择剩余时间最短的查询作为我们的第一部分评估。这定义了我们评估第一次离散混合的时期。我们选择这个查询qmin和它的估计延迟lmin作为下一次混合状态改变的时间。我们从混合中减去qmin，并通过取lmin/lq的比率并将其乘以剩余的逻辑I/O请求来更新每个不等于qmin的查询q的进度。我们还为工作负载中未终止的每个查询添加lmin到估计值。最后，我们从工作负载中减去qmin，因为我们预计它将在这个预测点结束。我们继续迭代地预测并在剩余时间最少的情况下消除查询，直到完成对工作负载中所有查询的估计。

这种JIT建模需要估计每个混合中每个查询的延迟，以及每个混合将占用的执行时间的百分比。JIT算法如图5所示。在我们的基于时间轴的QoS估计器中，首先我们查看当前在一个混合中执行的所有n个查询的进度。我们创建一个列表，列出当前执行的每个查询开始后所经过的时间，并使用这个数量初始化我们的性能估计。我们还记录为每个查询服务的逻辑I/O请求的数量。第二个指标为我们提供了查询工作已经完成的百分比的估计。

接下来，我们必须查看建议的混合中每个查询的估计QoS，在临时假设混合不改变的情况下操作。我们可以使用前一节中的技术在这些稳定状态条件下为工作负载中的每个查询创建端到端延迟估计。第一个估计是BAL使用B2cB预测模型，然后我们使用B2L模型转换为延迟。我们根据服务的逻辑I/O数量，将稳态估计值乘以我们所预测的剩余查询的百分比。

在这个公式中，当我们预测当前的混合将结束时，我们通过在队列中向前看来模拟不断变化的混合。我们将此场景称为队列建模器(Queue Modeler, QM)。

Queue Modeler要求访问提交的查询队列。QM的工作原理与JIT预测非常相似，不同之处在于它检查当前执行的工作负载，并对当前查询终止时在队列中添加下一个查询作为替换进行建模。这个系统允许我们给出一个端到端的进度估计，而不需要开始执行我们预测中包含的一些查询。

队列建模器显示在算法1中。队列建模从当前执行的每个查询的状态信息列表开始，很像JIT。这也是查询执行时间和查询在逻辑I/O请求方面取得的进展的一对。我们将新查询添加到列表(qp)，其进度和当前延迟为零。接下来，我们对混合中每个查询的稳定状态延迟进行建模，并对剩余延迟的估计结果进行排序。预计剩余时间最少的查询qmin将在lmin时间内继续运行。接下来，我们通过计算lmin与预计剩余时间的比率来更新剩余查询的进度。我们通过添加qmin的预计完成时间来更新它们的延迟估计，以模拟查询在这种混合中保留的时间量。最后，我们用队列上的下一个变量替换qmin。我们继续这个循环，直到创建预测的查询为qmin。

EXPERIMENTAL EVALUATION

在本节中，我们将验证框架中四个模块的准确性和实用性。

首先，我们看看B2L的准确性，或者我们的实验驱动模型在不同并发级别和查询混合的情况下，如何很好地使用缓冲区访问延迟来预测端到端查询延迟。 接下来，我们检查我们的B2cB模型在预测与B2L一起使用的BAL方面有多好。 之后，我们将探讨结合这两种技术来生成端到端延迟估计的准确性。 最后，我们尝试使用JIT和队列建模器时间轴分析技术，在固定的多编程级别上对随机的、动态生成的工作负载创建预测。

我们在稳态实验中分两阶段收集数据。

最初，我们创建由几个稳定状态混合组成的训练数据。我们的训练集从多程序层次1-5的样本中提取。利用训练数据集建立了预测模型

并发缓冲区访问延迟(B2cB)和端到端延迟(B2L)的模型。培训过程的详细内容见第4节。B2cB为每个多规划层次的多元预测模型产生系数。B2L为每个查询类生成简单的线性模型。

接下来，我们看了一个测试数据集，它由与训练数据不相交的随机选择的混合组成。我们的测试数据来自两个拉丁超立方样本集，每多程序级，产生20个稳态测量值。每个稳态测量由组合中的每个模板至少5个查询组成。

最后，我们试验了完全任意的混合，重新放松了我们的稳态假设。这让我们能够评估我们的时间轴分析。在这里，我们研究了预测的增量重新评估(JIT)以及在每个查询启动时只创建一个预测(队列建模器)。

6.1 Setup

我们试验了一个TPC-H查询工作负载，它由对数据库系统的不同部分施加压力的中等权重查询组成。我们以OLAP为目标，因为查询的运行时间更长，使我们有更多的时间来描述它们的交互。分析查询往往与I/O关系更密切，这使得我们可以将重点放在交互建模的这个元素上，而不是必须考虑CPU切片和其他资源共享的更复杂的多维模型上。

我们混合使用了10个权重适中的查询。具体地说，我们的工作负载由TPC-H查询3、4、5、6、7、8、10、14、18和19在TPC-H实例上，缩放倍数为10。我们在所有TPC-H模板的中位数执行时间附近选择了10个查询。我们关注中等重量的查询，因为它们运行时间足够长，这样我们可以对它们的行为做出有用的推断。它们也足够轻，让我们能够试验有意义的多编程级别。

此外，我们想要预测现实的工作负载。我们研究了不同多编程级别的并发查询混合，但是我们没有针对非常高的争用情况进行预测。因此，我们不考虑这样的情况:混合使用多个查询可能比并发运行查询更快地完成它们的所有执行。

我们还选择关注中等权重的查询，因为跨多个查询权重建模给问题增加了另一层，如[8]所示。在这项工作中，他们根据相对权重对查询进行分类，并为每个组建立模型。在未来的工作中，我们可能会用类似的标签策略来扩展我们的框架。

在我们的实验配置中，我们添加了由标准TPC-H实现提供的主键索引。该基准被部署在PostgreSQL 8.4.3的修改版本上。 该源代码用于测量BAL。我们所有的试验都是在Intel i7 2.8 GHz处理器和8 GHz处理器的机器上运行的8 GB的RAM。机器运行在Ubuntu 9.04和Linux 2.6.28-11上。

6.2 Predicting Query Contention

在这一节中，我们将看看我们的B2cB和B2L系统如何很好地预测BAL和端到端延迟。下面的所有结果都是在我们的测试数据上评估的，与训练样本不相交。

首先，我们检查了B2L在根据所提供的BAL估计延迟方面的有效性。 我们在多编程级别1-5的训练集中为每个查询类构建线性模型。 我们的训练阶段为工作负载中的每个查询类生成L = Oα+Pα * Bα形式的简单方程。

我们用图6演示了模型的拟合度。这个图上的点都来自我们的测试数据集的单个查询，并发级别为3-5。这些线表示单个B2L模型的斜率。每个查询类都非常适合其回归模型。我们的评估数据产生的平均误差仅为5%。这种紧密匹配是因为查询的延迟通常与它们访问物理页面的速度相适应。这表明，尽管采样的混合比较少，并发级别也不同，但缓冲区访问延迟是查询延迟的一个有效和健壮的时间触发器。重申一下，这里评估的要点都不是培训阶段的一部分。

很明显，我们的B2L模型分为两种主要轨迹。 这些不同的斜率是查询模板具有不同的查询执行计划布局的结果。查询计划可以分为处理管道。这些管道划定查询执行中的点，在这些点上，前一个管道的结果必须在查询的下一阶段开始之前完成。例如，排序需要在其操作中访问所有元组，因此要求执行程序为它们启动一个新的管道(从为排序提供元组的操作符分离)。在未来的工作中，我们可能会考虑将我们的预测分解为管道粒度，就像在[7]中对进度评估器所做的那样.

延迟增长较小的查询(查询6、14和19)只有一个管道(即没有诸如排序或按组聚合之类的实物化点)。其他延迟与BAL成比例增长较快的查询类在其查询计划中通常有一个以上的管道。这意味着每个BAL的总体增长率更高，因为元组必须遍历多个管道，而且通常需要在查询计划中使用更多的操作符来评估，这带来了开销。

既然我们已经确定了平均BAL是不同资源争用情况下延迟的一个很好的预测指标，那么我们就来评估我们能够在多大程度上预测这个指标。我们检查了B2cB方法在测试数据集上预测平均BAL的准确性。

图7显示了B2cB预测与3级多程序ming测量的BAL的拟合。这张图表显示了测试中稳定状态下的所有查询。本实验总共采样了20种稳态混合物。

我们的样本在趋势线周围建立了统一的拟合，这表明该模型可以对BAL做出合理的“大致估计”。 同一类和mix的查询之间存在一些差异。 其中大部分可以归因于缓冲池内容和查询模板每个示例的谓词更改。

导致差异的另一个原因是时间转移(即，相同混合中的查询相对于它们的补语，在不同的时间开始)。 这些偏移在这个图上显示为点的水平线。我们尝试将查询分解为多个部分，并在这种更细粒度的基础上评估我们的预测。在实验中，我们没有发现通过逐段评估这些查询的显著改进。我们还发现，在这个粒度上量化所有对的抽样会使我们的训练时间显著增长。

此外，我们的模型在低到中等水平的争论中效果最好。随着争用的增加(由更高的观察值表示BAL)，我们的估计精度降低了。这是因为当我们接近超负荷的状态时，我们的增长模式逐渐从线性转变为指数型。建模过载和BAL分配的转移留给未来的工作。

总之，我们的B2cB估计的平均误差为24-35%。随着我们的多程序设计水平的提高，我们的估计变得不那么准确了，因为我们接近超负荷的状态。

6.3 Steady State Predictions

接下来，我们将通过组合我们的BAL估计和B2L来检验我们在稳态条件下预测端到端延迟的能力。对于每个稳定状态运行的查询，我们首先使用B2cB预测BAL。然后，我们使用图6所示的B2L模型将预测的BAL转换为延迟。我们保持mix常量，以允许我们对离散的混合进行建模，尽管底层查询具有不同的执行延迟。我们稍后将量化不断变化的查询组合所带来的附加挑战。

在图8中，我们评估模型在测试数据上的准确性。我们将我们的发现划分为查询类，并对整体进行平均。我们对该系统进行了3-5级多程序设计测试。该图显示了我们的相对误差，计算为

作为参考，我们在每个组合中包含每个查询的标准偏差。这是标准化的平均延迟的样本，它来自。这是为了量化由模板谓词中的时间偏移和更改引起的方差诱导条件。平均在多程序设计级别3-5级以上。

在多道编程级别3，我们的错误率大致等于平均标准差。 我们的平均误差为15%，考虑到处理的各种情况(20个离散点乘以每个组合3个查询)，这是很好的拟合。 对于具有相对简单、I/O占主导地位的计划(如Q6)的查询，可以很好地建模。 具有更复杂聚合的查询更依赖于预取，因此对其补语的时间偏移很敏感。 这一现象的例子包括Q3和Q5。 稍后我们将讨论放宽这个稳态假设的影响。

6.4 Timeline Evaluation

接下来，我们评估时间轴方法对单个查询延迟的估计情况。我们再一次尝试了三个多编程级别。我们运行了250个随机生成的查询(模板和谓词都是以这种方式选择的)。这些测量排除了每次运行的预热和冷却期，以使我们的多编程水平保持不变。所有这些结果都来自同一组查询执行，分别用于JIT和队列建模时间轴分析。

JIT预测会对当前启动新查询时执行的所有查询产生一个延迟估计。我们使用这项技术来模拟用户提交立即运行的查询的场景。这个系统将使用户能够估计一个新查询将花费多长时间，以及它对当前运行查询的延迟的预计影响。在此上下文中，我们所处的场景是用户无法预测传入工作负载。因此，每当一个新的查询被引入时，我们都要重新评估延迟预测。

这种技术还允许我们对我们的估计进行实时的“航向修正”。在图9中，我们可以看到JIT技术的预测误差是如何随着时间的推移而收敛的。我们的预测自然遵循半锥状分布。查询越接近完成，我们的预测就越好。我们可以通过更频繁地评估来进一步提高我们的读数，可能是定期评估，而不是在调度一个新查询的时候。如果我们(例如)为等待查询结果或运行实时负载平衡的用户更新实时进度指示器，这将非常有用。

使用JIT估计器，我们的平均误差大约是10%。这是一个良好的延迟估计与从重新评估中纠正的组合。这就是为什么越高的多编程级别通常性能越好;当他们以更快的速度调度查询时，会更频繁地重新评估。

这一结果表明，我们可以 (a)为用户提供实时指导，告诉他们调度决策将如何影响当前运行的查询以及正在考虑调度的查询; (b)我们可以对任意混合进行预测。 因此，我们不受初始稳态构型的限制。

由于数据库太大了，以至于在任何给定的时间内，大多数数据库都无法放入内存中，所以能够脱离稳态估计并仍然产生类似的错误率。 因此，我们的估计可以适应RAM定期更改其内容的情况，从而消除了对缓冲池状态进行离散建模的必要性。

最后，在图11中，我们检查了我们的预测器在处理任意混合的情况下，对单个混合的持续时间和内容的不确定性有多大。使用队列建模技术，我们通过预测主查询及其补充查询何时终止来构建一个延迟估计。我们通过在补充查询投影到终止查询时，从提供的队列中添加新的查询来建模连续多编程级别。当我们的主查询被投影为被队列中的元素替换的下一个查询时，模拟结束。

总的来说，这使我们的准确率水平平均达到21%。这接近于我们在稳态下的估计精度。这种准确性表明，我们的框架可以在实际的查询启动和停止间隔的情况下进行预测。这样可以让用户一目了然。在考虑调度一批查询时进行“假设”分析。这个框架可以让用户形成他们查询的不同顺序，并提交给我们的系统进行评估。这将搜索提交查询的省时排序。

这些结果还表明，我们的系统可以容忍一些不确定性的混合执行。 尽管我们的稳态估计具有有限的固有误差，但这并不会过度影响我们的混合工作负载情况。 在许多情况下，时间轴错误并不显著，因为当我们在混合之间进行转换时，我们一次执行一个查询。 因此，就它们对主查询的影响而言，后续的混合仅略有不同。