蚂蚁金服OceanBase挑战TPCC | TPC-C基准测试之存储优化

本文涉及的产品
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
日志服务 SLS,月写入数据量 50GB 1个月
简介: OceanBase的TPC-C测试技术解读第五篇

蚂蚁金服自研数据库 OceanBase 登顶 TPC-C 引起业内广泛关注,为了更清楚的展示其中的技术细节,我们特意邀请 OceanBase 核心研发人员对本次测试进行技术解读,共包括五篇:

1)TPC-C基准测试介绍
2)OceanBase如何做TPC-C测试
3)TPC-C基准测试之SQL优化
4)TPC-C基准测试之数据库事务引擎的挑战
5)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。

在线压缩

在 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 占用,有如下三点:

  1. 对于集中式架构,除了数据库使用 CPU 之外,专用存储设备也需要使用 CPU。例如,第二名 Oracle 3000多万 tpmC 的测试中,数据库使用了 108 颗 T3 SPARC 处理器,共有 1728 个物理核心和 13824 个执行线程,同时存储设备使用的是 Intel 服务器作为机头,总共使用了 97 台服务器,97 颗 Intel X5670 CPU,583 个物理核心;
  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 团队高级技术专家,2010 年加入支付宝后从事分布式事务框架的研发,2013 年加入 OceanBase 团队,目前负责存储引擎相关的研发工作。

相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
3天前
|
人工智能 前端开发 测试技术
探索软件测试中的自动化框架选择与优化策略####
本文深入剖析了当前主流的自动化测试框架,通过对比分析各自的优势、局限性及适用场景,为读者提供了一套系统性的选择与优化指南。文章首先概述了自动化测试的重要性及其在软件开发生命周期中的位置,接着逐一探讨了Selenium、Appium、Cypress等热门框架的特点,并通过实际案例展示了如何根据项目需求灵活选用与配置框架,以提升测试效率和质量。最后,文章还分享了若干最佳实践和未来趋势预测,旨在帮助测试工程师更好地应对复杂多变的测试环境。 ####
14 4
|
8天前
|
机器学习/深度学习 前端开发 测试技术
探索软件测试中的自动化测试框架选择与优化策略####
本文深入探讨了在当前软件开发生命周期中,自动化测试框架的选择对于提升测试效率、保障产品质量的重要性。通过分析市场上主流的自动化测试工具,如Selenium、Appium、Jest等,结合具体项目需求,提出了一套系统化的选型与优化策略。文章首先概述了自动化测试的基本原理及其在现代软件开发中的角色变迁,随后详细对比了各主流框架的功能特点、适用场景及优缺点,最后基于实际案例,阐述了如何根据项目特性量身定制自动化测试解决方案,并给出了持续集成/持续部署(CI/CD)环境下的最佳实践建议。 --- ####
|
1月前
|
运维
【运维基础知识】用dos批处理批量替换文件中的某个字符串(本地单元测试通过,部分功能有待优化,欢迎指正)
该脚本用于将C盘test目录下所有以t开头的txt文件中的字符串“123”批量替换为“abc”。通过创建批处理文件并运行,可实现自动化文本替换,适合初学者学习批处理脚本的基础操作与逻辑控制。
134 56
|
8天前
|
缓存 监控 测试技术
全网最全压测指南!教你如何测试和优化系统极限性能
大家好,我是小米。本文将介绍如何在实际项目中进行性能压测和优化,包括单台服务器和集群压测、使用JMeter、监控CPU和内存使用率、优化Tomcat和数据库配置等方面的内容,帮助你在高并发场景下提升系统性能。希望这些实战经验能助你一臂之力!
22 3
|
3月前
|
存储 SQL 分布式数据库
OceanBase 入门:分布式数据库的基础概念
【8月更文第31天】在当今的大数据时代,随着业务规模的不断扩大,传统的单机数据库已经难以满足高并发、大数据量的应用需求。分布式数据库应运而生,成为解决这一问题的有效方案之一。本文将介绍一款由阿里巴巴集团自主研发的分布式数据库——OceanBase,并通过一些基础概念和实际代码示例来帮助读者理解其工作原理。
309 0
|
1月前
|
SQL 存储 人工智能
OceanBase CTO杨传辉谈AI时代下数据库技术的创新演进路径!
在「DATA+AI」见解论坛上,OceanBase CTO杨传辉先生分享了AI与数据库技术融合的最新进展。他探讨了AI如何助力数据库技术演进,并介绍了OceanBase一体化数据库的创新。OceanBase通过单机分布式一体化架构,实现了从小规模到大规模的无缝扩展,具备高可用性和高效的数据处理能力。此外,OceanBase还实现了交易处理、分析和AI的一体化,大幅提升了系统的灵活性和性能。杨传辉强调,OceanBase的目标是成为一套能满足80%工作负载需求的系统,推动AI技术在各行各业的广泛应用。关注我们,深入了解AI与大数据的未来!
|
3月前
|
Oracle 架构师 分布式数据库
OceanBase数据库的发展历程是什么?
【8月更文挑战第11天】OceanBase数据库的发展历程是什么?
176 63
|
3月前
|
Oracle 关系型数据库 MySQL
OceanBase数据库简介
【8月更文挑战第9天】OceanBase数据库简介
360 60
|
3月前
|
Oracle 关系型数据库 MySQL
OceanBase 与传统数据库的对比
【8月更文第31天】随着云计算和大数据技术的发展,分布式数据库因其高扩展性、高可用性和高性能而逐渐成为企业和开发者关注的焦点。在众多分布式数据库解决方案中,OceanBase作为一个由阿里巴巴集团自主研发的分布式数据库系统,以其独特的架构设计和卓越的性能表现脱颖而出。本文将深入探讨OceanBase与其他常见关系型数据库管理系统(如MySQL、Oracle)之间的关键差异,并通过具体的代码示例来展示这些差异。
250 1
|
3月前
|
关系型数据库 OLAP 分布式数据库
揭秘Polardb与OceanBase:从OLTP到OLAP,你的业务选对数据库了吗?热点技术对比,激发你的选择好奇心!
【8月更文挑战第22天】在数据库领域,阿里巴巴的Polardb与OceanBase各具特色。Polardb采用共享存储架构,分离计算与存储,适配高并发OLTP场景,如电商交易;OceanBase利用灵活的分布式架构,优化数据分布与处理,擅长OLAP分析及大规模数据管理。选择时需考量业务特性——Polardb适合事务密集型应用,而OceanBase则为数据分析提供强大支持。
932 2

热门文章

最新文章