概要

TPC-C是对OLTP系统进行测试的标准，而HBase作为新型NoSQL数据库，数据以及操作模型都是KeyValue风格的，所以HBase本身并不具备直接使用TPC-C进行测试的条件，比如它没有数据规约、没有二级索引、没有数据类型等。因此，我们针对HBase对TPC-C的一些标准进行了修改，设计并开发了一套HBase风格的TPC-C驱动。

数据规约

由于TPC-C对数据规约并没有太大需求，因此我们忽略了HBase上的数据规约设计，对于一些关联外键，直接使用RowKey进行关联。

数据类型

• 对于字符串型数据，使用Unicode编码后的二进制数据进行存储。
• 对于整型、浮点型以及日期时间型数据，统一采用8字节长整型数进行保存，转换协议采用HBase自带的Bytes工具类。
• 对于RowKey，使用整型ID转化为定长字符串，不足长度在左边补‘0’，具体长度根据库表而定。

库表设计

WAREHOUSE表，RowKey由5个字节组成，由W_ID直接进行赋值，其他字段对应于TPC-C的WAREHOUSE表。

DISTRICT表，RowKey由5个字节的W_ID及2个字节的D_ID拼接组成，其他字段对应于TPC-C的DISTRICT表。

ITEM表，RowKey由5个字节组成，由I_ID直接进行赋值，其他字段对应于TPC-C的ITEM表。

STOCK表，RowKey由5个字节的W_ID以及5个字节的I_ID拼接而成，其他字段对应于TPC-C的STOCK表。

CUSTOMER表，RowKey由5个字节的W_ID、2个字节的D_ID及5个字节的C_ID拼接而成，其他字段对应于TPC-C的CUSTOMER表。

ORDER表，RowKey由5个字节的W_ID、2个字节的D_ID及7个字节的O_ID拼接而成，其他字段对应于TPC-C的ORDER表。

NEW-ORDER表，RowKey由5个字节的W_ID、2个字节的D_ID及7个字节的O_ID拼接而成，其他字段对应于TPC-C的NEW-ORDER表。

ORDER-LINE表，RowKey由5个字节的W_ID、2个字节的D_ID、7个字节的O_ID及2个字节的OL_ID拼接而成，其他字段对应于TPC-C的ORDER-LINE表。

HISTORY表，由于本身无主键，所以设计RowKey由5个字节的W_ID、2个字节的D_ID、5个字节的C_ID和8个字节的时间戳组成，其他字段对应于TPC-C的HISTORY表。

另外，除了TPC-C中的数据表，根据TPC-C几类事务的查询特点，我们还在HBase中增加了两个索引表：

CUSTOMER-INDEX-LAST表，用来对客户的C_LAST建立索引，处理Payment以及OrderStatus事务中以C_LAST作为查询条件的操作，RowKey由5个字节的W_ID、2个字节的D_ID、C_LAST、分隔符以及C_FIRST拼接而成，在进行查询时只需填充好W_ID、D_ID、C_LAST，就可以很自然地利用HBase的数据模型得到按C_FIRST排序的C_ID了。

ORDER-INDEX-CUSTOMER表，用来对客户的C_ID以及O_ID建立倒序索引，处理OrderStatus事务中对用户最近订单的查询。由于HBase不支持对数据的倒序扫描，我们对该表的RowKey进行了这样的处理：5字节W_ID + 2字节D_ID + 5字节C_ID + （O_ID上界99999 – O_ID），这样在扫描时，指定好W_ID、D_ID、C_ID以后，第一条即为用户最近的订单O_ID。当新订单生成时，TPC-C HBase驱动将自动写入一条对应的ORDER-INDEX-CUSTOMER记录。

读写操作的转化

OLTP系统大都使用SQL作为数据存取的接口，对于HBase而言，只要有合适的库表设计，就可以使用Get、Put、Scan以及Delete完成大部分SQL的功能，根据3）中的库表设计，我们已经完全可以使用这些基本操作来处理所有的事务了。