OceanBase如何获得TPC-C测试第1名？

3. I测试，标准要求TPC-C模型里5个事务除了StockLevel事务都需要满足最高的可串行化隔离级别，并构造了9个case来验证隔离性。对于分布式数据库而言，这个要求并没有那么容易实现，所幸OceanBase在2.x版本中提供了全局时间戳的支持，所以的I测试都在审计员的特别要求下跑完了全本地和全分布式两种模式的两轮测试，这也应该是TPC-C测试中首次有数据库厂商需要做两轮I测试跑18个case的，也许在不久后TPC-C标准定义也会因为OceanBase的这次测试而带来针对分布式数据库的相关更新。

4. D测试，OceanBase在这个场景其实相对传统数据库是有较大天生优势的，OceanBase每个Warehouse数据有两份数据三份日志，通过paxos强同步，保证RPO=0的前提下只有秒级RTO。

面对D测试标准中最严格的一项-部分存储介质永久故障，OceanBase还使用了最严苛的测试场景，在使用超出标准要求的全量6000W tpmC压力下，我们强行销毁了一个云服务器节点，整体tpmC在两分钟内恢复到6000w并持续跑到测试时间结束，这些表现都是远远超过TPC-C规范要求的，相比较而言其它传统数据库基本面对有日志的存储介质故障D测试场景都是依赖磁盘RAID来恢复，OceanBase应该算是首个没有raid完全依赖数据库自身恢复机制完成全部D测试的数据库厂商了。

同时我们在D测试中是连续杀掉了两台服务器节点，首先杀掉一个数据节点，等待tpmC恢复且稳定5分钟后，再次杀掉了rootserver leader节点，tpmC仍然快速恢复。

二、TPC-C基准测试之SQL优化

对TPC-C有所了解人都知道，TPC-C是一个典型的OLTP (On-Line Transaction Processing) 场景测试，考察的是数据库在高并发压力场景下的事务处理能力，最终的性能指标以tpmC(transaction per minute，也即每分钟系统处理TPC-C模型中的new order事务的数量)和平均到每tpmC的系统成本作为衡量标准。在OLTP场景中，每条请求的响应时间都是极短的。因此，各个数据库厂商在进行TPC-C测试时，都会尽一切可能将每一个操作时间压缩到最短，不夸张的说，在TPC-C的测试中，一些关键操作的优化往往需要细化到CPU指令级。

在进入我们的主题前，我们先来谈谈TPC-C中的事务模型，主要分为五种事务，订单创建、订单支付、订单查询、订单发货以及库存查询，这五种事务按照一定的比例发生，测试最终衡量的是每分钟订单创建事务的执行个数。大家知道，每一个数据库的事务，其实就是由一定逻辑关系关联的若干条SQL语句组成，他们在一个事务中，要么全部成功，要么全部失败，这个在数据库中称为“原子性”，也就是ACID中的“A”。那么TPC-C中的一个事务的耗时大约是多久呢?看一下报告就很清楚了——只有十几个毫秒。考虑到一个事务由多条SQL构成，那么每一条SQL的平均耗时都不到1毫秒!

在C/S(client-server)模型中，一条SQL语句从发起到执行完成需要经历从客户端输入、网络传输、SQL优化、执行、结果返回到客户端这样一个流程。而具体每一条SQL的执行可能只是做一个字段的更新，所需要的执行时间是非常短暂的，从整个链路的角度来看，大量的时间会花费在与客户端的交互过程中，造成资源的浪费和耗时的增加。那么如何解决这个问题的呢?

答案就是使用存储过程。

（编辑：衢州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!