TPCH标准中文版修订版.docx
- 文档编号:2009147
- 上传时间:2023-05-02
- 格式:DOCX
- 页数:101
- 大小:690.20KB
TPCH标准中文版修订版.docx
《TPCH标准中文版修订版.docx》由会员分享,可在线阅读,更多相关《TPCH标准中文版修订版.docx(101页珍藏版)》请在冰点文库上搜索。
TPCBENCHMARKH
(决策支持)
标准规范修订版2.0.0
事务处理性能理事会(TPC)
101
致谢
TPC感谢TPC-D分会成员公司的工作,他们开发的第二版TCP-D规范是第一版TCP-H的基础。
TPC-D分会包括来自Compaq,DataGeneral,EMC,HP,IBM,Informix,Microsoft,NCR,Oracle,Sequent,SGL,Sun,Sybase,和Unisys各大公司的代表。
另外,TPC还要感谢TCP-D分会的顾问Jack Stephens先生的贡献,感谢他在标准规范和DBGEN开发方面的工作。
TPC成员
文档历史
日期
版本
描述
1999年2月26
草案1.0.0
通过邮件投票得到的标准规范的草案
1999年6月24
修订版1.1.0
对标准规范的第一个小修改
2002年4月25
修订版1.4.0
对关键字的说明
2002年7月12
修订版1.5.0
在8.6节附加了关于硬件EOL的东西
2002年7月15
修订版2.0.0
通过邮件投票得到的三年维护定价的草案
TPCBENCHMARK,TPC-H,QppH和QhpH都是事务处理委员会的标志。
任何团体都可以免费复制本文的全部或部分,或者将本分的全部或部分分发给任何其他团体,只要:
1、复制和分发的主要目的是传播TPC的材料;
2、TPC的版权提示,出版物的标题以及发表日期,还有其他提示都出现在复制品中以表明它是得到TPC允许的。
其它想复制或分发本文(包括哪些包含TPC问档内容但非TPC文档、规范或报告)而又不满足以上两个条件的团体必须得到TPC的书面许可。
目录
致谢 2
TPC成员 2
目录 3
条款0:
概述 5
0.1前言 5
0.2一般系统实现原则 6
0.3一般测量原则 7
条款1数据库逻辑设计 7
1.1商业和应用环境 7
1.2数据库实体,关系和特性 8
1.3数据类型定义 9
1.4表的规划 10
1.5执行的规则 13
1.6数据透明访问的要求 15
条款2.查询和更新函数 15
2.1查询的一般要求和定义 15
2.2查询一致性 17
2.3查询确认 20
2.4价格摘要报告查询(Q1) 20
2.5最小代价供应者查询(Q2) 21
2.6运送优先权查询(Q3) 24
2.7订单优先权检查查询(Q4) 25
2.8当地供应者数量查询(Q5) 26
2.9预测收入变化查询(Q6) 27
2.10货运量查询(Q7) 28
2.11国家市场份额查询(Q8) 29
2.12产品类型利润估量查询(Q9) 31
2.13返回项目报告查询(Q10) 32
2.14重要库存标志查询(Q11) 34
2.15货运模式和命令优先查询(Q12) 35
2.16消费者分配查询(Q13) 36
2.17促进效果查询(Q14) 38
2.18促进效果查询(Q15) 39
2.19零件/供应商关系查询(Q16) 40
2.20小量订单收入查询(Q17) 42
2.21大订单顾客查询(Q18) 42
2.22折扣收入查询(Q19) 44
2.23潜在零件促进查询(Q20) 45
2.24不能按时交货供应商查询(Q21) 47
2.25全球销售机会查询(Q22) 48
2.26更新函数的一般要求 50
2.27新销售更新函数(RF1) 51
2.28旧销售更新函数(RF2) 51
2.29数据库处理进程 51
条款3:
数据库系统特性 52
3.1ACID特性 52
3.2原子性需求 54
3.3一致性需求 54
3.4隔离性需求 54
3.5持久性需求 57
条款4缩放和数据生成 59
4.1数据库定义和扩展 59
4.2DBGEN和数据库填充 60
4.3数据装载时间 68
条款5.性能度量和执行规则 70
5.1术语定义 70
5.2配置规则 70
5.3执行规则 72
5.4度量 76
条款6.SUT和驱动器 78
6.1测试配置模型 78
6.2被测试系统(SUT)定义 79
6.3驱动器定义 80
条款7.定价 81
7.1被定价的系统 81
7.2定价方法 83
条款8.完全公开报告 85
8.1报告要求 85
8.2格式指导 85
8.3完全公开报告的内容 86
8.4执行总结 89
8.5完整的公开报告的可用性 92
8.6完整的公开报告的修订 92
条款9审计 93
9.1一般性规则 93
9.2审计员的审核表 94
附录A:
排序集 96
附录B:
通过确认的查询变形 97
附录C:
查询确认 100
附录D:
数据和查询产生程序 100
附录E:
简单执行摘要 100
条款0:
概述
0.1前言
TPCBenchmarkH(TPC-H)是一个决策支持的基准,它由一系列面向商务应用的查询和并行数据修改组成。
基准里选择的查询和组成数据库的数据在商业上都具有广泛的代表性并且易于实现。
本基准阐明了决策支持系统的三个方面:
·分析大量的数据;
·执行高复杂度的查询;
·回答关键的、经常需要回答的商业问题。
通过在可控环境下执行一系列针对标准数据库的查询,TPC-H评估各种决策支持系统的性能。
TPC-H查询:
·回答现实商业问题;
·模拟生成随机查询(比如通过点击图形界面产生的查询);
·比大多数OLTP事务复杂得多;
·包括各种各样的操作和选择性限制;
·在受测试系统的数据库服务器端产生高密度的活动;
·在某种遵守特定入口和有一定规模的数据库中执行;
·实现的时候带有由于与在线产品数据库同步而产生的限制。
TPC-H操作模型如下:
·对于众多终端用户的查询和对数据库中所有表的修改而言,除了少量的维护时间之外,数据应该是每周7天,每天24小时不停工作的;
·在OLTP数据库执行更新操作的过程中,TPC-H数据库跟踪OLTP数据库的状态,这些更新操作会成批提交大量影响决策支持数据库某些部分的修改操作;
·存储在TPC-H数据库中的商业数据的共性导致查询和更新操作会在任何时候被执行,并且二者存在着一定的联系。
另外,因为查询和更新可能并发执行,所以查询和更新操作的混合又受ACID特性的限制;
·为了达到性能和操作要求的最佳折衷,数据库管理员可以为查询和修改操作设定锁级别和并发调度规则。
拥有10000个供应商的商业数据,这是运行本测试所要求的最小数据库。
它的容量是一千万条记录也就是大约1G的数据量。
像在4.1.3节定义的那样,运行基准测试可能会使用更大的数据库容量(比如100G)。
TPC-H报告的性能度量单位称作TPC-H每小时完成复合查询性能指标,简称
QphH@Size(Size是测试数据库的大小),这一指标反映了系统处理查询的多方面的能力,这些方面包括执行查询所选择的数据库的大小,单步提交时的查询能力,以及多用户并行提交时的查询吞吐量。
TPC-H价格性能比单位简写为$/QphH@Size。
为了与TPC-H标准一致,
对于特定的配置,所有的对TPC-H结果的查询必须包含所有要求报告的部分(见5.4.6节)。
TPC-H认为对于不同数据库大小的TPC-H结果的比较是具有误导性的,并且不主张这样的
比较。
TPC-H数据库必须使用市场上销售的数据库管理系统(DBMS),并且查询的执行是通过一个使用动态SQL语言的接口。
本规范适用于各种不同的SQL语言,因此并不要求实现者完完全全的实现标准SQL。
TPC-H使用和其他基准相似的术语和单位,这些术语和单位由TPC和其他组织共同创建。
这种在术语上的相似性并不是说TPC-H测试结果和其他测试结果具有可比性,唯一可
与TPC-H结果相比较是其他采用同一修订版的TPC-H结果。
虽然本基准提供了一个能够代表很多决策支持系统的环境,但是并没有反映决策支持的所有要求。
另外,客户所取得的性能和销售商标明的性能的接近程度强烈依赖于客户应用环境和TPC-H环境的相似程度。
这种从测试而来的相对性能与在其他工作量或环境下的性能不一定一致。
任何对于其他环境下性能的推断是不可取的。
测试结果很大程度上依赖于工作负荷,特定的应用要求,以及系统的设计与实现。
系统性能会因为这样那样的因素而改变。
因此,当用户在考虑关键能力计划或产品评估决定时TPC-H不应该被用作具体用户应用测试的代替品。
测试发起者可以提供多个系统设计,只要它们遵守第6章描述的模型。
像第8章说明的那样,系统实现细节的完整公开报告(FDR)必须和测试结果同时提供。
注释1:
为了保证主文档的可读性而被分离出去的注释和附录也是本标准的一部分,
它们的规定也必须被遵守。
注释2:
有些附录的内容只提供了电子档,而不包含在本文档的印刷品中。
0.2一般系统实现原则
TPC测试的目的是为商业界使用者提供客观的性能数据,为了达到这个目的,TPC测试规范要求测试由系统,产品,技术以及定价多个部分组成,并且这些:
·是用户可以普遍得到的;
·是和某个TPC基准所代表的市场类别相一致的;
·对于相应的市场类别里的用户而言,较容易实现。
只要满足上面的要求,鼓励使用新的系统,产品,技术以及定价,但是严禁使用主要目的是为提高TPC测试性能而对于实际应用环境毫无实际用途的测试系统,产品,技术以及定价(以后统称为系统实现)。
换句话说,就是所有仅以提高测试成绩为目的而不是以提高实际性能或改善实际定价为目的的“测试专用”系统实现是禁止的。
根据下面的特征可以判断某个系统实现是不是“测试专用”。
没必要每点都满足,但是证据越多就越容易甑别一个不可接受的系统实现。
在这样一个复杂问题上作出判断并不需要绝对的确定或是基于某个合理疑点上的确定。
这个问题必须这样回答:
“基于手头上的证据,大部分的证据是否表明本系统实现是“测试专用”。
”
下面的这些特征可以判断一个系统实现是否是“测试专用”:
a)这个系统实现是不是普遍可得,有没有证明文件和技术支持?
b) 在TPC测试之外,这个系统实现在使用或应用上有没有重大的会限制它的应用的约束?
c)整个系统实现或部分系统实现是不是很蹩脚的集成到更大的产品中?
d)这个系统实现是不是专门利用了TPC测试的有限性(如查询分布情况,查询混合,并发或竞争,隔离要求等)?
而在某种意义上这种针对性措施对于测试所对应的应用环境而言并没有广泛的实用性。
e) 这个系统实现是不是不为供应商看好?
(这包括不能够成功地升级到和同类产品与技术水平相近地系统。
)
f)这个系统实现有没有要求最终用户,程序员或系统管理员非常的熟练?
g) 对于商家而言定价是不是非同寻常,或者和正常的商业行为而言定价是不是非同寻常?
如下的定价行为是可疑的:
·只有极少的客户可以得到的折扣;
·折扣被证明是非同寻常的;
·少量的得到超过25%的折扣而大量则会得到50%的折扣;
·定价是特价或抛售;
·对于折价商品在产品运输,质保或维护上有非同寻常的限制;
注释:
本处列出的特征没有打算包括驱动和系统实现的特殊层,因为它们不一定是商业软件,而且它们有自己特殊的要求和在第六章中列举的限制。
在第六章列出的特征和禁令用来判断驱动或系统实现的特殊层是不是“测试专用”。
0.3一般测量原则
TPC测试结果试图准确表现系统性能。
因此在测量结果时应该遵守某些原则。
测量时用到的步骤或方法不是在规范中明确描述就是留给测试发起者决定。
如果在规范中没有描述,那么测量的步骤和方法必须满足以下要求:
·方法是公认的工程惯例或标准;
·方法不会增强结果;
·测量结果所使用的仪器必须按照质量标准校准;
·在报告结果中的异常时要精确而坦率,即使在测试要求中并没有特殊要求。
注释:
鼓励使用新方法只要它们满足上面的要求。
条款1数据库逻辑设计
1.1商业和应用环境
TPCBenchmarkH测试由一系列商业查询组成,这些查询在某种意义上代表复杂的商业分析应用。
这些查询给出了一个实际的环境,描绘了批发商的活动以帮助读者将该基准的组件联系起来。
TPC-H不代表任何特定商业领域里的活动,而是可以被应用到任何需要管理,销售或在全球范围销售某种商品的行业。
(比如汽车租赁,食品销售,供应商等)。
但TPC-H并不是如何构建实际信息分析系统的模型。
测试的目的是减少在信息分析应用中出现的操作的多样性,同时又保留应用最根本的性能特征,也就是:
系统的利用率和操作复杂度。
要完全管理一个商业分析环境需要执行大量不同类型和复杂度的查询。
因为查询的运行时间,占用的系统资源以及被执行的频率
(不符合决策支持的特性),许多查询的主要目的并不是性能分析。
被选择的查询具有以下特征:
·它们非常复杂;
·它们选择各种各样的访问模式;
·它们带有在随机特性;
·它们检查可获得数据的大部分
·它们互不相同
·它们含有查询参数并在执行时变化
所选择的查询要为下面各类商业分析提供答案:
·定价和促销;
·供货和需求管理;
·利润和收入管理;
·顾客满意度研究;
·市场份额研究;
·运输管理。
虽然重点是信息分析,但本测试也认可数据库定期更新的需要。
这个数据库既不是商
业运作数据库的一次快照也不是一个支持OLTP程序并行操作的数据库。
这个数据库必须能够全天候支持对所有表的查询和更新。
虽然本测试模拟了一个视更新操作为数据维护不可分割的部分的商用环境。
但是实际上,测试中的更新操作没有模拟商用环境的这个方面。
它的目的更主要是展示DBMS的更新能力,同时评估维护辅助数据结构的性能代价,比如次索引。
注释:
本测试不包含任何用来验证数据库连续性的测试,也没有特定的系统功能可以
设置为用来测试数据库的连续性。
持续性和全天候工作能力的定义包含在测试规范中,这为预期的决策支持系统描绘了一幅更完美的图画。
一个系统实现即使没有全天候工作的能力,但只要它满足规范中描述的要求也能产生相应的测试结果。
决策者
决策支持数据库
商业分析
商业操作
OLTP
数据库
OLTP事务
图一:
上图说明了TPC-H所对应的商用环境,并且突出了TPC-H测试和其他TPC测试的根本区别。
其他TPC基准模拟了商用环境的操作端,在这一端事务以实时的基础被执行。
而TPC-
H测试则模拟了商用环境的分析端,在这一部分计算出未来走势、产生了精炼的数据。
然后这些东西被用于产生合理的商业决策。
在OLTP测试中原始数据从四面八方流向OLTP数据库,在这里这些数据会保留一段时间。
在TPC-H测试中,决策支持数据库(DSS)定期进行更新操作,它里面的内容被各式各样的决策者查询使用。
1.2数据库实体,关系和特性
TPC-H数据库的组成被定义为由八个单独的表(基本表)组成。
这些表的列与列之间的关系举例如图2:
TPC-H模式
图2:
TPC-H模式
图例:
·每个表名后面的括号内为这个表的列名的前缀;
·箭头指出表与表之间的一对多的关系;
·每个表名下方的数字或公式表示表的行数。
一些是SF(ScaleFactor)中的因子,用来获得数据库的大小。
在LINEITEM表中的行数是近似值(详见4.2.5)。
1.3数据类型定义
1.3.1下列数据类型将应用于每个表的列的清单中:
·Identifier
注释:
一个默认的数据类型是整形。
然而在SF大于300时,一些值将超出所支持的4个字节的整数。
用户必须使用一些其他的数据类型比如8个字节的整数、小数或者字符串类型来实现。
·Integer意思是必须为整数(比如值的增长为1),取值范围为-2,147,483,646到
2,147,483,647。
·Decimal意思是必须能够描述取值范围从-9,999,999,999.99到+9,999,999,999.99
内、数值增长为0.01的所有有理数。
·Big Decimal是扩展的Decimal数据类型,它具有的附加特性是它必须足够大以至于能够描述存放在临时表中创建的查询变量的总数。
·FixedText,sizeN是用来存储一个固定长度为N的字符串类型。
注释:
如果字符串本身小于长度N,那么剩余的空间必须被存储在数据库中,或者数据库自动加上一些空间使得CHAR_LENGTH()函数的返回值为N。
·Variabletext,sizeN是该列可以存储变量长度最长为N的字符串变量。
被定义为“Variabletext,sizeN”的列可以和定义为“fixedtext,sizeN”一样执行。
·Date是一个可以被描述为YYYY-MM-DD的值,它所有的字符均为数字。
一个日期必须能够描述连续的14年里的每一天,但是对日期的内部描述没有特殊的要求。
注释:
用户在选择数据类型时,申请的详细的数据类型定义必须由所有定义在模式中的数据类型的情况组成,除了标识列,它必须满足数据库缩放比例的要求。
1.3.2在这篇文档中使用的SF标记是用来描述数据库的比例因子的(详见条款4)。
1.4表的规划
以下的列表定义了每个表所需要的结构(列的清单)。
主键的注释及外键引用仅仅只是为了说明,而不是指定实现要求,例如完整性约束。
PART表的规划
列名
数据类型需求
注释
P_PARTKEY
identifier
SF*200,000
P_NAME
variabletext,size
55
P_MFGR
fixedtext,size25
P_BRAND
fixedtext,size10
P_TYPE
variabletext,size
25
P_SIZE
integer
P_CONTAINER
fixedtext,size10
P_RETAILPRICE
decimal
P_COMMENT
主键:
P_PARTKEY
variabletext,size
23
SUPPLIER表的规划:
列名
数据类型需求
注释
S_SUPPKEY
identifier
SF*10,000
S_NAME
fixedtext,size25
S_ADDRESSS_NATIONKEY
variabletext,sizeidentifier
40
外键引用N_NATIONKEY
S_PHONE
fixedtext,size15
S_ACCTBAL
decimal
S_COMMENT
主键:
S_SUPPKEY
variabletext,size
101
PARTSUPP表的规划
列名 数据类型需求 注释
PS_PARTKEY identifier 外键引用P_PARTKEY
PS_SUPPKEY identifier 外键引用S_SUPPKEYPS_AVAILQTY integer
PS_SUPPLYCOST decimal
PS_COMMENT variabletext,size199
主键:
PS_PARTKEY,PS_SUPPKEY
CUSTOMER表的规划
列名 数据类型需求 注释
C_CUSTKEY
C_NAME
identifier
variabletext,size
25
SF*150,000
C_ADDRESSC_NATIONKEY
variabletext,sizeidentifier
40
外码参照N_NATIONKEY
C_PHONE
fixedtext,size15
C_ACCTBAL
decimal
C_MKTSEGMENT
fixedtext,size10
C_COMMENT
主键:
C_CUSTKEY
variabletext,size
117
ORDERS表的规划
列名
O_ORDERKEYO_CUSTKEY
数据类型需求
identifieridentifier
注释
少量的计算SF*1,500,000
外键引用C_CUSTKEY
O_ORDERSTATUS
fixedtext,size
1
O_TOTALPRICE
decimal
O_ORDERDATE
date
O_ORDERPRIORITY
fixedtext,size
15
O_CLERK
fixedtext,size
15
O_SHIPPRIORITY
integer
O_COMMENT variabletext,size79
主键:
O_ORDERKEY
注释:
并不是所有的顾客都会有订单。
事实上,数据库中大约1/3的用户不会有任何订单。
这些订单随机的分配给2/3的用户(详见条款4)。
这样做的目的是为了在加入两个或更多的表时,数据库有能力操作“死数据”。
LINEITEM表的规划
列名 数据类型需求 注释
L_ORDERKEY identifier 外键引用O_ORDERKEY
L_PARTKEY identifier 外键引用P_PARTKEY,
和L_SUPPKEY混合引用(PS_PARTKEY,PS_SUPPKEY)
L_SUPPKEY identifier 外键引用S_SUPPKEY,
和L_PARTKEY混合引用外键(PS_PARTKEY,PS_SUPPKEY)
L_LINENUMBER integer
L_QUANTITY decimal
L_EXTENDEDPRICE decimal
L_DISCOUNT decimal
L_TAX decimal
L_RETURNFLAG fixedtext,size1
L_LINESTATUS fixedtext,size1
L_SHIPDATE date
L_COMMITDATE date
L_RECEIPTDATE date
L_SHIPINSTRUCT fixedtext,size25L_SHIPMODE fixedtext,size10
L_COMMENT variabletextsize44
混合的主键:
L_ORDERKEY,L_LINENUMBER
NATION表的规划:
列名
数据类型需求
注释
N_NATIONKEY
identifier
组合25nations
N_NA
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- TPCH 标准 中文版 修订版