benchmarking purpose_olap oltp数据库区别

编者按： Benchmarking 作为一个衡量标尺，可从不同的维度来客观公正公平的评价相关产品，例如：对应数据测评而言，有 TPC-C、TPC-H，TP-DS 等等。现有的这些测评 TPC-X 标准（Benchmarking）真的适合现有的 OLTP&OLAP 混合型数据库吗？现在对于很多 HTAP 数据库厂商来说，对外所发布的性能对比数据都是以 TPC-H 为基准，但是单方面或者说只看一个 TPC-H 真的能真实地反映出这些 HTAP 数据库的指标吗？这篇来自德国慕尼黑工业大学数据库研究组的 Paper 就给大家介绍了一种专门针对 HTAP 数据库测评的标准，真正的从 HTAP 的基础出发，引出如何正确地评测一款 HTAP 数据库产品。希望本文能够给诸多的 HTAP 厂商起到抛砖引玉的作用。
当然，除了 TPC-H 之外，StoneDB 也会持续基于此类专门针对 HTAP 的 Benchmarking 上做出优化，我们后续会及时给社区的小伙伴们同步我们的最新进展。

论文翻译：王学姣，编辑：李明康

背景介绍

在正式开始介绍这篇论文前，我想先介绍一下这篇论文作者的背景，首先是，三位作者的单位慕尼黑工业大学（TMU），想必在DB组待过的同学应该不会陌生，著名的 HyPer 数据库就是出自他们的手里。

HyPer 是一款高速主内存数据库系统，可在不影响性能的前提下，同时进行联机事务处理(OLTP)和联机分析处理(OLAP)。此外，它还能在同一个系统中对交易和分析进行统一处理。

怎么样？是不是听着很耳熟？没错，在我们上一期的学术分享会也提到：StoneDB：深度干货！一篇Paper带您读懂HTAP | StoneDB学术分享会第①期
清华大学李国良教授他们就把 HyPer 定义为第一代的 HTAP 数据库，可以说，任何一家研究 HTAP 数据库的企业，理解学习 Hyper 的架构还是有很有大帮助的。
让我们回到 2010 年，那一年，谷歌大数据“三驾马车“的论文最后一篇已经发表了四年，Hadoop 系列分化项目势头正猛；Oracle 收购了 Sun 公司间接获得了 MySQL，引起轩然大波；放眼整个数据库行业，关系型数据库也迎来了 NoSQL 运动的又一波挑战；OLTP 和 OLAP 在飞快发展，商业数据智能化分析的价值不断被放大，适用于 HTAP 的市场业务场景需求也不断增加，很多人提出了要做“Real-Time Business Intelligence（实时商业智能）”，在慕尼黑工业大学的数据库研究组组长 Thomas Neumann 教授和同组的 Alfons Kemper 教授较早地意识到了这一点，他们认为使用传统复杂的 ETL 链路处理方式会有天然的缺陷，包括不限于陈旧过时的数据（即数据新鲜度低）、系统的冗余和高昂的软硬件维护费用等等，为了尝试解决这些缺陷，他们正式发表了 HTAP 领域最经典的奠基论文之一《HyPer: Hybrid OLTP&OLAP High-Performance Database System》，这篇论文在数据库学术界上影响深远，除了 HTAP 概念的雏形，也提及了 In-memory、MVCC等关键技术，同时也标志着 HyPer 数据库的正式诞生。

Hybrid OLTP&OLAP Database Architecture

而今天介绍的这篇《Benchmarking Hybrid OLTP&OLAP Database Systems》，正是由这两位教授和他们的博士研究生 Florian Funke 共同发表的，当然，那个时候 HTAP 的概念还没有提出来，他们在文中用的都是 “OLTP&OLAP 数据库系统”，此文发表于2011年，同年6月他们还发表了一篇《The mixed workload CH-benCHmark》，也是讲的 HTAP 数据库基准测试，同样非常经典，值得一读。不得不说，人家这么搞数据库还是厉害，头一年整出个数据库类别，第二年这个类别的数据库怎么评测都给你整的明明白白，出招快准狠就是这样。

摘要

最近有这么一个操作型或实时商业智能（business intelligence，BI）的案例。在操作型 BI 场景下， OLTP 数据库和 OLAP 数据仓库分离的传统架构存在严重的延时。为解决这一问题，OLTP&OLAP 数据库系统正在紧锣密鼓地开发中。第一代 OLTP&OLAP 混合型数据库系统的出现要求有能够衡量其性能的工具。

当前市场中已经存在一些分别针对 OLTP 和 OLAP 工作负载广泛使用的标准化基准，但是却没有针对 OLTP 和 OLAP 混合负载的基准。因此，我们基于针对 OLTP 负载的 TPC-C 基准和针对 OLAP 负载的 TPC-H 基准，定义了一个可以测试 OLTP 和 OLAP 混合负载的基准：TPC-CH。TPC-CH 基准执行了如下混合工作负载：基于 TPC-C 的订单输入处理的事务性工作负载，以及基于该销售数据库的对应的 TPC-H 等效 OLAP 查询套件。派生于最广泛使用的 TPC 基准，TPC-CH 基准产生的结果与混合型系统和传统的单工作负载系统具有很高的可比性。因此，我们能够将我们的（或其他的）OLTP&OLAP 混合型数据库系统同 OLTP 系统（如 VoltDB）的 OLTP 性能和OLAP 系统的 OLAP 性能进行比较。

1. 简介

在线事务处理（online transaction processing，OLTP）和在线分析处理（online analytical processing，OLAP）这两个领域对数据库架构提出了不同的挑战。事务通常是短期运行的，大多涉及选择性很强的数据访问；而分析查询通常是长期运行的，大多需要扫描绝大部分数据。因此，具有高关键任务事务率的客户目前只能操作两个独立的系统：一个操作型数据库用于处理事务，一个数据仓库用于分析查询。数据仓库定期从 OLTP 系统中同步更新数据，并将最新数据转换为易于分析的模型。人们也尝试过在操作型系统中直接执行分析处理，但是这样做带来了难以接受的事务处理性能损耗【DHKK97】。

虽然这种数据分级（data staging）方法允许针对各自的工作负载对每个系统进行调优，但存在以下几个固有的缺点: 必须购买和维护两套软件和硬件系统。根据数据分级实施情况，可能需要增加额外的系统。所有系统都必须存储相同数据的冗余副本，但最重要的是，用于分析的数据并非最新数据，而是数据仓库中的陈旧快照。

近期有如下一个实时 BI 的案例。SAP 的联合创始人 Hasso Plattner【Pla09】发表了自己对当前 OLTP 和 OLAP 分离的现状的看法，并表示对市场更重视 OLTP 而感到遗憾。他强调了 OLAP 在战略管理中的必要性，并将实时分析对管理的预期影响与互联网搜索引擎对世界的影响进行了对比。 实时 BI 推动了新的数据库架构的诞生。这些新的数据库架构通常以内存（in-memory）技术为基础，如用于运营报告的行列混合存储 OLTP 数据库架构【SBKZ08，BHF09，KGT+10】和 HyPer【KN11】。它们使用一个系统来处理两种工作负载，从而消除了数据分级的缺点。

图1：DBMS 分类以及各分类的测试基准

不同的策略看起来可以在频繁的插入和更新与长时间运行的 BI 查询寻求平衡点：由交易触发的修改可以作为增量数据收集起来，并定期合并到作为查询基础的主数据集中【KGT+10】。或者，可以在 DBMS 上开发支持版本控制功能，从而实现基于最新数据的事务处理与基于版本化数据快照执行的查询之间的隔离。

这种新型 DBMS 的产生要求能分析其性能的方法。混合系统之间需要进行对比，以便对不同的实现策略进行比较。它们还必须与传统的通用 DBMS 和单工作负载 DBMS 进行比较，以证明其在性能和资源消耗方面的竞争力。

我们提出了 TPC-CH，这是一个旨在为所有类型的系统生成高度可比结果的测试基准（参见图1）。下一章评价了各相关基准。第3章描述了 TPC-CH 的设计。第4章描述了我们用于测试的系统。第5章提供了各类型 DBMS 代表的设置以及测试结果。第6章对本论文内容进行了总结。

2. 相关工作

TPC（Transaction Processing Performance Council，事务处理性能委员会）指定了在工业界和学术界广泛使用的基准来测量数据库系统的性能特征。TPC-C 及其后继产品 TPC-E 模拟了 OLTP 工作负载。TPC-C 中使用的模型由围绕产品或服务的管理、销售和分销的九个表（relation）和五个事务组成。数据库的初始数据随机产生，随着新订单的处理而更新。TPC-E 模拟了一家经纪公司的工作负载。它有一个更复杂的模型和伪真实的内容，用来更好地匹配实际的客户数据。但是，与 TPC-E 相比，TPC-C 的使用更为普遍【Tra10c，Tra10d】，因此具有更好的可比性。

TPC-H 是 TPC 目前唯一活跃于市场上的决策支持基准。它模拟了类似于 TPC-C 的业务场景中的分析工作负载。该基准包含8个表以及能够通过这8个表得到预期结果的22个查询。它的后继产品 TPC-DS 将采用星形模型、包含大约100个决策支持查询和填充数据库的 ETL 过程描述。但是，TPC-DS 目前尚未正式完成。

注意，通过简单地使用两个 TPC 模型（一个用于 OLTP，一个用于 OLAP）为混合型 DBMS 构建一个基准并不能产生有意义的结果。这样的基准无法洞察系统如何处理其最具挑战性的任务: 即如何并发处理对同一数据集事务和分析查询。

在线事务处理（CBTR）综合基准【BKS08】旨在衡量由 OLTP 和运营报告组成的工作负载的影响。CBTR 没有结合现有的标准化基准，而是使用了一个企业的真实数据。作者提到了数据生成器的概念，从而能够产生系统间可比较的结果。然而，CBTR 的重点似乎是为了某个企业的特定用例来对不同的数据库系统进行比较。

3. 基准设计

我们设计 TPC-CH 的首要目标是可比性。因此，我们将 TPC-C 和 TPC-H 进行了结合。这两个基准已经得到了广泛的使用并得到了市场的认可，且能够快速实施。并且二者在设计上拥有足够高的相似度，从而保证了可比性。

TPC-CH 由未经修改的 TPC-C 模型和事务、以及 TPC-H 查询的改编版本构成。由于这两个基准的模型（参见图2）都模拟了“必须管理、销售或分发产品或服务”的业务【Tra10a，Tra10b】，它们之间有一些相似之处。两个模型都包含ORDER(S) 和 CUSTOMER 表。此外，ORDER-LINE（TPC-C）和 LINEITEM（TPC-H）模型实体是 ORDER(S) 的子实体，因此彼此相似。

图2：TPC-C 和 TPC-H 的模型

TPC-CH 保持所有 TPC-C 实体和关系完全不变，并集成了 TPC-H 模型中的 SUPPLIER、REGION 和 NATION 表。这些表在 TPC-H 查询中频繁使用，并允许以非侵入的方式集成到 TPC-C 模型中。SUPPLIER 包含固定数量（10,000条）的条目。因此，STOCK 中的一条记录可以通过 STOCK.S I ID × STOCK.S W ID mod 10, 000 = SUPPLIER.SU SUPPKEY 与其唯一的供应商（SUPPLIER 表中对应记录）关联起来。

TPC-C 中的原始 CUSTOMER 表不包含引用自 NATION 表的外键。我们并没有改变原始模型，从而保持了与现有 TPC-C 的兼容性，所以外键是从字段 C STATE 的第一个字符开始计算的。TPC-C 规定第一个字符可以有62个不同的值（即大写字母、小写字母、数字），因此我们选择了62个国家来填充 NATION。根据 TPC-H 规范，主键 N NATIONKEY 是一个标识符。它的值被规定，从而使得与这些值相关联的 ASCII 值是一个字母或数字,即 N NATIONKEY ∈ [48, 57]∪[65, 90]∪[97. 122]。因此，不需要额外的计算来跳过 ASCII 码中数字、大写字母和小写字母之间的间隔。不支持从字符转换到 ASCII 码的数据库系统可能会偏离 TPC-H 模式，使用单个字符作为 NATION 的主键。REGION 包含国家的五个地区。新表之间的关系使用简单的外键字段来建模：NATION.N REGIONKEY 和 SUPPLIER.SU NATIONKEY。

3.1 交易和查询

如图4中的概述所示，该工作负载由五个原始 TPC-C 事务和22个来自 TPC-H 的查询组成。由于 TPC-C 模型是 TPC-CH 模型的子集，因此这5个原始事务可以直接执行，无需修改:
New-Order 该事务将一个带有多行数据的订单输入至数据库中。

对于每行数据，99%的情况下，供应仓库是主仓库。主仓库是固定的，其 ID 与一个终端相连。为了模拟用户数据输入错误，1%的事务失败并触发回滚：

• Payment：该事务更新客户的账号余额。15%的情况下，客户是从一个随机的远程仓库中选择的，在另外85%的情况下，客户与主仓库相关联。在60%的情况下，客户是按姓氏选择的，其他情况下则是按三要素键（three-component key）进行选择的。
• Order-Status：该只读事务报告客户最后一个订单的状态。60%的情况下，客户是按姓氏选择的。在其他情况下，客户按照客户 ID 选择。所选客户始终与主仓库相关联。
• Delivery：该事务一次交付10个订单。所有订单都与主仓库相关联。
• Stock-Level：该只读事务只对主仓库进行操作，并返回那些最近有售卖记录且库存水平低于阈值的库存商品的数量。

图3：TPC-CH 模型加粗显示部分为源自 TPC-H 的实体

图4：基准概述: 针对相同数据进行 OLTP 和 OLAP

TPC-CH 与其底层的 TPC-C 基准不同，因为它不模拟终端，并且在没有任何思考时间的情况下生成客户端请求，正如【Vola】所提议的。从而可以在相对较小的数据库配置上实现非常高的事务率。TPC-CH 中的事务与 TPC-C 中的事务是相同的，因此 TPC-CH 的结果可直接与做了同样修改的 TPC-C 的结果进行比较，例如 VoltDB【Vola】。此外，这些修改可以很容易地应用于现有的 TPC-C 工具，从而产生的结果与 TPC-CH 兼容。

对于工作负载中的 OLAP 部分，我们将 TPC-H 中的22个查询应用到了 TPC-CH 模式中。在修改这些查询以使之符合 TPC-CH 模型的过程的同时，我们也确保修改后的查询保留了它们的业务语义和语法结构。例如，查询5列出了通过本地供应商获得的收入（请见Listing 1 和 Listing 2）。这两个查询将相似的表连接起来，具有相似的选择标准，并执行求和、分组和排序操作。

Listing 1: TPC-CH 查询5

SELECT n_name, SUM(ol_amount) AS revenue
FROM customer, "order", orderline, stock, supplier, nation, region
WHERE c_id=o_c_id AND c_w_id=o_w_id AND c_d_id=o_d_id
AND ol_o_id=o_id AND ol_w_id=o_w_id AND ol_d_id=o_d_id
AND ol_w_id=s_w_id AND ol_i_id=s_i_id
ANDmod((s_w_id * s_i_id),10000)=su_suppkey
ANDascii(SUBSTRING(c_state, 1, 1))=su_nationkey
AND su_nationkey=n_nationkey AND n_regionkey=r_regionkey
AND r_name=’[REGION]’ AND o_entry_d>=’[DATE]’
GROUPBY n_name ORDERBY revenue DESC

Listing 2: TPC-H 查询5

SELECT n_name, SUM(l_extendedprice * (1 - l_discount)) AS revenue
FROM customer, orders, lineitem, supplier, nation, region
WHERE c_custkey = o_custkey AND l_orderkey = o_orderkey
AND l_suppkey = s_suppkey AND c_nationkey = s_nationkey
AND s_nationkey = n_nationkey AND n_regionkey = r_regionkey
AND r_name = ’[REGION]’ AND o_orderdate >= DATE ’[DATE]’
AND o_orderdate < DATE ’[DATE]’ + INTERVAL ’1’ YEAR
GROUPBY n_name ORDERBY revenue DESC

TPC-CH 不需要 TPC-H 规定的刷新函数，因为 TPC-C 事务会不断地更新数据库。查询何时必须包含这些更新将在下一章进行详细说明。

3.2 基准参数

TPC-CH 有四个参数：第一个参数用于指定数据库大小。在 TPC-C 中，数据库的大小由仓库的数量来决定。大多数表随着仓库数量的增加而增加，只有 ITEM、SUPPLIER、NATION 和 REGION 的大小不变。

第二个参数用于指定工作负载的构成。它可以纯 OLAP、纯 OLTP、也可以是两种工作负载的任意组合。该参数通过指定连接到数据库系统的并行 OLTP 和 OLAP 会话（流）的数量来设置。OLTP 会话按照官方规范【Tra10a】中描述的分布顺序调度随机 TPC-C 事务。OLAP 会话针对由这22个查询组成的查询集进行持续迭代。每个会话以不同的查询开始，以避免会话之间的缓存效应，如图4所示。

第三个输入参数用于指定隔离级别。较低的隔离级别（如读已提交）意味着较高的处理效率，而较高的隔离级别则保证了事务和查询的结果质量。 最后一个参数用来指定用做分析基础的数据的新鲜度。它仅适用于工作负载组合同时包含 OLTP 和 OLAP 两种负载的情况。数据新鲜度通过事务的时间或数量来指定，在该时间或数量之后，新发出的查询集必须包含最新的数据。从而该基准可以同时支持两种数据架构：一种可以支持在单一数据集上同时进行 OLTP 和 OLAP，另一种则是通过数据增量的应用来实现对 OLTP 和 OLAP 的支持。

3.3 报告要求

除了对用到的硬件和软件的描述之外，报告还需要包含以下系统特征信息：OLTP 引擎的性能由 New-Order 事务和所有事务的吞吐量来衡量。在 OLAP 端，针对每一次迭代和每一个会话统计查询响应时间。中值和查询吞吐量也是统计指标。除了新鲜度参数之外，需要报告数据集已存在的时长最大值。对于内存型（in-memory）系统，总内存消耗会按一定时间间隔报告，其中包括已分配但尚未使用的内存块。图5提供了一个报告样例。

图5：TPC-CH 基准的测试报告要求

4. 被测系统

在图1中，我们将 DBMS 分为四类。我们从四类 DBMS 中各选了一个代表进行了 TPC-CH 基准测试。

4.1 分析型数据库

MonetDB 是针对内存型 OLAP 数据库的最有名的列存存储方案。关于该系统的概述可以在总结性文件【bmk09】中找到。因此，我们使用 MonetDB 作为“OLAP型”类别的代表。此类别还包括 SAP 的 TREX (BWA)、IBM Smart Analytics Optimizer 和 Vertica 分析数据库。

4.2 事务型数据库

最近一家名为 VoltDB 的初创公司将 Michael Stonebraker 牵头创造的 H-Store 原型【KKN+08】进行了商业化。VoltDB 是一个高性能的内存型 OLTP 系统，它采用无锁方法【HAMS08】进行事务处理，其中事务在私有分区上操作，并以串行方式执行【Volb】。因此，我们使用 VoltDB 作为事务型数据库的代表。该类别还包括以下系统: P*Time【CS04】、IBM solidDB、Oracle 的 TimesTen 以及新启动的开发项目 Electron DB、Clustrix、Akiban、dbShards、NimbusDB、ScaleDB 和 Lightwolf。

4.3 通用数据库

此类别包含基于磁盘存储的通用数据库。我们选择了一个流行的、商业上可用的系统 System X 作为此类别的代表。

4.4 混合型数据库

这一类别包括 Hasso Plattner【Pla09】概述的 SAP 新数据库开发和我们的 HyPer【KN11】系统。Crescando【GUMG10】是一个特殊的 OLTP&OLAP 混合型系统，但是它的查询能力比较有限。

4.4.1 HyPer：虚拟内存快照

我们开发了一个新型 OLTP&OLAP 混合型数据库系统，该系统通过操作系统的虚拟内存管理【KN11】对事务数据进行快照。在该架构下，OLTP 进程“拥有”数据库，并定期（秒级或分钟级）派生出 OLAP 进程。此 OLAP 进程创建了数据库的新事务一致性快照。因此，我们利用操作系统提供的功能为新的、重复的进程创建虚拟内存快照。例如，在 Unix 中，这是通过调用 fork() 来为 OLTP 进程创建子进程来实现的。为了保证事务的一致性，fork() 应该只在两个连续的事务之间执行，而不应该在一个事务执行过程中执行。在4.4.1节中，我们将使用 undo 日志将动作一致的快照（在某个事务执行过程中创建的）转换成事务一致的快照来放宽此约束。

通过派生产生的子进程会获得父进程地址空间的精确副本，如图6中的重叠的页框面板所示。使用 fork() 创建的这个虚拟内存快照将用于执行一个 OLAP 查询会话，如图6中的右侧部分所示。

图6：派生新快照（左侧）和更新/写入时复制（右侧）

快照精确地停留在 fork() 发生时的状态。值得庆幸的是，最先进的操作系统不会立即复制这些内存段。相反，这些操作系统采用了一种延迟更新时复制（lazy copy-on-write）策略，如图6所示。最初，父进程（OLTP）和子进程（OLAP）通过将任一虚拟地址（例如，到对象 a）转换到相同的物理主存位置来共享相同的物理内存段。共享内存段在图中用虚线框标识。一个虚线方格表示一个尚未复制的虚拟内存页面。只有当对象被更新时，比如数据项 a，操作系统和硬件支持的更新时复制机制才启动对 a 所在的虚拟内存页面的复制。从而产生了可由执行事务的 OLTP 进程访问的新状态 a’，以及可由 OLAP 查询会话访问的旧状态 a。与图中所示不同，额外的页面实际上是为启动页面更改的 OLTP 进程创建的，而 OLAP 快照引用的是旧页面。如果创建了多个这样的快照，这一细节对于估算空间消耗非常重要（参见图7）。

图7：不同时间点的多个 OLAP 会话

至此，我们已经描绘了一个使用两个进程的数据库架构，一个进程用于 OLTP，而另一个用于 OLAP。由于 OLAP 查询是只读的，它们可以很容易地在共享相同地址空间的多个线程中并行执行。尽管如此，我们可以避免任何同步（锁定和锁存）开销，因为 OLAP 查询不共享任何可变的数据结构。现代多核计算机通常具有十个以上的内核，通过这种查询间的并行化，肯定可以大幅提高速度。

充分利用多核服务器的另一种可能性是创建多个快照。HyPer 架构允许任意快照。这可以简单地通过周期性（或按需）派生新的快照并由此启动新的 OLAP 查询会话进程来实现。图7提供了一个示例。图7中描绘了一个 OLTP 进程的当前数据库状态（最上层）和三个活跃的查询会话进程的快照，按时间顺序排列，时间越近，越靠上层。连续的状态变化由数据项 a（最老的状态）、a′、a′′和a′′′（最新的事务一致状态）的四种不同状态来突出显示。显然，大多数数据项在不同的快照之间不会改变，因为我们预期的快照间隔为几秒钟，而不是像当前使用 ETL 数据暂存方式的独立数据仓库解决方案那样以几分钟或几小时为间隔。原则上，活跃快照的数量不受限制，因为每个快照都“活在”自己的进程中。通过调整优先级，我们可以确保任务关键型 OLTP 进程始终分配有一个内核，即使 OLAP 进程数量众多和/或利用多线程，从而超过了内核数量。

会话的最后一个查询完成后，快照将被删除。这可以通过简单地终止正在执行查询会话的进程来完成。另外，快照删除不需要按照创建时间顺序进行。一些快照可能会因为某些特殊原因，比如用于详细盘点，需要保留更长时间。但是，快照的内存开销与从创建该快照到下一个快照（如果存在）或当前时间之间执行的事务数量成比例。该图使用数据项 c 说明了这一点，数据项 c 被物理复制用于“中年”快照，因此被最老的快照共享和访问。与我们的直觉有些不太一样的是，“中年”快照有可能会在早于最老的快照被终止，因为 c 驻留的页面将被操作系统/处理器自动检测为通过与物理页面相关联的引用计数器与最老的快照共享。因此，最老快照在“中年”快照终止后仍然存在——不像 a’所在的页面那样，最老快照在“中年”快照进程终止时被释放。最新的快照访问了包含在当前 OLTP 进程的地址空间中的状态 c’。

5. 结果

在本节中，我们给出了 TPC-CH 的粗略结果。我们使用的测试机使用的是 RHEL 5.4 操作系统，配有两个四核2.93 GHz Intel R Xeon R 处理器和 64GB 内存。所有数据库都扩展到了12个仓库，对查询集共执行了5次迭代。

图8：各系统的测试结果对比

对于 MonetDB，我们评估了一个执行纯 OLAP 工作负载的基准实例。我们排除了 OLTP，因为 MonetDB 中缺少索引会影响事务处理效率。我们在图9中展示了处理三个并行 OLAP 会话的结果。由于在这种情况下不涉及对数据库的更新，所以新鲜度和隔离级别参数无效。将查询流的数量增加到5几乎不会改变吞吐量，但是查询执行时间几乎增加了一倍。单个查询会话执行将执行速度提高了10%到45%，但是吞吐量下降到每秒0.55个查询。

对于 VoltDB，工作负载仅包括事务。每个仓库/分区一个“站点”（即12个站点）在我们的服务器上产生最佳结果。与 TPC-CH 规范不同，我们允许 VoltDB 只执行单分区事务，如【Vola】中所建议的，并跳过那些涉及多个仓库的 New-Order 和 Payment 实例。VoltDB 中的隔离级别是可序列化（serializable）。

对于 System X，我们使用了25个 OLTP 会话和3个 OLAP 会话。对于 OLTP 和 OLAP，配置的隔离级别是读已提交，我们对五个事务的组使用组提交。由于系统针对单个数据集进行操作，所以每个查询都是对最新的数据进行操作。图9显示了此设置下的测试结果。将 OLAP 会话从3个增加到12个之后，查询吞吐量从0.38个查询/秒提高到1.20个查询/秒，但是这种调整导致查询执行时间增加了20%到30%，且 OLTP 吞吐量下降14%。添加更多的 OLTP 会话也会大大增加查询执行时间。

对于 HyPer，我们混合使用5个 OLTP 会话和3个并行 OLAP 会话来执行查询。我们并没有像 VoltDB 那样简化单分区事务的运行，而是用3.1节中指定的跨仓库事务来挑战 HyPer。在一种设置下，OLAP 会话对最初加载的数据进行操作（参见图9）。在第二种设置下，为每个新的查询流创建一个新的快照（参见图9）。查询与事务通过快照隔离。在 OLTP 端，隔离级别为可序列化。

图9：VoltDB 和 HyPer 的内存消耗（加载后）

因为 HyPer 还没有独立的客户端和服务器进程，所以结果是由包含两个组件的单个驱动程序产生的。因此，HyPer 排除了由进程间通信引起的潜在性能损失，但其他被测系统却没有。HyPer 强大的 OLTP 性能源于其能将事务编译成机器码。VoltDB 使用 Java 编写的存储过程。

图9显示了 HyPer 和 VoltDB 的内存消耗。我们在这里没有提供 MonetDB 结果，因为 MonetDB 数据库大小不会随着时间的推移而变化。HyPer 对5个 OLTP 会话并发运行3个查询会话，并在每次迭代后生成一个新的虚拟机快照。VoltDB 执行纯 OLTP 工作负载。该图显示了初始加载完成后的内存消耗。

6. 小结

本文中，我们展示了一个适用于混合 OLTP 和 OLAP 数据库系统的基准——TPC-CH。这个基准是基于标准化的 TPC-C 和 TPC-H 基准开发的。它不仅适用于混合 DBMS，还可以用于将混合 DBMS 与 OLTP、OLAP、传统数据库以及通用数据库进行比较。我们用 TPC-CH 对各类数据库的主流产品进行了测试并证实了上述观点。

鸣谢

我们非常感谢 Dagstuhl 研讨会（Dagstuhl Workshop）在2010年9月进行的关于“稳健查询处理（Robust Query Processing）”研讨中，关于该基准卓有成效的探讨。另外，感谢 Stefan Krompaß 帮助实现了 System X 基准测试。

考虑篇幅，我们会把论文的附录部分放到官网上，欢迎大家关注~

StoneDB 已经正式开源，欢迎关注我们

官网：https://stonedb.io/

Github: https://github.com/stoneatom/stonedb

Slack: https://stonedb.slack.com/ssb/redirect#/shared-invite/email

参考文献