OceanBase如何获得TPC-C测试第1名？
|
平滑 TPC-C测试很大的挑战在于在整个压测过程中性能曲线要求是绝对平滑的，曲线上的波动幅度不能超过2%，这对于传统数据库来说都是一件困难的事情，因为这要求对于所有后台任务的精细控制，不能由于某个后台任务的资源过度使用导致前台请求的阻塞积压。而对于OceanBase而言，事情变得更为困难，因为OceanBase的存储引擎是基于LSM Tree的，在LSM Tree要定期执行compaction操作。Compaction是个非常重的后台操作，会占用大量CPU和磁盘IO资源，这对前台的用户查询和写入天然就会造成影响。我们做了一些优化，来平滑后台任务对性能的影响，从最终的测试结果来看，性能曲线在整个8小时压测过程中的抖动小于0.5%。 分层转储 在LSMTree中，数据首先被写入内存中的MemTable，在一定时候为了释放内存，MemTable中的数据需要与磁盘中的SSTable进行合并，这个过程被称为compaction。在很多基于LSM Tree的存储系统中，为了解决写入的性能问题，通常会将SSTable分为多层，当一层的SSTable个数或者大小达到某个阈值时，合并入下一层SSTable。多层SSTable解决了写入的问题，但是SSTable的个数过多，会极大拖慢查询的性能。OceanBase同样借鉴了分层的思路，但同时使用了更加灵活的compaction策略，确保SSTable总数不会太多，从而在读取和写入性能之间做了更好的平衡。 资源隔离 Compaction等后台任务需要消耗大量的服务器资源，为了减少后台任务对用户查询和写入的影响，我们在CPU、内存、磁盘IO和网络IO四个方面对前后台任务做了资源隔离。在CPU方面，我们将后台任务和用户请求分为不同的线程池，并按照CPU亲和性做了隔离。在内存方面，对前后台请求做了不同的内存管理。在磁盘IO方面，我们控制后台任务IO请求的IOPS，使用deadline算法进行流控。在网络IO方面，我们将后台任务RPC和用户请求RPC分为不同队列，并对后台任务RPC的带宽使用进行流控。 存储CPU占用 TPC-C基准测试主要考察整体性能tpmC，很多人也会关注单核的tpmC。然而，这个指标只有在相同架构下才有意义。对于存储模块的CPU占用，有如下三点： 1. 对于集中式架构，除了数据库使用CPU之外，专用存储设备也需要使用CPU。例如，第二名Oracle 3000多万tpmC的测试中，数据库使用了108颗T3SPARC处理器，共有1728个物理核心和13824个执行线程，同时存储设备使用的是Intel服务器作为机头，总共使用了97台服务器，194颗Intel X5670 CPU，2328个物理核心。 2. 集中式数据库使用高可靠硬件，只需要存储一个副本，而OceanBase通过软件层面容错，虽然硬件成本更低但需要两个数据副本和三个日志副本，维护多个副本需要耗费大量CPU; 3. OceanBase在TPC-C测试和生产系统中都打开了在线压缩，进一步增加了CPU使用; 因此，简单地对比OceanBase和Oracle的CPU核是不科学的，还需要算上共享存储设备的CPU核，以及OceanBase存储多副本和在线压缩带来的CPU开销。TPC-C推荐的方案是不关注具体的软件架构和硬件架构，关注硬件总体成本。在OceanBase的测试中，硬件成本只占整体成本的18%左右，只考虑硬件的性价比大幅优于集中式数据库。 后续发展 OceanBase的优势在于采用分布式架构，硬件成本更低，可用性更好且能够做到线性扩展，但是，OceanBase单机的性能离Oracle、DB2还有不小的差距，后续需要重点优化单机存储性能。另外，OceanBase的定位是在同一套引擎同时支持OLTP业务和OLAP业务，而目前OceanBase的OLAP处理能力还不如Oracle，后续需要加强存储模块对大查询的处理能力，支持将OLAP算子下压到存储层甚至在压缩后的数据上直接做OLAP计算。 作者：阳振坤(OceanBase创始人)曹晖(OceanBase技术专家)陈萌萌(OceanBase资深技术专家)潘毅(OceanBase资深技术专家)韩富晟(OceanBase资深技术专家)赵裕众(OceanBase高级技术专家) 【编辑推荐】
【责任编辑：武晓燕 TEL：（010）68476606】 点赞 0 （编辑：常州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
