网站建设的五类成员,贵州住房和城乡建设厅旧网站,办公网站建设,网站建设提问蚂蚁金服自研数据库 OceanBase 登顶 TPC-C 引起业内广泛关注#xff0c;为了更清楚的展示其中的技术细节#xff0c;我们特意邀请 OceanBase 核心研发人员对本次测试进行技术解读#xff0c;共包括五篇#xff1a;
1#xff09;TPC-C基准测试介绍 2#xff09;OceanBase…蚂蚁金服自研数据库 OceanBase 登顶 TPC-C 引起业内广泛关注为了更清楚的展示其中的技术细节我们特意邀请 OceanBase 核心研发人员对本次测试进行技术解读共包括五篇
1TPC-C基准测试介绍 2OceanBase如何做TPC-C测试 3TPC-C基准测试之SQL优化 4TPC-C基准测试之数据库事务引擎的挑战 5TPC-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 榜首的数据库在存储架构上有如下关键点
为了保证可靠性OceanBase 存储了两个数据副本和三个日志副本而传统的集中式数据库测试 TPC-C 只存储一份数据由于 OceanBase 存储两个数据副本再加上 OceanBase TPC-C 测试采用了和生产系统完全一样的阿里云服务器 i2 机型SSD 硬盘的存储容量成为瓶颈。OceanBase 采用在线压缩的方式缓解这个问题进一步增加了 CPU 使用相应地集中式数据库测试存储一份数据不需要打开压缩OceanBase LSM 引擎定期需要在后台做 compaction 操作而 TPC-C 要求测试至少运行 8 小时且 2 小时之内抖动小于 2%因此OceanBase 存储需要解决 LSM 引擎后台操作导致的抖动问题
两份数据
为了保证可靠性和不丢数据RPO0有两种不同的方案一种方案是在硬件层面容错另一种方案是在软件层面容错。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。
在线压缩
在 shared nothing 架构下OceanBase 至少需要存储两份数据才可以满足容灾的要求这意味着 OceanBase 需要比传统数据库多耗费一倍的存储空间。为了缓解这个问题OceanBase TPC-C 测试选择对数据进行在线压缩Oracle 数据库中一个 warehouse 的存储容量接近 70MB而 OceanBase 压缩后存储容量只有 50MB 左右大幅降低了存储空间。TPC-C 规范要求磁盘空间能够满足 60 天数据量的存储对于 OceanBase由于需要保存两份数据虽然可靠性更好但需要保存相当于 120 天的数据量这些存储成本都要计入总体价格。OceanBase 使用了 204 台 ECS i2 云服务器存储数据服务器规格和线上真实业务应用保持一致。每台服务器的日志盘 1TB数据盘接近 13TB。计算两份压缩后的数据 60 天的存储空间之后服务器的数据盘基本没有太多余量,从服务器的资源成本消耗来看已经达到了比较好的平衡。如果 OceanBase 的单机性能 tpmC 进一步提升磁盘容量将成为瓶颈。OceanBase LSM 引擎是 append-only 的它的优势是没有随机修改能够在线压缩。无论是 TPC-C 测试还是最核心的 OLTP 生产系统例如支付宝交易支付OceanBase 都会打开在线压缩通过 CPU 换存储空间。
存储性能平滑
TPC-C 测试很大的挑战在于在整个压测过程中性能曲线要求是绝对平滑的曲线上的波动幅度不能超过 2%这对于传统数据库来说都是一件困难的事情因为这要求对于所有后台任务的精细控制不能由于某个后台任务的资源过度使用导致前台请求的阻塞积压。而对于 OceanBase 而言事情变得更为困难因为 OceanBase 的存储引擎是基于 LSM Tree 的在 LSM Tree 要定期执行 compaction 操作。Compaction 是个非常重的后台操作会占用大量 CPU 和磁盘 IO 资源这对前台的用户查询和写入天然就会造成影响。我们做了一些优化来平滑后台任务对性能的影响从最终的测试结果来看性能曲线在整个 8 小时压测过程中的抖动小于 0.5%。
分层转储
在 LSM Tree 中数据首先被写入内存中的 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 占用有如下三点
对于集中式架构除了数据库使用 CPU 之外专用存储设备也需要使用 CPU。例如第二名 Oracle 3000多万 tpmC 的测试中数据库使用了 108 颗 T3 SPARC 处理器共有 1728 个物理核心和 13824 个执行线程同时存储设备使用的是 Intel 服务器作为机头总共使用了 97 台服务器194 颗 Intel X5670 CPU2328 个物理核心集中式数据库使用高可靠硬件只需要存储一个副本而 OceanBase 通过软件层面容错虽然硬件成本更低但需要两个数据副本和三个日志副本维护多个副本需要耗费大量 CPUOceanBase 在 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计算。
原文链接 本文为云栖社区原创内容未经允许不得转载。
