oceanbase tpcc 关键总结

tpcc 基准测试

简介

TPC-C是TPC组织制定的关于商品销售的订单创建和订单支付等的基准测试标准，是数据库联机交易处理系统（OLTP）的权威基准测试标准。TPC-C有5种事务，每种事务有规定的比例，分别订单支付不低于43%，订单查询、订单发货和库存查询各不低于4%，其余则为订单创建(不高于45%)，tpmC值是订单创建事务每分钟执行的数量。

TPC-C benchmark测试必须通过TPC组织的审计（准确地讲是TPC-C组织认可的审计员的审计），通过审计的TPC-C的结果，其完整详实的测试报告（包括测试厂家、数据库版本、详细的软硬件配置、测试过程等）将公布在TPC组织的网站上。

要求

首先事务符合ACID。

• 隔离级别为可串行化。

• 持久性抵御任何单点故障。

• 对于分布式，订单创建和订单支付 分别有10%和15%的分布式事务。

其次，tpcc规定被测数据库的性能与数据量成正比。

• 每个仓库大约70M

• 每个仓库的tpmC 上限是 12.86。

• 同时要求具备60天，每天压测8小时的存储容量。

第三，要求被测数据库能以平稳的性能长期运行

• 去掉启动预热（ramp up）和结束降速（ramp down）时间后，被测数据库至少要性能平稳地（steady state）运行8小时，

• 其中性能采集时段（不少于2小时）内的性能累积波动不得超过2%

第四，TPC-C要求被测数据库的写事务的结果必须在一定时间内数据落盘（指数据库数据，不是日志）

• TPC-C要求被测数据库的写事务的结果必须在一定时间内数据落盘(不是日志)
• 对于具备checkpoint功能的数据库，checkpoint的间隔不得超过30分钟
• checkpoint数据持久化的时间不得超过checkpoint间隔

OB修改在内存，一天落盘一次。

测试流程

TPC-C 测试首先需要找到官方唯一认证的审计员来对测试进行审计监察。

测试系统

benchmarksql 不符合规范

• benchmarksql 大量的字符串生成未保证全局随机
• 缺乏压测阶段最基本的 think time、keying time 这些基本配置
• 测试工具不应该与DB 直连

标准测试系统

• 在 TPC-C 标准定义中，测试系统分为 RTE（Remote Terminal Emulator）和 SUT 两部分

  RTE（Remote Terminal Emulator）客户终端。事务的触发，RT统计都在这里。

  WAS 和 DB 是必须商业化可购买且提供支付服务的

  RTE 则一般由各个参测厂商自行根据标准实现

  SUT 分为 WAS(web application server)和 DB Server

  WAS 是RTE 和DB server 的桥梁

• 标准规定每个ternimal 都必须保持长连接，(海量的warehouse 是无法承受这么多连接)，标准规定可以使用连接池。

测试规则

硬件选型

不仅要对数据库服务器选型，还需要对 RTE 以及 WAS 服务器选型。

参数选择

跑多少个 Warehouse，每个数据库服务器上承载多少 Warehouse。

单机的存储空间又有预计 80%（经验值）需要预留给 60 天增量存储。

性能压测

1. Ramp-up，预热达到稳定
2. Steady state，报告tpmC的值稳定运行8小时以上，每隔半小时需要完成一次 checkpoint。
3. 采集阶段保持2小时，tpmC波动不超过2%。必须完成至少4次checkpoing。
4. 整个性能测试前后，审计员还需要进行数据及事务随机分布检查，简单说来就是大量全表扫描和统计 sql，最大的一条 sql 需要访问超过万亿行的 order_line 表结果。

oceanbase ACID测试

1. A测试，通过提交和回滚 payment 事务来确认数据库对原子性支持。分布式和本地事务各测一遍。
2. C测试，标准里的 C 测试一共包含 12 个 case，前四个是必须要完成验证的
3. I测试，简单说来就是大量全表扫描和统计 sql，最大的一条 sql 需要访问超过万亿行的 order_line 表结果。OceanBase 在 2.x 版本中提供了全局时间戳的支持。
4. D测试，OceanBase 每个 Warehouse 数据有两份数据三份日志，通过 paxos 强同步。

SQL优化

• 使用存储过程减少网络开销
• llvm编译执行，将存储过程翻译成高效的二进制可执行代码，执行效率上获得了数量级的提升。
• Array Binding 通过参数绑定复用执行计划
• Prepared Statement ,prepare只后，传入id和参数，省去了解析文本。
• 高速缓存来缓存存储过程的可执行代码及 SQL 执行计划。
• 可更新视图。通过减少应用与数据库的交互次数。标准禁止使用物化视图。

事务引擎

• paxos 算法同步 redo log ，保证持久性和数据库服务可用性。
• 两阶段提交协议来保证原子性。
• 多版本并发控制保证事务的隔离性。有一个全局时间戳生成器。
• 复制表（ITEM）解决单点瓶颈。OceanBase 使用特殊的广播协议保证复制表的所有副本的 ACID 特性。

存储优化

oceanbase 存储特点

1. OceanBase 存储了两个数据副本和三个日志副本。
2. OceanBase 采用在线压缩的方式缓解存储容量瓶颈，进一步增加了 CPU 使用。
3. OceanBase LSM 引擎定期需要在后台做 compaction 操作，需要解决性能抖动问题。

• 两份数据
• 在线压缩，cpu 换存储空间。
• 更加灵活的 compaction 策略，减少 compaction性能抖动。
• CPU、内存、磁盘 IO 和网络 IO 四个方面对前后台任务做了资源隔离

链路层优化

WAS请求 OceanBase 采用了 ODBC 接口。

OceanBase 实现了OBProxy 代理服务器来解决数据库链路上的路由及容灾问题。OBProxy 会感知数据副本地址和分区规则，不参与 SQL 引擎参与执行计划的生成调度，主要负责 SQL 路由和转发。

链路层性能优化

• 提供异步接口，减少线程创建。
• PreparedStatement ，OBProxy SQL 引擎会缓存 PS SQL 文本以及解析结果。
• OBProxy 的 SQL 引擎会解析存储过程中的 SQL，计算最优策略，将存储过程调用发往最合适的 OBServer 上执行，尽可能的减少远程执行次数。OBProxy 也会缓存存储过程的解析结果和路由信息，用以省去每次硬解析带来的 CPU 开销。
• 在 OceanBase 原有传输协议上重新做了扩展，使得整个链路支持复杂类型的传输。

代理资源占用

OBProxy 代理采用多线程异步框架和透明流式转发的设计，保证了数据的高性能转发（单核 5 万 QPS、转发 RT 30~50us），以及自身对机器资源的最小消耗。

持续服务能力

OceanBase 针对强制断电这种单机故障场景，OBProxy 有包含黑名单和灰名单两种机制，用于处理 OBServer错峰合并、升级、宕机、启动/停止，网络分区等状态。。黑名单采取定期刷新维护，由 OBServer 反馈哪些服务器节点不能提供服务。灰名单则采取主动触发维护，当 OBProxy 转发请求给 OBServer，如果发现 OBServer 返回特定的系统错误，或者 OBServer 在一段时间内有多次连续不可用，则将该 OBServer 加入灰名单。黑名单中的 OBServer 不会被访问，灰名单中的 OBServer 每隔一段时间会重试一次，检查是否需要洗白，以避免长时间将OBServer 降级。通过 OceanBase 这样的机制，能够保障 TPC-C Durability 测试过程中的数据库持续服务能力

参考

https://www.yuque.com/pockry/dvkxsk/dtk0ig