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 天增量存储。
性能压测
- Ramp-up，预热达到稳定
- Steady state，报告tpmC的值稳定运行8小时以上，每隔半小时需要完成一次 checkpoint。
- 采集阶段保持2小时，tpmC波动不超过2%。必须完成至少4次checkpoing。
- 整个性能测试前后，审计员还需要进行数据及事务随机分布检查，简单说来就是大量全表扫描和统计 sql，最大的一条 sql 需要访问超过万亿行的 order_line 表结果。
oceanbase ACID测试
- A测试，通过提交和回滚 payment 事务来确认数据库对原子性支持。分布式和本地事务各测一遍。
- C测试，标准里的 C 测试一共包含 12 个 case，前四个是必须要完成验证的
- I测试，简单说来就是大量全表扫描和统计 sql，最大的一条 sql 需要访问超过万亿行的 order_line 表结果。OceanBase 在 2.x 版本中提供了全局时间戳的支持。
- D测试，OceanBase 每个 Warehouse 数据有两份数据三份日志，通过 paxos 强同步。
SQL优化
- 使用存储过程减少网络开销
- llvm编译执行，将存储过程翻译成高效的二进制可执行代码，执行效率上获得了数量级的提升。
- Array Binding 通过参数绑定复用执行计划
- Prepared Statement ,prepare只后，传入id和参数，省去了解析文本。
- 高速缓存来缓存存储过程的可执行代码及 SQL 执行计划。
- 可更新视图。通过减少应用与数据库的交互次数。标准禁止使用物化视图。
事务引擎
- paxos 算法同步 redo log ，保证持久性和数据库服务可用性。
- 两阶段提交协议来保证原子性。
- 多版本并发控制保证事务的隔离性。有一个全局时间戳生成器。
- 复制表（ITEM）解决单点瓶颈。OceanBase 使用特殊的广播协议保证复制表的所有副本的 ACID 特性。
存储优化
oceanbase 存储特点
- OceanBase 存储了两个数据副本和三个日志副本。
- OceanBase 采用在线压缩的方式缓解存储容量瓶颈，进一步增加了 CPU 使用。
- 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 测试过程中的数据库持续服务能力