编者按： 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 DESCListing 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 DESCTPC-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