OLTP-Bench Testbed

【原文信息】

D. Van Aken, D. E. Difallah, A. Pavlo, C. Curino, and P. Cudré-Mauroux, "BenchPress: Dynamic Workload Control in the OLTP-Bench Testbed," in Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data, 2015, pp. 1069-1073. [PDF]

【译文】

BenchPress: Dynamic Workload Control in the OLTP-Bench Testbed

ABSTRACT

在选择数据库产品、系统调优和探索底层引擎时，基准测试是一项必不可少的工作。但是，用于这项工作的工作负载通常是受制约的，无法代表现行数据库产品不断变化的需求。我们最近推出了OLTP Bench，它是一个可扩展的测试平台，可由15个工作负载捆绑在一起用于基准关系数据库的测试。使这个框架与众不同的关键特性是它能够严格控制请求率并动态地更改混合事务。这使得管理员可以组成复杂的执行目标，模拟创建真实的系统负载，打开了通向新的研究方向的大门，此外此系统还可针对特殊执行模式和多用户的调优。在本演示中，我们通过BenchPress游戏突出了OLTP工作台的重要功能。它允许用户实时控制多个数据库管理系统的基准行为。

INTRODUCTION

新的数据库计划是由新出现的用例或改进现有部署的需要所推动的。为了使这些工作取得成功，使用精确和灵活的测量工具比较数据库管理系统（DBMS）并在不同情况下强调它们是非常重要的。其中一种方法是使用基准，因为它允许人们理解和比较这些系统的性能。多年来，基准测试已经从一组生成单个性能数字的简单例程演变为现在通常涉及不同工作负载、参数、系统配置和其他变量的复杂工作[4]。

数据库管理员和研究人员使用通用的行业标准基准或（如果需要）自定义工作负载来测试DBMS[2，5]。在后一种情况下，这些工作负载的代码和数据集（如果有的话）并不总是可用的，或者维护得不好。因此，这使得其他人很难验证以前项目的结果，或者将基准移植到其他DBMS。除此之外，尽管过去已经提出了一些重要的基准，但据我们所知，以前还没有一个广泛的、适应性强的试验台。研究人员和实践者经常为每一个新项目“重新设计方向盘”，并反复花费时间收集数据、构建真实或合成工作负载、部署数据库系统、构建驱动其系统的软件，最后创建工具来收集和分析结果。多年来，我们注意到，我们和其他人为评估DBMS而构建的许多软件组件都是可重用的。

除了冗余工作之外，缺少现有的工具也大大限制了比较相关系统和方法的机会，因为为异构部署设置测试条件非常耗时。使这个软件对数据库社区可用会促进并鼓励实验的可重复性。

基于这些原因，我们开发了OLTP基准测试台，旨在使DBMS的可靠性和重复评估变得更容易[3]。OLTP工作台能够在实验执行期间动态控制事务速率、混合和工作负载偏差。这允许我们模拟许多通常难以测试的实际场景（例如，时间演化的访问倾斜）。我们的框架提供了一种简单的方法来监视测试中的数据库系统的性能和资源消耗。它目前支持超过15个基准，包括合成微基准、OLTP基准和真实的Web应用程序。这些都是由这项工作的作者和社区中的几个贡献者报告的。

在构建OLTP工作台时，我们关注的一个具有挑战性的方面是能够非常精确地控制请求速率。正如我们在第2节中所描述的，对于单个代码库中的多个DBMS，这是很难实现的。此外，OLTP工作台还支持在执行期间根据用户定义的工作负载动态更改事务请求率。有了这两个特性，一个可以在OLTP工作台上设计复杂的执行场景。例如，可以并行运行多个工作负载，以测试DBMS支持多租户部署的能力。在本演示中，我们通过台式机展示了OLTP工作台的动态和灵活控制特性。BenchPress是一个图形界面，允许用户实时控制OLTP工作台的行为。它支持动态修改基准的事务工作负载组合和吞吐量，以及动态执行其他基准。该演示还允许用户在同一框架内比较不同的DBMS。接下来，我们将在第2节中概述OLTP工作台的主要技术贡献，并在第3节中讨论演示中可用的数据集和基准。最后，我们在第4节中讨论了BenchPress如何允许用户在我们的演示测试台中处理这些不同的方面。

2. OVERVIEW
OLTP工作台是一个可扩展的，其中包括“数据库基准测试台[3]。它与许多单节点DBMS、分布式DBMS和DBAS系统一起工作，这些系统通过JDBC支持SQL。如图1所示，我们的框架结构由两个主要组件组成：（1）客户端基准驱动程序和（2）服务器端模块。OLTP底层完全是用Java编写的，包括所有内置的基准。客户端部分小且可移植（小于5MB）。该框架已经在各种类似Unix的平台上进行了测试和部署。

2.1 Architecture
OLTP工作台的客户端组件包含一个集中式工作负载管理器，负责通过集中式请求队列严格控制工作负载的特性。它将一个描述具有多个执行阶段的预定义工作负载的配置文件作为输入，其中一个阶段定义为（1）目标事务速率，（2）事务混合，以及（3）以秒为单位的时间持续。WorkloadManager生成多个客户端工作线程，每个线程使用JDBC连接到目标DBMS，并从请求队列中迭代地提取任务。对于每个新的事务请求，工作人员调用相应事务的控制代码（即带有参数化查询的程序逻辑），并提交或中止事务。然后，工作线程返回队列以检索其下一个任务。为了处理跨多个DBMS SQL语言的可移植性，我们决定使用支持手写方言翻译而不是自动工具。这样，我们允许各个系统的专家为不同系统的DML和DDL查询和操作贡献特定的SQL变量。在服务器端，我们使用与OLTP工作台并行启动的标准服务器监控工具[7]，并在主机上收集系统性能指标时实时提供这些指标。

2.2 Features
在[3]中，我们介绍了激发OLTP工作台后面的设计决策的需求。我们在下面概述了我们实现的这些关键功能。

2.2.1 Rate Control

在数据库管理系统中，高精度控制请求率的能力对于解释异常非常重要。即使吞吐量中的小振荡也会使结果的解释变得困难。OLTP工作台可以以开环方式执行事务，也可以在预定义的时间段内以每秒受限事务的速率执行事务[6]。这允许我们评估一个DBMS能够承受长时间连续负载的能力。如上所述，运行时吞吐量通过工作负载管理器的请求队列控制。在运行时，管理器生成新请求并将其添加到此队列中。工作人员从队列中提取一个请求，执行它，休眠一个可选的“思考时间”，然后返回队列以获取新的请求。使用集中式队列允许我们从一个位置控制吞吐量，而不需要协调多个工作线程。配置的请求的确切数量将每秒添加到队列中，并且每个到达都与一个统一的或指数的到达时间交错。当工作人员无法跟上所有的请求时，剩余的请求将被延迟，这样框架就永远不会超过目标速率。如果请求无限吞吐量，则将到达设置为大型可配置常量。

2.2.2 Mixture Control

当WorkloadManager将工作请求插入到队列中时，工作人员通过从预先定义的分发（或混合）中抽样来选择要执行的基准的特定事务。在OLTP工作台中，我们添加了在每个阶段或通过新的控制API按需更改给定基准中使用的事务组合的能力（参见第2.2.4节）。这允许用户使用不同的组合[3]进行实验，例如从重读工作负载转换为重写工作负载。

2.2.3 Multi-tenancy

OLTP工作台可以配置为并行运行多个工作负载和基准。我们引入的一个新特性允许用户执行多租户测试，在同一实例中隔离不同的工作负载。

2.2.4 Application Programming Interface

为了本演示的目的和对用户反馈的响应，我们为OLTP工作台创建了一个RESTful应用程序编程接口（API），它公开了在运行时以编程方式控制其执行的能力。这包括通过限制吞吐量或更改工作负载混合来更改当前阶段参数（参见第2.1节）。此外，此API还提供有关当前执行吞吐量和每个事务类型的平均延迟的即时反馈。正如我们在第4节中讨论的，这个API使我们能够将基准系统转换为BenchPress交互游戏。当用户在游戏中控制他们的角色时，他们的输入被转换成API命令，用于调整在OLTP工作台上运行的当前基准。然后，游戏从API接收状态更新，然后相应地修改游戏的视觉效果。除了benchpress之外，这个用于控制执行负载的API有助于在更广泛的测试基础架构环境中集成OLTP工作台。这对于动态创建新的工作负载混合以响应应用程序级的观察可能很有用。

3.BENCHMARK DATA & WORKLOADS

最近需要事务支持的基于Web和移动的应用程序的增长推动了传统基准的界限。我们选择了一组最初的基准测试来覆盖当前流行的一些应用程序，而不是尽可能详尽。表1概述了目前移植到OLTP工作台的15个基准及其应用领域。我们相信该表中的每个基准对于建模特定的应用程序领域都是有用的。我们注意到，管理员可以配置与每个基准对应的数据库大小，并且工作集大小可以自动缩放。我们的网站[1]上提供了更详细的信息，包括每个基准中各个交易的描述及其源代码。

4. DEMONSTRATION DESCRIPTION

BenchPress是一款允许用户通过API控制OLTP工作台行为的游戏。目标是能够在水平滚动障碍物过程中导航游戏角色。字符在给定时间点的垂直高度基于目标DBMS的当前吞吐量（每秒事务数）。用户通过使用键盘或控制器增加或减少目标吞吐量来控制其字符。然而，字符只响应由oltpbench测量的DBMS提供的实际吞吐量。障碍物的边界对应于不同的目标吞吐量。如果DBMS无法传递请求的事务速率，则字符将陷入障碍。

BenchPress是一个在浏览器中运行的JavaScript应用程序。它连接到一个基于Web的应用服务器，该服务器连接到OLTP工作台。基准框架部署在包含多个目标DBMS的计算机上。我们的系统提供了许多测试来挑战用户，例如通过使用更高和更低的障碍来线性增加或减少执行模式。此演示允许用户（1）深入了解OLTP工作台中包含的基准，（2）熟悉OLTP工作台提供的功能，（3）引发有关特定执行模式如何影响DBMS性能和潜在暴露隐藏弱点的讨论。现在，我们将描述BenchPress演示的不同组件。

4.1 Gameplay

我们的演示是一个侧滚游戏，其中的字符是间接控制使用键盘或外部输入设备。如图2a所示，用户通过选择所需的基准开始游戏。每个基准对应于游戏中的不同角色。然后他们选择目标DBMS（图2b）。每个DBMS对应于不同环境条件下的不同阶段。例如，图2c中的屏幕截图显示mysql是森林级别。角色必须通过一系列障碍物前进，要么跳过障碍物，要么让角色由于模拟重力而坠落。现在，我们将在数据库基准测试的背景下更详细地描述这些概念：

•障碍物是一组限制角色在定义范围内移动的垂直管道。该范围由管道高度给出，并表示在给定时间段内预设挑战的预期吞吐量。如果用户无法通过这些障碍，那么游戏就结束了。这将导致BenchPress停止基准并重置数据库。

•跳跃请求更高的吞吐率，并使游戏角色向上移动。但是，字符的移动只反映了DBMS提供的实际吞吐量，而不是所请求的吞吐量。这将测量DBMS在OLTP工作台请求负载中的变化能力，从而允许用户轻松感知不同系统的响应。

•下降会使游戏角色在模拟重力后下降，即吞吐量自动线性下降，直到达到每秒0个事务，此时角色将落在地板上。不同的设置允许用户使用命令手动降低吞吐量。

4.1.1 Mixture Control

除了上述基本控制之外，用户还可以动态更改基准混合。也就是说，用户可以随时暂停BenchPress来更改工作负载参数，以避免出现障碍。这将导致OLTP工作台暂时阻止任何工作线程执行事务请求。除了能够通过手动为事务分配新的概率分布来完全定制工作负载之外，BenchPress还包括预设的混合。如图2d所示，这包括“读重”和“写重”工作负载混合。当DBMS努力保持通过一些困难障碍所需的速率时，修改工作负载混合允许玩家对角色有更严格的控制（有效地控制吞吐量）。例如，将工作负载混合切换为“读重”工作负载将由于减少锁争用而提高DBMS的吞吐量。

4.1.2 Challenges

我们的目标是创建一个DBMS必须响应的模拟负载。为此，挑战代表了在游戏期间在任何给定时间点实现的吞吐量。在台式机中，挑战的形式是一对垂直的障碍物，它们之间有一个狭窄的开口。这个开口可以直观地表示预期的吞吐量范围。游戏中的其他挑战是自动引导区，用户必须确定正确的吞吐量和混合，允许角色在没有任何外部输入的情况下成功地通过障碍物。也就是说，当游戏角色在这些区域中移动时，用户无法控制吞吐量。在这种情况下，障碍是一个目标吞吐量，必须在给定的时间段内实现。此挑战将使用户反思可用于实现给定目标执行的不同参数。对于本演示，我们创建了以下四种不同形状的挑战（尽管此列表并不详尽，但可以使用配置文件创建新挑战）：

Steps: 字符必须经历一组增加或减少的吞吐量级别。这模拟了数据库上不断增加的负载；在某个时刻，DBMS将变得饱和，无法再处理任何事务。在最坏的情况下，根据工作负载的不同，性能实际上可能会变得更差。

Sinusoidal: 角色必须以循环模式上下移动。这演示了一个波动的负载，并测试了DBMS在没有太多抖动的情况下优雅地响应的能力。

Peak: 经过一段时间的低吞吐量模拟某些稳定工作负载后，在恢复正常之前，会在短时间内创建一个吞吐量峰值。同样，这将显示DBMS对负载偶尔和突然增加的响应能力。

Tunnels: 自动引导区是一个长隧道，目标执行固定在高（或低）目标吞吐量的恒定范围内。这个挑战期望DBMS在很长一段时间内提供恒定的紧吞吐量。

4.2 Performance Visualization

BenchPress接口提供了有关DBMS在吞吐量和延迟方面的性能的可视化概述。为了补充这些信息，OLTP工作台监控工具将实时显示从DBMS运行的系统收集的度量。这些信息对于用户预测性能的潜在下降（例如，当接近CPU绑定时）很有用。因此，用户可以采取必要的措施，通过调低事务速率，防止最终撞上障碍物，并可能导致性能下降（见第4.1.1节）。例如，如果磁盘IO活动似乎已饱和，用户可以在该上下文中降低写密集型事务的百分比。

4.3 Demo Takeways

这个演示的目标是三重的。首先，我们的目标是通过一个超越DBMS典型后端演示的交互式演示吸引观众。其次，我们试图展示OLTP工作台动态控制多个数据库基准参数的能力。最后，我们希望游戏能为用户提供关于DBMS和事务性工作负载的一些关键见解。这方面的例子包括了解DBMS的弱点和OLTP工作台中内置的各种工作负载的特性（参见表1）。玩家将了解到，某些类型的事务比其他事务更难维持，某些事务无法用于实现高吞吐量，或者某些DBMS（和调优组合）无法通过隧道测试，因为它们产生振荡吞吐量。此外，游戏的两人版本允许玩家实时体验多租赁的效果，其中一人影响另一人。

5. ACKNOWLEDGEMENTS

这项研究是由美国国家科学基金会（III1423 210）和瑞士国家科学基金会（PP00 P2 128459）资助的。我们还向彼得·贝利斯提供道具，他的数据库和诱捕技能正在杀死它。当他的混音带掉下来时，所有的怀疑者都会被炸飞。

6. CONCLUSION

BenchPress是一种基准DBMS的新方法，它基于定义执行期望（即挑战），并通过游戏界面动态控制工作负载。在本演示中，我们提出了一组预先定义的挑战，利用我们的底层OLTP工作台框架支持的一组基准。这允许用户通过压力测试各种DBMS来探索其属性

OLTP-Bench Testbed相关推荐

如何使用vs来运行box2d中Testbed的案例
0 环境 vs: vs2012 box2d: Box2D_v2.1.2 1 得到box2d编译版本可以参考: https://blog.csdn.net/sty945/article/details ...
OLAP和OLTP的区别(基础知识)
联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的,他同时提出了关于OLAP的12条准则.OLAP的提出引起了很大的反响,OLAP作为一类产品同联机事务处理 ( ...
九、OLTP 性能调整与优化－－结语
OLTP性能调整与优化--结语根据软件生命周期的瀑布模型,应用程序的性能在其设计阶段就已经有了质的定性.如果在应用程序开发完成之后才想到优化,一般就只能治标不治本,在遇到严重的性能问题时,甚至需要将 ...
简单明了！OLTP场景下的数据分布式设计原则
来自:DBAplus社群作者介绍温卫斌,就职于中国民生银行信息科技部,目前负责分布式技术平台设计与研发,主要关注分布式数据相关领域. 前言最近几年做分布式项目,很多工作是关于OLTP(联机交易系 ...
OLTP与OLAP是什么？OLTP与OLAP的主要区别是什么？
OLTP与OLAP是什么?OLTP与OLAP的主要区别是什么? 目录 OLTP与OLAP是什么?OLTP与OLAP的主要区别是什么? OLTP是什么? OLTP是什么? OLTP与OLAP的主要区别是 ...
apache bench linux,linux – 如何在CentOS上安装Apache Benchmark？
我尝试在我的centos上使用 Is there a way to install Apache Bench (ab) without installing apache解决方案安装Apache Be ...
SAS vs SSD各种模式下MySQL TPCC OLTP对比测试结果
在各种测试组合方案中,组合10(组合10:SSD * 2, RAID 0, XFS,WB,nobarrier,noop)的综合性能最高,因此以它为基准,其他方案与其对比,下表是各组合和组合10的对比: ...
配置内存中OLTP文件组提高性能
在今天的文章里,我想谈下使用内存中OLTP的内存优化文件组来获得持久性,还有如何配置它来获得高性能.在进入正题前,我想简单介绍下使用你数据库里这个特定文件组,内存OLTP是如何获得持久性的. 内存中O ...
OLAP与OLTP介绍
联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的,他同时提出了关于OLAP的12条准则.OLAP的提出引起了很大的反响,OLAP作为一类产品同联机事务处理 ( ...
6 redhat 查看rtc时间_甜甜老师的DB Fun圈第2讲：GaussDB 100 OLTP 单机在RHEL7.6上的安装...
在[甜甜老师的DB Fun圈]第一讲的分享中,我们揭开了华为GuassDB数据库的神秘面纱,那么本期我们继续分享[甜甜老师的DB Fun圈]第二讲--GaussDB 100 OLTP 单机在RHEL7 ...

OLTP-Bench Testbed

OLTP-Bench Testbed相关推荐

最新文章

热门文章