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

OceanBase的全局时间戳生成器也是由多副本组成，可以独立部署在三台机器上，也可以像这次TPC-C评测中一样部署在root node机器上，与root node共享资源。全局时间戳的三副本是一种极高可用的架构，任何一次时间戳的获取操作都至少在三台机器上的两台获得了确认，所以任意一台机器出现故障，获取时间戳的操作不会有一点影响。

按照TPC-C标准，OceanBase准备了9种不同的场景测试有读-读、读-写冲突时事务的隔离性，最终都完美通过了审计员的审计。

一致性保证(Consistency)

在有了上述的事务能力后，OceanBase可以完美的保证各种数据的一致性的约束。TPC-C标准里提出了12种不同的一致性测试场景在各种测试运行前后对数据库内的数据进行一致性校验。因为OceanBase此次测试数据规模庞大，一致性校验的SQL需要核对大量的数据，所以一致性校验的挑战在于校验的SQL本身运行的效率。基于OceanBase的并行查询能力，发挥整个集群所有的计算资源，校验SQL的运行时间均缩短了几个数量级，很好的完成一致性功能的审计工作。

复制表

TPC-C测试模型中有一张商品(ITEM)表，这张表的内容是测试所模拟的销售公司所有售卖的商品信息，包含了商品的名字、价格等信息。“订单创建”事务执行中需要请求这张表内的数据来确定订单的价格信息，如果商品表的数据只存放在一台机器上，那么所有机器上发生的“订单创建”事务都会请求包含商品表的机器，这台机器就会成为瓶颈。OceanBase支持复制表功能，将商品表设置为复制表后，商品表的数据会自动复制到集群中的每一台机器上。

TPC-C标准不限制数据的副本数，但是不管数据的组织形式，标准里要求事务的ACID一定要保证。OceanBase使用特殊的广播协议保证复制表的所有副本的ACID特性，当复制表发生修改时，所有的副本会同时修改。并且，当有机器出现故障时，复制表的逻辑会自动剔除无效的副本，保证数据修改过程中不会因为机器故障出现无谓的等待。复制表在很多业务场景中都有使用，例如很多业务中存储关键信息的字典表，还有金融业务中存储汇率信息的表。

四、TPC-C基准测试之存储优化

TPC-C规范要求被测数据库的性能(tpmC)与数据量成正比。TPC-C的基本数据单元是仓库(warehouse)，每个仓库的数据量通常在70MB左右(与具体实现有关)。TPC-C规定每个仓库所获得的tpmC上限是12.86(假设数据库响应时间为0)。

假设某系统获得150万tpmC，大约对应12万个仓库，按照70MB/仓库计算，数据量约为8.4TB。某些厂商采用修改过的不符合审计要求的TPC-C测试，不限制单个warehouse的tpmC上限，测试几百到几千个warehouse全部装载到内存的性能，这是没有意义的，也不可能通过审计。在真实的TPC-C测试中，存储的消耗占了很大一部分。OceanBase作为第一款基于shared nothing架构登上TPC-C榜首的数据库，同时也作为第一款使用LSM Tree存储引擎架构登上TPC-C榜首的数据库，在存储架构上有如下关键点：

1. 为了保证可靠性，OceanBase存储了两个数据副本和三个日志副本，而传统的集中式数据库测试TPC-C只存储一份数据;

2. 由于OceanBase存储两个数据副本，再加上OceanBase TPC-C测试采用了和生产系统完全一样的阿里云服务器i2机型，SSD硬盘的存储容量成为瓶颈。OceanBase采用在线压缩的方式缓解这个问题，进一步增加了CPU使用;相应地，集中式数据库测试存储一份数据，不需要打开压缩;

3. OceanBase LSM引擎定期需要在后台做compaction操作，而TPC-C要求测试至少运行8小时且2小时之内抖动小于2%，因此，OceanBase存储需要解决LSM引擎后台操作导致的抖动问题

两份数据

为了保证可靠性和不丢数据(RPO=0)，有两种不同的方案：一种方案是在硬件层面容错，另一种方案是在软件层面容错。OceanBase选择在软件层面容错，优势是硬件成本更低，带来的问题是需要冗余存储多个副本的数据。OceanBase使用Paxos协议保证在单机故障下数据的强一致。在Paxos协议中，一份数据需要被同步到多数派(超过一半)，才被认为是写入成功，所以一般来说副本个数总是奇数，出于成本考虑最常见的部署规格是三副本。

三副本带来的首要问题就是存储成本的上升，之前商业数据库的TPC-C测试大多基于磁盘阵列，而TPC-C规范中明确对磁盘阵列不做容灾要求，使用相对于传统数据库三倍的存储空间进行TPC-C测试显然难以接受。

我们注意到这样一个事实，通过Paxos协议同步的只是日志，日志需要写三份，但数据不是，数据只需要有两份就可以完成单机故障的容灾了，当一份数据由于服务器宕机不可用时，另一份数据只要通过日志把数据补齐，就可以继续对外提供访问。

和数据存储相比，日志的存储量比较小。我们将数据与日志分开，定义了三种不同的副本类型：F副本既包含数据又同步日志，并对外提供读写服务;D副本既包含数据又同步日志，但对外不提供读写服务;L副本只同步日志，不存储数据。当F副本出现故障时，D副本可以转换为F副本，补齐数据后对外提供服务。在TPC-C测试中我们使用FDL模式进行部署(一个F副本，一个D副本，一个L副本)，使用了两倍数据副本的存储空间。无论是D副本还是L副本，都需要回放日志，D副本还需要同步数据，这些都是都会消耗网络和CPU。

在线压缩

在sharednothing架构下，OceanBase至少需要存储两份数据才可以满足容灾的要求，这意味着OceanBase需要比传统数据库多耗费一倍的存储空间。

为了缓解这个问题，OceanBaseTPC-C测试选择对数据进行在线压缩，Oracle数据库中一个warehouse的存储容量接近70MB，而OceanBase压缩后存储容量只有50MB左右，大幅降低了存储空间。TPC-C规范要求磁盘空间能够满足60天数据量的存储，对于OceanBase，由于需要保存两份数据，虽然可靠性更好，但需要保存相当于120天的数据量，这些存储成本都要计入总体价格。

（编辑：济南站长网）

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