TPCC笔记

TPCC

介绍

TPCC是TPC组织联合Oracle、IBM、思科等企业制定的单机事务数据库测试基准。是OLTP工作负载。它模拟了一个仓储物流的业务场景，包括新建订单、付款、发货、订单查询、库存查询五个事务操作。

这个测试基准所描绘的公司是一个仓库提供者，拥有一些地理分散的销售区域和联系起来的仓库。当公司的商业扩展的时候，将会创建新的仓库和与其联系起来的销售区域。每个地区的仓库包含十个区域。每个区域服务3000个顾客。所有仓库都为公司维护100000个售卖的商品。下面的图说明了TPCC商业环境的仓库、区域和顾客的层级：

1.2 数据库实体、关系和特征

1.2.1 TPCC数据库由9个分离和独立的表组成。下面的实体关系图是这些表之间的关系：

1.3 表的布局

1.3.1 下面定义了每个表的最小结构：

• N唯一ID意味着属性必须能够在最少N个唯一ID集合中保存任何一个ID，而不管属性的物理表示形式（例如二进制、压缩十进制、字母等）。

• 可变的文本，大小N意味着属性必须能够容纳最大长度为N的任何可变长度的字符串。如果属性存储为固定长度字符串，并且它所包含的字符串少于N个字符，则必须用空格填充。

• 固定的文本，大小N意味着属性必须能够容纳一个固定长度为N的字符串。

• 数据和时间表示一个包含时间成分的数据值的数据类型。能够存储的时间要精确到秒。

• 数字(m [,n])表示一个无符号数值，至少有m个小数位数，其中n位在小数点的右边（后面）。这个属性必须能保存所有可能的值。

• 有符号的数字(m [,n])能表示正值和负值。

• null意味着一个属性的可用值超出范围。

• Comment 1：对于每个表，可以使用测试系统任意可用物理表示以任意顺序实现下列属性。

• Comment 2： 表和属性名称只是用来说明目的，实现也许会使用不同的名称。

• Comment 3： 在定义数字数据类型的任何地方，都可以使用带符号的数字数据类型（由发起人自行决定）。

仓库表布局(WAREHOUSE Table Layout)

区域表布局(DISTRICT Table Layout)

顾客表布局(CUSTOMER Table Layout)

历史记录表布局(HISTORY Table Layout)

• Comment：在测试基准的内容中，历史记录表中的行是没有主键的，这个表不需要定义一个唯一的行。
• 说明： TPC-C应用程序不一定能够利用超过6000的C_ID值的增加范围。

新订单表布局(NEW-ORDER Table Layout)

订单表布局(ORDER Table Layout)

订单行表布局(ORDER-LINE Table Layout)

条目表布局(ITEM Table Layout)

库存表布局(STOCK Table Layout)

1.4 实现规则

• 1.4.1 数据库中记录的物理簇是被允许的。
• 1.4.2 表示避免逻辑读/写的行的视图被排除。
• 1.4.3 所有表必须具有由数据库数量要求定义的适当缩放的行数。
• 1.4.4 允许表的水平分区。一个表的行组可能被分配到不同的文件，磁盘或区域。实现的时候，需要隐藏分区的细节。
• 1.4.5 允许表的垂直分区。一个表的属性（列）组可能被分配到不同的文件，磁盘或区域。
• 1.4.6 所有的表都允许存在副本。副本必须满足原子性、一致性和隔离性。当只有一个副本的时候需要满足持久性。
• 1.4.7 属性可能会从一个表加到或复制到另一个表，虽然这些改变不会提升性能。
• 1.4.8 如第1.3.1所述，每个属性必须在逻辑上是离散的，并且可以由数据管理器独立地访问。
• 1.4.9 如1.3.1所述，每个属性作为一个单独的属性对于数据管理器必须是可理解的。
• 1.4.10 每个表的主键不能直接表示该行的物理磁盘地址或其任何偏移量。
• 1.4.11 虽然并不是对所有表都执行插入和删除操作，但不能将系统配置为在测试过程中特别利用这一事实。

2.事务和终端配置文件

2.4 新订单事务(The New-Order Transaction)

新订单商业交易包括通过单个数据库事务输入完整的订单组成。它代表了一个中等权重的读写事务，具有高执行频率和严格的响应时间要求，以满足在线用户的需求。此事务是工作负载的主干。它被设计为在系统上施加可变负载，以反映生产环境中常见的在线数据库活动。

2.4.1 输入数据的产生

• 2.4.1.1 对于任意给定的终端，在整个测试期间主仓库的编号（W_ID）是不变的。（条款5.5）

• 2.4.1.2 区域编号（D_ID）是在主仓库编号（D_W_ID = W_ID）[1…10]内随机选择的。

• 2.4.1.3 订单数目（ol_cnt）是从[5…15]随机选择的（平均是10）。

• 2.4.1.4 新订单事务会随机选择1%的事务出现错误并回滚。实现需要在[1…100]产生一个随机数rbk。

• 2.4.1.5 对于订单中的每一个ol_cnt:

1. 一个非统一的随机数（OL_I_ID）使用NURand(8191,1,100000)函数产生。

2. 正在供应的仓库编号(OL_SUPPLY_W_ID)99%的时间是本地仓库，1%的时间是远程仓库。实现过程会产生一个[1…100]的随机数x。
   如果x>1，就是本地仓库，OL_SUPPLY_W_ID = W_ID。
   如果x=1，就是远程仓库，OL_SUPPLY_W_ID是除了W_ID之外其他活跃的仓库内随机选择一个。

3. 数量(OL_QUANTITY)在[1…10]随机选择。

• 2.4.1.6 订单确认时间（O_ENTRY_D）使用系统时间。
• 2.4.1.7 本地仓库供应的订单称为home，即OL_SUPPLY_W_ID = O_W_ID。
• 2.4.1.8 远程仓库供应的订单称为remote，即OL_SUPPLY_W_ID 不等于 O_W_ID。

2.4.2 事务配置文件

2.4.2.1 单机数据库事务中通过下列步骤完成一个新订单：

1. 创建一个订单标头，包含：
   通过数据检索选择2行；
   通过数据检索和更新选择2行；
   2行插入。
2. 订单有可变的项目数（平均ol_cnt = 10），包含：
   通过数据检索选择(1ol_cnt)行；
   通过数据检索和更新选择(1ol_cnt)行；
   (1*ol_cnt)行插入。

2.5 支付事务

支付事务会更新顾客的余额并且会反映在区域和仓库的销售统计上。它代表了一个轻量级的读写事务，具有高执行频率和严格的响应时间要求，以满足在线用户的需求。另外，这个事务包含对顾客表非主键访问。

2.5.1 输入数据的产生

• 2.5.1.1 对于给定的终端，本地仓库编号(W_ID)在整个检索测试期间都是不变的。
• 2.5.1.2 区域编号(D_ID)是从本地仓库(D_W_ID=W_ID)在[1…10]内随机选择的。顾客是随机选择，60%的情况下是姓名(C_W_ID,C_D_ID,C_LAST),40%的情况是编号(C_W_ID,C_D_ID,C_ID)。独立于选择的方式，顾客选中的仓库85%时间是本地仓库，15%是随机选择的远程仓库。通过两个在[1…100]产生两个随机数x和y来实现。
• 2.5.1.3 付款金额(H_AMOUNT)在[1.00…5000.00]随机选择。
• 2.5.1.4 付款时间(H_DATE)通过使用系统时间产生。
• 2.5.1.5 如果在支付确认后顾客属于这个仓库，那这个支付事务就被称为本地的。(C_W_ID = W_ID)
• 2.5.1.6 否则就是远程的。即(C_W_ID 不等于 W_ID)

2.5.2 事务配置文件

• 2.5.2.1 支付事务在单机数据库事务下确认一个顾客的支付包含以下情况：

1. Case 1. 基于顾客编号选择顾客：
   通过数据检索和更新选择3行；
   1行插入。
2. Case 2. 基于顾客姓名选择顾客：
   通过数据检索选择两行（平均）；
   通过数据检索和更新选择3行；
   1行插入。

2.6 订单状态事务

订单状态事务会查询一个顾客最新订单的状态。它表示一个轻量的只读数据库事务，具有较低的执行频率和较低的响应时间要求来满足在线用户。另外，这个表包含对顾客表的非主键访问。

2.6.1 输入数据的产生

• 2.6.1.1 对于给定的终端，本地仓库编号(W_ID)在整个测试期间是不变的。
• 2.6.1.2 区域编号（D_ID）从本地仓库在[1…10]内随机选择。顾客从选择的区域(C_D_ID = D_ID)和本地仓库(C_W_ID = W_ID)在60%的时间通过姓名和40%的时间通过编号随机选择产生。

2.6.2 事务配置文件

• 2.6.2.1 在单机数据库事务中通过下列步骤完成一个订单状态的查询：

1. 找到顾客和他的最新订单，包含：
   Case 1，基于顾客编号选择的顾客：
   通过数据检索选择2行。
   Case 2，基于顾客姓名选择的顾客：
   通过数据检索选择4行（平均）。
2. 检查这个订单（平均items-per-order = 10）每个数据项的状态（发货数据），包含：
   通过数据检索选择（1*items-per-order）行。

2.7 发货事务

发货事务由处理一批10个新订单（还未发货）组成。每个订单完全是在一个读写数据库事务范围内被处理（发送）。一组订单的发送在同一个数据库事务中被具体实现。这个商业事务由一个或者多个(最多10个)数据库事务组成,具有较低的执行频率和在一个宽松的响应时间要求内必须完成。
发货事务是通过队列机制在延迟模式下(deferred mode)执行的，而不是交叉的方式。延迟执行的结果也会记录在一个结果文件中。

2.7.1 输入数据的产生

• 2.7.1.1 对于给定的终端，本地仓库编号(W_ID)在整个测试期间不变。
• 2.7.1.2 运输编号(O_CARRIER_ID)在[1…10]内随机产生。
• 2.7.1.3发货时间(OL_DELIVERY_D)由系统时间生成。

2.7.2 延迟执行(Deferred Execution)

• 2.7.2.1 与测试基准中其他事务不同的是，发货事务必须的延迟模式下执行。这个执行模式的主要特点是通过对事务进行排队来实现延迟执行，然后把完成的事务独立地返回给控制终端，并在结果文件中记录执行信息。
• 2.7.2.2 发货事务的延迟执行必须依附于下列规则：

1. 商业事务作为确认最新输入的结果的延迟执行是排队的。
2. 商业事务的延迟执行必须遵守在2.7.4中定义的配置文件和2.7.1中定义的输入数据。
3. 至少90%的商业事务必须在它们称为队列的80秒内执行完成。
4. 商业事务完成后，下列信息必须记录在结果文件中：

• 商业事务完成排队时的时间。
• 和商业事务有关联的仓库编号(W_ID)和运输编号(O_CARRIER_ID)。
• 被商业事务发送的每个订单的区域编号(D_ID)和订单编号(O_ID)。
• 商业事务完成时的时间。

2.7.4 事务配置文件

• 2.7.4.1 发货事务的延迟执行使用一个或者多个(最多10个)数据库事务发送被选中仓库中10个区域的每一个中未完成的订单(平均items-per-order = 10)。通过以下步骤完成一个订单的发送：

1. 处理订单，包含：
   通过数据检索选择1行；
   通过数据检索和更新选择(1+items-per-order)行。
2. 更新顾客的余额，包含：
   通过数据更新选择1行。
3. 从新订单中移除这个订单，包含：
   删除1行。

2.8 库存查询事务

库存查询事务查明库存低于指定数量的最近售卖的商品数目。它表示一个只读频繁的数据库事务具有较低的执行频率，宽松的响应时间要求和宽松的一致性要求。

2.8.1 输入数据的产生

• 2.8.1.1 每个终端必须使用一个独一无二的(W_ID,D_ID)值并且在整个测试期间保持不变，例如D_ID在一个仓库中不能重复使用。
• 2.8.1.2 库存的最小阈值在[10…20]中随机选择。

2.8.2 事务配置文件

• 2.8.2.1 检查最新的20个订单的库存水平通过以下步骤由一个或多个数据库事务完成：

1. 检查下一个可用的订单数目，包含：
   通过数据检索选择1行。
2. 检查这个区域最新的20个订单(平均items-per-order = 10)的所有项，包含：

通过数据检索选择(20items-per-order)行。
3. 对于所选的每个不同的项目，检查主仓库的可用库存水平是否低于阈值，包括：
通过数据检索选择最多(20items-per-order)行。