TPC-DS标准规范（三）

TPC-DS是一套决策支持系统测试基准，主要针对零售行业。提供99个SQL查询（SQL99或2003），分析数据量大，测试数据与实际商业数据高度相似，同时具有各种业务模型（分析报告型，数据挖掘型等等）。国内目前相关的翻译文章较少。本文尝试对官网的TPC BENCHMARK DS Standard Specification（下称“原文”）进行翻译。翻译主要参照的是2017年发布的2.6.0版本。现在可以在 http://www.tpc.org/tpc_documents_current_versions/current_specifications.asp 查询到最新的版本。

 

6 数据访问性

 

6.1 数据访问性

被测系统必须满足本节中描述的数据可访问性要求。数据可访问性通过SUT考量：在包含表，EADS或元数据(metadata)的任何的不可恢复故障期间和故障之后，数据访问状态都要保持完整。

 

6.1.1 术语定义

6.1.1.1 数据可访问性：在包含表，EADS或元数据的单一耐用介质上，发生任何不可恢复故障期间和故障之后，能够进行完整数据访问。

 

6.1.1.2 耐用介质：数据存储媒介，可以是：

a. 固有的不易改变的介质（例如，磁盘，磁带，光盘，固态盘，持久存储器等）。

b. 具有自己的独立电源的易改变介质，当外部电源发生故障之后，保留数据并及时将数据传输到固有的不易改变的介质中的介质。

 

6.1.1.3 元数据：关于数据库的描述性信息。元数据包括表，索引和其他schema对象的名称和定义。通常被统称为元数据的各种术语，包括转移，信息schema，数据字典或系统目录。

 

6.1.2 数据可访问性要求

6.1.2.1 测试员应保证，测试系统在包含TPC-DS数据库对象的任何单一耐用介质上，发生不可恢复的故障期间和故障之后，完整数据访问的查询和数据维护功能可以继续执行。审计师随机选择用于测试的故障介质。

 

6.1.2.2 数据可访问性测试，是通过在第7.4节中描述的执行第一次数据维护测试期间，导致单个耐用介质的故障来完成的。如果所有当前和后续查询以及数据维护功能都能成功完成，则数据可访问性测试成功。

 

6.1.2.3 数据可访问性测试必须作为性能测试的一部分执行。测试结果是报告性能及结果的基础，标度因子要针对测试数据库选择。

 

7 性能指标与执行规则

7.1 术语定义

7.1.1 基准定义为执行负载测试，然后执行性能测试。

 

7.1.2 负载测试是指，在性能测试开始之前，对SUT进行配置过程的测试。负载测试不能包括在功率测试，吞吐量测试等等中执行的任何查询。

 

7.1.3 性能测试是指功率测试，吞吐量测试和数据维护测试。

 

7.1.4 查询流(query stream)是指，由单个仿真用户提交的排列查询的顺序执行。查询流由第4条定义的99个查询组成。

 

7.1.5 会话(session)是指，能够支持用户启动的数据库的唯一标识的进程内容。

 

7.1.6 查询会话(query session)是指功率测试或吞吐量测试的会话执行。

 

7.1.7 刷新运行是指一组数据维护功能的执行。

 

7.1.8 刷新会话是代表刷新运行的会话执行。

 

7.1.9 吞吐量测试由每个运行中的查询流的Sq查询会话组成。

 

7.1.10 功率测试由运行中的单个查询流的一个查询会话组成（不能多也不能少，就得是一个）。

 

7.1.11 数据维护测试由一系列刷新流组成。

 

7.1.12 查询是一个或多个有效的SQL语句的有序集合。查询模板是指语句中仅需将参数进行替换，就可以生成新的语句的代码块。SQL语句的顺序在查询模板中定义。

 

7.1.13 SUT由用于完成基准的组件组成。

 

7.1.14 驱动程序是指向SUT提交查询并测量其执行时间的机制。

 

7.1.15 必须在SUT位于的时区中采用时间戳。它定义为“yyyy-mm-dd hh:mm:ss.s”以及等效的任何表示形式，其中：

 

1. yyyy是年的4位数表示

2. mm是月的2位数表示

3. dd是日的2位数表示

4. hh是以24小时时钟表示法表示的小时的2位数字

5. mm是分钟的2位数表示

6. ss.s是秒的3位数表示，精度至少为1/10秒

 

7.1.16 经过时间以秒为单位测量，四舍五入至最接近的0.1秒。

 

7.1.17 测试数据库用来加载数据并创建执行TPC-DS基准测试所需的元数据。基准测试即负载测试，功率测试，吞吐量测试，数据维护测试和审核员要求的所有测试。

 

7.1.18 数据库位置是可以由测试数据库直接访问（读/写）加载数据的位置，用于根据负载测试，功率测试，吞吐量的要求在第2条中定义的TPC-DS表上查询或应用dml操作测试，数据维护测试和审核员要求的所有测试。

 

7.2 配置规则

7.2.1 驱动程序是一个逻辑实体，可以使用一个或多个物理程序，进程或系统实现（见第8.3节）。

 

7.2.2 驱动程序和SUT之间的通信必须限于每个查询一个会话。除了调度数据维护功能（见第5.3节）之外，这些会话之间禁止进行通信。

 

7.2.3 所有查询会话必须以完全相同的方式进行初始化，所有刷新会话也必须以完全相同的方式进行初始化。但是刷新会话的初始化可能与查询会话的初始化不同。

 

7.2.4 必须披露所有会话初始化参数，设置和命令。

 

7.2.5 驱动应通过与相应查询流相关联的会话，提交每个TPC-DS查询以供SUT执行。

 

7.2.6 对于数据维护功能而言，驱动程序只需要提交执行每个数据维护功能所需的命令。

 

7.2.7 驱动在性能测试期间向SUT提交的查询应限于将查询文本传输到数据处理系统，并且需要提交一些额外信息，以符合本文档中定义的测量和数据收集要求。此外：

 

1. 驱动程序和SUT之间的交互不应该向SUT或其任何组件指明执行计划，或者优先级是按时间还是特殊查询

2. 驱动与SUT之间的交互不得向SUT或其任何组成部分指明关于插入时间延迟的情况

3. 驱动不得在向SUT提交查询之前，之后或之间插入时间延迟

4. 驱动与SUT之间的交互不得改变SUT基于逐个查询的行为或配置（即数据处理系统或操作系统设置）。在性能测试执行过程中，这些参数不得改变。

 

7.2.8 环境假设

7.2.8.1 SUT，数据库或会话（包括任何相关参数，开关或选项设置）的配置和初始化应仅基于系统外部记录的，能够作为决策支持工作负载的系统功能。这个工作负载的特点是：

 

1. 大量数据的连续扫描

2. 汇总大量数据

3. 多表连接

4. 可能有延展排序(extensive sorting)

 

7.2.8.2 虽然配置和初始化可以反映我们对于工作实战的预期，但它不应该使基准的实际功能获得任何优势。 在基准测试中使用的查询仅仅是可能在这种实战环境中使用的查询类型的一种示例，而不一定是真实的用户查询。 由于查询和测试环境的限制，TPC-DS限制了某些数据库技术的使用（见第2.5条）。 一般来说，配置对基准绩效的影响应该代表其对由基准所模拟的程序的性能的预期影响。

 

7.2.8.3 构成操作系统，数据处理系统或会话配置的功能，开关或参数设置必须使得，DBA处于以下情况时，能够决定使用它们是否合理：

 

1. DBA已知上述工作量的一般特征

2. DBA已知数据库的逻辑和物理分布

3. DBA可以访问操作系统和数据库文档

4. DBA不了解关于产品的任何外部文件信息

 

在操作系统，数据处理系统或会话的配置和初始化中使用的每个功能，开关或参数设置必须符合以下标准：

 

1. 在整个性能测试中，它始终有效不会发生改变

2. 不得引用具体的表格，索引或查询，以提示查询优化器

 

7.2.9 收集通过指令请求的统计信息必须是数据库加载的一部分。如果这些指令要求收集不同列的不同级别的统计信息，则必须遵守以下规则。

 

1) 给定列收集的统计信息级别必须基于列中成员类。
2) 类定义必须仅依赖于逻辑数据库设计中的以下列属性（如第2条所定义）：
1. 数据类型
2. 可空
3. 外键
4. 主键
3) 类定义可以使用AND，OR和NOT运算符组合列属性，例如，一个类可以包含满足以下属性组合的所有列：[Identifier Datatype] AND [NOT nullable OR Foreign Key]。
4) 必须在所有表的所有列上始终应用类成员
5) 以分配统计为单位的统计数据应采用适用于所使用标度因子的固定值。不得使用非密钥列（如第3条规定）的基数，值或分布的任何信息来定制统计收集。

 

7.2.10 配置文件导向优化

 

7.2.10.1 使用配置文件导向优化（PDO）时，有一些特殊规定。其中二进制可执行文件(binary executables)被重新排序或以其他方式优化，以最适合特定工作负载的需要。这些规定不适用于数据库供应商在搭建商业数据库产品的过程中使用的PDO。相反，规定适用于测试发起人使用PDO来优化特定工作负载的数据库产品的可执行文件。如果满足以下所有条件，则允许这种优化：

1. 必须披露测试发起人使用PDO或类似程序。
2. 必须披露用于执行优化的过程和任何脚本。
3. 测试发起人使用的程序可以由客户在运送的数据库中合理使用可执行文件。
4. 数据库软件供应商必须支持应用程序优化的数据库可执行文件。
5. 第7.2.10.2节介绍了用于驱动优化的工作负载。
6. 基准的所有阶段都必须使用同一组可执行文件。

 

7.2.10.2 如果使用PDO，则用于驱动PDO的工作负载可以是针对任何所需标度因子的，以任何顺序执行的，TPC-DS查询或任何数据维护功能的任何子集，以及默认替代参数。必须报告在PDO中使用的查询/数据维护功能集。

 

7.3 查询验证

7.3.1 基准提交的所有查询模板应进行验证。

 

7.3.2 验证过程定义如下：

 

1. 填充资格数据。

2. 使用附录B 11.9.1.1节定义的资格替代参数执行查询模板。

3. 将输出与查询定义的答案集进行比较。

 

7.3.3 输出数据应符合设定的查询定义的答案集，且受7.5节中的约束。

 

7.4 执行规则

7.4.1 常规要求

7.4.1.1 如果负载测试、功率测试，吞吐量测试，或数据维护测试失败，基准运行无效。

 

7.4.1.2 基准测试执行期间，所有显性指令创建的表必须满足第6节所定义的数据访问性要求。

 

7.4.1.3 SUT，包括任何数据库服务器(S)，不得在功率测试开始前重启，直到所有测试完成后才能重启。

 

7.4.1.4 驱动应通过对SUT上的一个或多个会话提交查询。每个会话都对应有且只有一个SUT上的查询流。

 

7.4.1.5 SUT针对一个查询或数据维护功能时其并行操作（如查询内并行）是不受限制的。

 

7.4.1.6 驱动程序用来计算时间的intervals的实时时钟必须保证测量精度至少为0.01秒。

 

7.4.2 基准必须使用下面测试顺序：

 

a) 数据库负载测试

b) 功率试验

c) 吞吐量测试1

d) 数据维护测试1

e) 吞吐量测试2

f) 数据维护测试2

 

7.4.3 数据库负载测试

7.4.3.1 建立测试数据库的过程称为数据库加载。数据库加载由定时和非定时元件组成。

 

7.4.3.2 如第2.1节所定义的，测试数据库的填充，有两个步骤：

 

a) 生成步骤：使用dsdgen创建符合加载设备格式的数据。生成的数据可以存储在内存中，也可以存储在磁带或磁盘上的flat files中。

b) 加载步骤：将生成的数据存储到数据库的过程。

 

数据的生成和加载可以通过两种方式完成：

 

a) 从flat files加载：dsdgen生成flat files，将其存储或复制到SUT或与数据库地址不一样的外部存储空间，该数据即是TPC-DS数据的复制。在存储或复制到SUT或外部存储空间的过程中，这些数据可以被改变顺序和位置。在基准执行之前，数据必须从这些flat files加载到数据库。在这种情况下，只有加载到数据库的过程计作数据库加载时间。

b) 在线加载：dsdgen生成数据，直接通过在线加载设备加载到数据库的位置。在这种情况下，生成和加载是同时发生的，它们都算作数据库加载时间。

 

7.4.3.3 用于生成、排列、转移SUT或dsdgen的数据源可以与用于实际运行基准的不同。例如:

 

a) 从flat files加载时，可以用一个单独的系统或存储子系统，在数据库加载的flat files中生成、存储和排列dsdgen数据。
b) 在线加载时，独立的处理元可以生成和排列数据，并转移到数据库中。

 

7.4.3.4 仅用于填充测试数据库的生成阶段的资源必须做如下处理：

如果从flat files加载，

 

a) 加载阶段之前，用于生成和保存dsdgen数据或将数据转移至SUT的任何处理元件（如CPU或内存），不应包括在总价格中。

b) 用于生成和转移数据到SUT的任何存储设备（如磁盘驱动器、磁带驱动器或外设控制器）不应包括在总价格中

 

7.4.3.5 dsdgen生成的数据，在转移过程中可能需要其他程序进行辅助。如果使用非商用程序则需披露源码。程序功能仅限：

 

1. 对dsdgen生成数据排序。

2. 将生成数据进行转移。

 

7.4.3.6 只能使用SQL接口或商用程序完成数据库的加载。

 

7.4.3.7 数据库加载时间

7.4.3.7.1 加载时间(TLOAD)是指，加载用于执行性能测试的测试数据库的时间。加载时间必须披露。加载时间包括建表（符合2.1节要求），加载数据，创建并填充EADS，定义并验证约束条件，统计测试数据库，配置SUT以执行性能测试，确保测试数据库达到数据可访问性要求等等的时间。

 

7.4.3.8 TLOAD代表开始加载到加载结束的时间差。

 

1. 加载开始的时间从建表开始算/从读入flat files的数据开始算/dsdgen开始生成数据算起。以上三种哪个先开始就算哪个。

2. 加载结束时间是指测试数据库被填充完毕，所有EADS被创建，数据库备份完成，SUT配置完成时的时间。

 

7.4.3.8.1 以下5类不算在加载时间内：

 

a) 任何不影响数据处理系统状态的操作（如生成flat files，将flat files转移至SUT，将flat files内数据排序，操作系统级别的硬盘分区或配置）。

b) 任何并不因TPC-DS而产生的特殊的改变数据处理系统状态的操作。

c) 安装或卸载SUT上物理资源的时间损耗

d) 测试人员自发的测试数据库备份行为，且该备份行为并不是为了满足数据可访问性要求。

e) 创建RAID设备的操作。

f) 执行测试所需的数据验证测试。

 

7.4.3.8.2 数据库负载测试不能人力干预。

 

7.4.3.8.3 SUT或其任何组件的重启只能在负载测试开始之后，性能测试开始之前。

 

7.4.4 功率测试

7.4.4.1 功率测试在负载测试之后立即执行。

 

7.4.4.2 功率测试用于测量系统以单一流方式，处理该流中一系列查询的最短时间。

 

7.4.4.3 功率测试执行驱动提交的在SUT上的单一会话，单一查询流流识别码为0的查询。

 

7.4.4.4 功率测试中的查询需按照流识别码顺序逐一执行，见附录D 11.9.1.1

 

7.4.4.5 功率测试期间同一时刻只能跑一个查询。

 

7.4.4.6 /*唐犁：这一条原文也没写，但是有个小标题在这。*/

 

7.4.5 功率测试时间。

7.4.5.1 功率测试时间(TPOWER)是指功率测试开始到结束之间花费的时间：

 

1. 功率测试开始时间，是指驱动向SUT提交的查询流(Stream 0)中的第一条查询开始执行的时间。

2. 功率测试结束时间，是指驱动收到SUT从最后一个查询中输出的数据的时间。

3. 功率测试时间必须披露。

 

7.4.6 吞吐量测试

7.4.6.1 吞吐量测试用于测量系统在多用户查询情况下，处理最多查询所用的最短时间。

 

7.4.6.2 吞吐量测试1需在功率测试后立即执行。吞吐量测试与数据维护测试的顺序：

 

1. 吞吐量测试1在数据维护测试1之前，紧接着是吞吐量测试2，最后是数据维护测试2。

 

7.4.6.3 在吞吐量测试1和2期间，创建显性聚集（符合5.1.4定义）需保证其始终可以被查询处理。

 

7.4.6.4 每个查询流都有自己的TPC-DS查询模板的排序方式。附录D 11.9.1.1当中有前20个查询流的查询排列顺序。

 

7.4.6.5 吞吐量测试时，同一时刻，任何会话最多跑一个查询。

 

7.4.6.6 吞吐量测试执行驱动提交的查询流中查询，查询流数量由测试人员选择。SUT上的每个查询流只有一个会话并且每个流必须一个接一个的串联执行查询。

 

7.4.6.7 每个查询流都是不同的，它们有各自的流号(stream identification number)，流号从1排到S。S是吞吐量测试1+2的总流数。

/*唐犁：也就是说吞1跑完13个流，吞2一开始流号就是14。*/

 

7.4.6.8 每个流号分配给一个指定的查询流。测试过程中，相同流号必须代表相同的查询流。

 

7.4.6.9 Sq是大于等于4的偶数。

 

7.4.6.10 吞吐量测试1和2的流数要一样多。

 

7.4.6.11 每个查询流的查询要按照序号顺序执行，见附录D 11.9.1.1。

 

7.4.7 吞吐量测试时间

7.4.7.1 对于用于执行查询流s的第i条查询的查询模板t，查询执行的时间QD(s, i, t)是指以下两个时间点的差值：

 

1. 驱动将查询文件发给SUT后，开始执行查询的时刻。

2. SUT将查询的最后一个输出以及成功完成的信息发回给驱动的时刻。

 

7.4.7.2 所有的吞吐量测试及功率测试中的每个流当中的每个查询的耗时都要披露。

 

7.4.7.3 吞吐量测试1的耗时TTT1是吞吐量测试1的起始时刻到结束时刻的时间差值。

 

7.4.7.4 吞吐量测试1的起始时刻是指，驱动发到SUT上的第一个流中的第一个查询被执行的起始时刻。

 

7.4.7.5 吞吐量测试1的结束时刻是指，SUT将最后一个流中的最后一个查询的结果数据返回到驱动上的时刻。

 

7.4.7.6 吞吐量测试2的耗时TTT2是吞吐量测试2的起始时刻到结束时刻的时间差值。

 

7.4.7.7 吞吐量测试2的起始时刻是指，数据维护测试1结束的时刻。

 

7.4.7.8 吞吐量测试2的结束时刻是指，SUT将最后一个流中的最后一个查询的结果数据返回到驱动上的时刻。

 

 

7.4.7.9 两个吞吐量测试的耗时都必须披露。

 

7.4.8 数据维护测试

7.4.8.1 数据维护测试1和2是用于测量改变TPC-DS数据集的能力的测试。

 

7.4.8.2 每个数据维护测试需要执行Sq/2次刷新运行。

 

7.4.8.3 每个刷新用的都是dsdgen生成的专属数据。刷新运行顺序必须遵从dsdgen生成的顺序。

 

7.4.8.4 在5.1.4节定义的任何显性聚集创建，在吞吐量测试1中必须符合7.4.6.3中的定义。

 

7.4.8.5 刷新运行不能重叠，一次最多跑一个刷新。所有数据维护功能需要把第n次刷新都跑完才能开始跑第n+1个刷新。

 

7.4.8.6 跑刷新的时候数据维护功能的调度由测试人员负责。

 

7.4.8.7 在6.1.2节说的数据可访问性测试里，需要触发耐用介质故障。这一故障必须在第一个数据维护测试期间进行（作用于数维1的第一个刷新开始后到数维2的最后一个刷新结束前的这段时间）。

 

7.4.9 数据维护测试时间

7.4.9.1 数据维护测试的耗时DI(i,s)是指，用于数据维护功能I的第s次刷新的时间。改时间是指一下两个时间点的差值：

 

1. 驱动提交到SUT的数据维护功能i开始跑的时刻，或者驱动向SUT申请执行i的时刻。这俩哪个先出现就按哪个时刻算。

2. 驱动收到SUT返回的最后一个数据维护功能的最后一个刷新的结果以及成功跑完的信息的时刻。

 

7.4.9.2 DI(s)是跑刷新s的耗时。是DS(s)和DE(s)的时间差。DS(s)是刷新s的起跑时刻，DE(s)是跑完时刻。DS(s)也可以记作DS(i,s)，i就是刷新s的第一个数据维护功能。同理，DE(s)也可以记作DE(j,s)，j就是刷新s里的最后一个数据维护功能。

 

7.4.9.3 数据维护测试1的耗时TDM1是数维1开始到数维1结束的时间差。

 

7.4.9.4 数据维护测试1的开始时刻，是指数维1中第一个刷新的起始时间戳DS。

 

7.4.9.5 数据维护测试1的结束时刻，是指数维1中最后一个刷新（包括所有EADS更新）的结束时间戳DE。

 

7.4.9.6 数据维护测试2的耗时TDM2是数维2开始到数维2结束的时间差。

 

7.4.9.7 数据维护测试2的开始时刻，是指数维2中第一个刷新的起始时间戳DS。

 

7.4.9.8 数据维护测试2的结束时刻，是指数维2中最后一个刷新（包括所有EADS更新）的结束时间戳DE。

 

7.4.9.9 所有的数据维护功能的所有刷新的耗时DI(i,s)都必须披露。

 

7.4.9.10 对于每个DI(s)，其DS(s)与DE(s)也必须披露。

 

7.5 输出数据

7.5.1 跑完一个查询后，会返回一行或多行。这些行被定义为输出数据。

 

7.5.2 输出数据应遵循以下准则：

 

a) 列的显示顺序，与查询中select的顺序一致。

b) 列的标题可以自己定。

c) 包括价格在内的非整形表达式，必须以包含至少两位小数的小数形式表示。

d) 整数含0。

e) 日期必须以包含整数形式的年月日的形式出现，并按年月日顺序排列，比如YYYY-MM-DD。年月日之间的分隔符可以用别的形式表现，但是其他形式的日期，比如，自1970-01-01起至今的天数这种形式，是不支持的。

f) 字符串区分大小写，前后可以有空格。

g) 没有指定列之间的空格。

h) 带order的查询，其对应的验证数据必须和输出数据的order一致。不带order的无所谓。

 

7.5.3 输出数据中包含的所有值的精度应遵循以下规则：

 

a) 使用count聚集的结果，输出数据与验证数据的值必须完全匹配。

b) 输出数据和验证数据之间的差距不能大于验证数据的1%（四舍五入后取整的百分数）。

c) 使用sum聚集计算的货币的结果值，输出数据和验证数据不能差出$100。

/*

唐犁：这个有个问题，这文档是美国人写的，那要是按人民币算的话，难道是按汇率换算成700人民币？换算的话，误差百分比和数额虽然还是一致的，可是实际数值会比较大；不换算的话，实际数额相对于原基准又会比较小。我个人倾向于根据币种自定义一个阈值。

*/

d) 使用avg聚集的结果，输出数据和验证数据相差不能大于验证数据的1%（四舍五入后取整的百分数）。

 

7.6 度量指标

7.6.1 TPC-DS定义了三个主要度量指标：

 

a) 性能指标QphDS@SF，反映了TPC-DS查询吞吐量（见第7.6.3节）。

b) 价格-性能指标，$/QphDS@SF（见第7.6.4节）

c) 系统有效日期（见第7.6.5节）

 

7.6.2 TPC-DS还定义了一些次要度量指标：

 

a) 加载时间，见7.4.3.7节。

b) 功率测试耗时，见7.4.4节，以及功率测试中每条查询的用时。

c) 吞吐量测试1和2的耗时，见7.4.7.3和7.4.7.6节。

d) 选用TPC_Energy作报告的话，TPC-DS能量指标会报告每次性能的功率，并以Watts/QphDS@SF表示（详见TPC-Energy规范）。

 

注意，这些次要度量指标要结合标度因子一起考量。

 

7.6.3 性能指标(QphDS@SF)

7.6.3.1 QphDS@SF是基准的主要表现指标，公式为：

 

 

其中：

 

1. SF在3.1.3节中定义，SF的选取基于不同的标度因子。

2. Q是查询加权总数，Q=Sq*99，Sq是吞吐量测试的流数。

/*唐犁：之所以是Sq*99，是因为基准一共提供了99条SQL。*/

3. TPT=TPOWER*Sq，其中TPOWER是功率测试总耗时，见7.4.4节，Sq是吞吐量测试的流数。

4. TTT=TTT1+TTT2，其中TTT1是吞1耗时，TTT2是吞2耗时，见7.4.6节。

5. TDM=TDM1+TDM2，其中TDM1是数维1耗时，TDM2是数维2耗时，见7.4.9节。

6. TLD是加载因子，TLD=0.01*Sq*TLOAD，其中Sq是吞吐量测试的流数，TLOAD是加载时间，见7.1.2节。

7. TPT，TTT，TDM和TLD的运算单位是小时，精度至少保留到1秒。

 

7.6.3.2 上式最外面那个方括号形状的符号，表示舍去结果小数部分(floor)。

 

7.6.4 价格-性能指标($/QphDS@SF)

7.6.4.1 价格-性能指标的公式为：

 

 

其中，P是定价系统，见9.1.1节，QphDS@SF是7.6.3中的性能指标。

 

7.6.4.2 如果基准配置的定价使用美元以外的货币，则价格-性能指标也要进行币种换算。

 

7.6.5 TPC定价规范版本1中定义的系统有效日期，必须在任何性能指标或价格-性能指标相关的引用中披露。

 

7.6.6 公平的度量指标比较

7.6.6.1 由于在不同数据量下，计算挑战显著不同，因此不同标度因子的结果是不可比较的。类似地，由于数据库大小的变化所需的配置不同，系统的价格/性能可能不会随着数据库大小的减小而线性缩小。

 

针对不同数据库大小（即不同标度因子）得出的测量结果或度量指标，必须标明其对应的数据库大小。所有TPC-DS指标（性能度量指标或价格/性能度量指标）必须以包含测试数据库的大小的形式命名，即包括“@size”后缀。如果度量指标以图形形式呈现，则该测试数据库的大小必须通过适当的轴标签或数据点标签标明。

 

此外，结果必须附有免责声明：

“TPC认为，针对不同数据库大小测量的TPC-DS结果的比较是误导的，并且禁止这种比较”。

 

7.6.6.2 TPC-DS的结果之间的比较，只关注是否使用了相同的标度因子，即相同大小的数据库，并不关注测试期间使用的查询流的数量是否一致。

 

7.6.7 所需报告组件

为了符合TPC-DS标准和TPC的使用策略，对于给定配置的TPC-DS结果，其报告必须包括以下组件：

 

1. 测试数据库的大小，单独表示或作为度量名称的一部分（例如，QphDS@10GB）。

2. TPC-DS性能指标，QphDS@Size。

3. TPC-DS价格/性能指标，$/QphDS@Size。

4. 完整配置的可用日期，详见TPC网站上的TPC定价规范（http://www.tpc.org）。

 

以下是TPC-DS结果合规报告的两个示例：

示例1：基于TPC-DS，RALF/3000服务器在运行10GB数据库时，具有3010条查询/时的性能，价格/性能指标为1202美元/（查询/时），于06年4月1日起生效。

示例2：将于06年4月1日开始发货的RALF/3000服务器的性能指标为3010 QphDS@10GB，价格-性能指标为1202 $/QphDS@10GB。

 

8 SUT与驱动实现

 

本节定义了SUT和基准驱动。

 

8.1 测试配置模型

8.1.1 被测配置其实就是一个驱动和一个SUT。驱动向SUT发查询，SUT执行，之后把结果返回给驱动。从硬件和软件角度来说，驱动是安装在SUT的硬件和软件里面的。

 

8.1.2 图8-1描绘了驱动程序/SUT配置的示例。阴影区域代表驱动，该图还描绘了测量时间间隔的驱动器/SUT边界（见第7.1.16节和第7.4节）。

 

 

8.2 被测系统(SUT)定义

8.2.1 SUT由以下几部分组成：

 

a) 主机系统或服务器，包括支持访问数据库（指的是性能测试用的数据库）的硬件和软件。

b) 用于执行查询的任何客户端处理单元（例如，前端处理器，工作站等）。

c) 与用户界面设备通信所需的硬件和软件组件。

d) 连接和支持SUT组件所需的所有网络的硬件和软件组件。

e) 满足第3节中的缩放规则，第1.6节中的数据访问属性，以及第7.5节中描述的数据的要求的数据存储介质。

 

8.2.2 所有SUT组件，如第8.2.1节所述，应为市售的软件或硬件产品。

 

8.2.3 可以在SUT上实现特定层，该层应逻辑上位于驱动程序和SUT之间，如图8-2所示。

 

 

8.2.4 如果特定层在SUT上，则层应该是通用的（即不限于TPC-DS查询使用）。特定层的源代码必须披露，其功能应严格限于以下内容：

 

a) 在每条查询执行前或执行完的时间段里，进行数据库的交易控制。

b) EQT的游标控制及操作。

c) 处理动态SQL所需的过程和数据结构的定义，包括EQT与SUT的层（这些层需要是市面上可以购买到的层）的通信，以及查询输出数据的接收。

d) 与SUT的层（这些层需要是市面上可以购买到的层）的通信

e) 缓冲查询输出数据。

f) Communication with the drivere it

/*唐犁：这个f)我真的看不懂，drivere it到底啥意思有人知道吗？*/

 

以下是实现特定层不能执行的功能的示例：

 

a) 对可执行文件的任何修改。

b) 任何使用存储过程来执行查询。

c) 查询输出数据的任何排序或翻译。

d) 7.2.8.1节禁止的任何功能。

 

8.3 驱动定义

8.3.1 驱动是指一个可以由一个或多个程序，进程，或系统实现的逻辑实体，它负责向SUT提交工作负载。驱动的功能只能是以下几种：

 

a) 生成唯一的流ID，每个查询流都是从1开始。

b) 按照查询顺序执行查询。

c) 激活，调度和/或同步数据维护功能的执行。

d) 生成每个查询的EQT。

e) 生成每个查询的替换参数的值。

f) 将生成的替换参数值替换进去，如果有需要也可以把相应的文本的流ID替换。

g) 将每个完整的EQT发给SUT供其执行，如果每个查询对SUT返回结果的行数有要求，驱动也要告知SUT。

h) 将每个数据维护方法发给SUT供其执行。

i) 接受SUT返回的查询执行结果数据集。

j) 测量查询和数据维护方法的执行时间并进行统计。

k) 维护查询文本以及输出结果集的工作日志。

 

8.3.2 用于发给SUT执行的EQT，其生成过程不应该发生在SUT上，生成耗时也不应计入任何测试时间。

 

8.3.3 驱动不应该有8.3.1节以外的任何功能，比如：

 

a) 驱动不应该有8.3.1节以外的任何表现，行为，同步，或操作。

b) 对两个查询执行之间加入任何在8.3.1中不必要的延迟。如果有加入延迟的需要，延迟只能加在同一个流内相邻两个查询间，时长不能超过半秒。加入延迟必须在报告中注明。

c) 在发给SUT之前修改了EQT的兼容性。

d) 将查询文本嵌入执行计划或者程序中。

e) 向SUT提交一个查询替换参数的值，该值并不包括在这个查询的原文本中。

f) 向SUT提交，用于数据维护功能/兼容EQT/要求的结果集返回行数，以外的任何数据。

g) 人为延长任何查询的执行时间。

 

8.3.4 驱动价格不计入总价。