benchmarking是什么意思,benchmarking的意思翻译、用法、？Benchmarking

老铁们，大家好，相信还有很多朋友对于benchmarking是什么意思,benchmarking的意思翻译、用法、和Benchmarking的相关问题不太懂，没关系，今天就由我来为大家分享分享benchmarking是什么意思,benchmarking的意思翻译、用法、以及Benchmarking的问题，文章篇幅可能偏长，希望可以帮助到大家，下面一起来看看吧！

编者按：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)。此外，它还能在同一个系统中对交易和分析进行统一处理。

怎么样？是不是听着很耳熟？没错，在我们上一期的学术分享会也提到，李国良教授他们就把HyPer定义为第一代的HTAP数据库，可以说，任何一家研究HTAP数据库的企业，理解学习Hyper的架构还是有很有大帮助的。

让我们回到2010年，那一年，谷歌大数据“三驾马车”的论文最后一篇已经发表了四年，Hadoop系列分化项目势头正猛；Oracle收购了Sun公司间接获得了MySQL，引起轩然大波；放眼整个数据库行业，关系型数据库也迎来了NoSQL运动的又一波挑战；OLTP和OLAP都在飞速发展，商业数据智能化分析的价值不断被放大，适用于HTAP的市场业务场景需求也不断增加，当时很多人提出了要做“Real-TimeBusinessIntelligence（实时商业智能）”，在慕尼黑工业大学的数据库研究组组长ThomasNeumann教授和同组的AlfonsKemper教授较早地意识到了这一点，他们认为使用传统复杂的ETL链路处理方式会有天然的缺陷，包括不限于陈旧过时的数据（即数据新鲜度低）、系统的冗余和高昂的软硬件维护费用等等，为了尝试解决这些缺陷，他们正式发表了HTAP领域最经典的奠基论文之一《HyPer:HybridOLTP&OLAPHigh-PerformanceDatabaseSystem》，这篇论文在数据库学术界上影响深远，除了HTAP概念的雏形，也提及了In-memory、MVCC等关键技术，同时也标志着HyPer数据库的正式诞生。

HybridOLTP&OLAPDatabaseArchitecture

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

最近有这么一个操作型或实时商业智能（businessintelligence，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性能进行比较。

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

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

近期有如下一个实时BI的案例。SAP的联合创始人HassoPlattner【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章对本论文内容进行了总结。

TPC（TransactionProcessingPerformanceCouncil，事务处理性能委员会）指定了在工业界和学术界广泛使用的基准来测量数据库系统的性能特征。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的重点似乎是为了某个企业的特定用例来对不同的数据库系统进行比较。

我们设计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)的子实体，因此彼此相似。

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

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

如图4中的概述所示，该工作负载由五个原始TPC-C事务和22个来自TPC-H的查询组成。由于TPC-C模型是TPC-CH模型的子集，因此这5个原始事务可以直接执行，无需修改:

New-Order该事务将一个带有多行数据的订单输入至数据库中。

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

图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列出了通过本地供应商获得的收入（请见Listing1和Listing2）。这两个查询将相似的表连接起来，具有相似的选择标准，并执行求和、分组和排序操作。

Listing1:TPC-CH查询5

SELECTn_name,SUM(ol_amount)ASrevenue\nFROMcustomer,"order",orderline,stock,supplier,nation,region\nWHEREc_id=o_c_idANDc_w_id=o_w_idANDc_d_id=o_d_id\nANDol_o_id=o_idANDol_w_id=o_w_idANDol_d_id=o_d_id\nANDol_w_id=s_w_idANDol_i_id=s_i_id\nANDmod((s_w_id*s_i_id),10000)=su_suppkey\nANDascii(SUBSTRING(c_state,1,1))=su_nationkey\nANDsu_nationkey=n_nationkeyANDn_regionkey=r_regionkey\nANDr_name=’[REGION]’ANDo_entry_d>=’[DATE]’\nGROUPBYn_nameORDERBYrevenueDESC\n

Listing2:TPC-H查询5

SELECTn_name,SUM(l_extendedprice*(1-l_discount))ASrevenue\nFROMcustomer,orders,lineitem,supplier,nation,region\nWHEREc_custkey=o_custkeyANDl_orderkey=o_orderkey\nANDl_suppkey=s_suppkeyANDc_nationkey=s_nationkey\nANDs_nationkey=n_nationkeyANDn_regionkey=r_regionkey\nANDr_name=’[REGION]’ANDo_orderdate>=DATE’[DATE]’\nANDo_orderdate<DATE’[DATE]’+INTERVAL’1’YEAR\nGROUPBYn_nameORDERBYrevenueDESC\n

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

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的支持。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

对于SystemX，我们使用了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工作负载。该图显示了初始加载完成后的内存消耗。

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

我们非常感谢Dagstuhl研讨会（DagstuhlWorkshop）在2010年9月进行的关于“稳健查询处理（RobustQueryProcessing）”研讨中，关于该基准卓有成效的探讨。另外，感谢StefanKrompa?帮助实现了SystemX基准测试。

考虑篇幅，我们会把完整包含论文的附录的翻译文章放到官网上，欢迎大家前往阅览。

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

https://github.com/stoneatom/stonedb

本文系列责编：李明康

论文解读仅供知识分享，难免有误，如有不足，欢迎指正

如果你还想了解更多这方面的信息，记得收藏关注本站。