仁济医院,我不是精英,沙海-弄他交友平台,付出一颗真心,得到真诚的爱

蚂蚁金服自研数据库 OceanBase 登顶 TPC-C 引起业界广泛重视,为了更清楚的展现其间的技能细节,咱们特意约请 OceanBase 中心研制人员对本次测验进行技能解读,共包含五篇:

1)TPC-C基准测验介绍

2)OceanBase怎么做TPC-C测验

3)TPC-C基准测验之SQL优化

4)TPC-C基准测验之数据库业务引擎的应战

5)TPC-C基准测验之存储优化

本文为第三篇,其它文章已同步发布,概况请在“蚂蚁金服科技”大众号检查。

TPC-C 是一个十分苛刻的基准测验模型,检测的是一个齐备的联系数据库体系全链路的才干。这也是为什么在 TPC-C 的榜单前列,呈现的永久仅仅咱们熟知的那几家在业界有着几十年堆集、从联系数据库理论开端开展就差不多同步呈现的数据库公司。接下来咱们经过这篇文章为您剖析在 TPC-C 测验中 OceanBase 数据库的 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 的履行或许仅仅做一个字段的更新,所需求的履行时刻是十分时刻短的,从整个链路的视点来看,许多的时刻会花费在与客户端的交互进程中,形成资源的糟蹋和耗时的添加。那么怎么处理这个问题的呢?答案便是运用存储进程。

存储进程

所谓“存储进程”便是数据库为用户供给的一种面向进程的编程言语。根据这种言语,用户能够将运用程序的逻辑封装为一个可调用的进程(procedure)存放在数据库中并随时进行调用。经过这种方法,用户能够将原本需求与数据库进行屡次交互才干完结的作业经过一次交互完结,省去了中心网络的传输和等候时刻(参见图1)。假设一条业务的网络开支均匀是 30%,也便是说 30% 的 CPU 都花在了网络的收发和解析上。那么在 6 千万规划 tpmC 测验中节省下来 30% 的 CPU 资源换算成体系处理才干是惊人的。运用存储进程还能够带来业务呼应时刻的下降,导致数据库内核中业务锁的临界区缩短,直接的提高了体系 CPU 运用率,整个吞吐量也随之进步。存储进程在缩短运用端的等候耗时上相同有很大作用。

图1 传统的 C/S 模型与运用存储进程的履行方法比照

在 TPC-C 中,存储进程关于整个体系的履行功率提高是至关重要的。OceanBase 2.2 版别不只全面支撑了存储进程,而且对存储进程的履行功率做了许多极致的优化。

编译履行

存储进程作为一种面向进程的高档言语,需求转换成机器码才干够履行。这个进程一般能够分为“编译履行”和“解说履行”两种,一般来说,编译履行比较解说履行有代码优化充沛、履行功率高级特色。OceanBase 运用近两年逐步老练的 LLVM 编译器结构完成了一个支撑存储进程的编译器,经过动态编译(Just-in-Time Compilation)的方法将存储进程翻译成高效的二进制可履行代码,在履行功率上取得了数量级的提高。一起,进程中 LLVM 结构将存储进程转换为与机器无关的中心代码,使得存储进程也自然而然地取得了跨渠道的编译履行才干,LLVM 内置的优化进程保证咱们在各种不同的硬件渠道上都能够取得正确、高效的可履行代码。

Array Binding

别的一个在 TPC-C 测验中发挥了重要作用的功用便是对 DML 句子进行批量处理的才干,在 Oracle 中该功用也称为“Array Binding”。一条 SQL 在数据库中的履行进程大致上能够分为“方案生成”和“履行”两个阶段。虽然咱们对 SQL 的履行方案做了高速缓存,但找到一个适宜的履行方案在整个履行进程中仍然是比较耗时的一个部分。那有没有办法省去这个时刻呢?当一组 SQL 的履行方案彻底相同而只要履行参数不一起,在存储进程中咱们能够经过特定的语法将他们的履行做成一个批量处理的进程,此刻“方案生成”只需求做一次即可,这便是所谓的“Array Binding”。

在 Array Binding 中,数据库会首先找到需求运用的方案,然后履行该方案,并在每次履行结束后,从头履行参数绑定(binding)的进程。打个比方,这就像是在一个 C 言语的 for 循环中,重复赋值而不是从头界说一个数据结构。Array Binding 的运用受用户操控,需求在存储进程中运用 FORALL 要害字来触发这一功用,在 TPC-C 的测验进程中,咱们屡次运用了 Array Binding 来提高体系的处理才干,作用十分显着。

Prepared Statement 与履行方案缓存

Prepared Statement 是一种二进制的恳求交互协议,能够大大下降体系的交互本钱。OceanBase 不只支撑用户程序与数据库间运用 Prepared Statement, 也支撑在存储进程引擎调用 SQL 引擎履行时运用这种交互方法。存储进程在对 SQL 进行一次 Prepare 操作并获取仅有 id 后, 后续的每次履行仅需求传入该 id 和对应的参数,体系能够经过高速缓存找到对应的存储进程或 SQL 方案开端履行。该进程比较运用 SQL 文本的交互方法,省去了许多恳求文本解析的 CPU 开支。

OceanBase 内部完成了高速缓存来缓存存储进程的可履行代码及 SQL 履行方案, 不同参数的存储进程和 SQL 能够经过这一高速缓存快速获取需求的履行方针, 耗时一般在几十微秒以内, 有用避免了从头编译带来的毫秒级的推迟和 CPU 耗费。

可更新视图

在 OLTP 场景中,经过削减运用与数据库的交互次数来完成功用提高的比方许多,可更新视图便是其间之一。咱们常见的数据库视图通常是只读的,经过界说视图,用户能够界说自己感兴趣的数据以及其获取接口,但视图一起也能够作为更新操作的进口,比方在 TPC-C 的 new order 创建场景中,运用需求得到产品信息,更新库存并得到更新后的值。一般能够经过两条 SQL 完成这一进程:

但经过树立一个可更新视图:

咱们就能够经过一条句子更新库存并得到产品和库存信息:

这样就省去了一条句子的交互,而且更新逻辑愈加直观。可更新视图答运用户能够像一般表相同操作视图,但不是一切视图都能够界说为可更新视图。比方带 distinct, group by 的视图,详细更新哪些行语义是不明确的,因而不能答应更新。详细到上面的 stock_item 两表 join 的视图,需求满意所更新表的 unique key 在 join 之后坚持 unique (key-preserved table),即 item.i_id 有必要是仅有的这个条件。

需求着重,TPC-C 标准制止运用物化视图,而可更新视图并没有改动底层数据表格的存储方式,是契合标准的。

总结

由于 TPC-C 的规划原则是尽或许的“实在”反响一个 OLTP 体系的运转场景,咱们所做的许多优化都具有广泛的适用性。例如,关于一个高并发的 OLTP 体系来说,大部分的 SQL 恳求的耗时是十分短的,选用朴实的 C/S 交互模型的成果必定使体系的时刻糟蹋在运用与数据库的频频交互中,而运用存储进程能够大大缓解这种交互的耗时,而且增强体系关于网络颤动的免疫力,这种中心才干关于一个分布式 OLTP 数据库是不可或缺的。

OceanBase 从创建伊始就坚持走自主研制的路途,这个挑选保证了咱们对数据库内核有着彻底的掌控才干,让咱们有在任何场景下寻求极致功用的底气和实力的一起,也对产品形状的开展方向有更明晰的规划和方针。在这次的 TPC-C 测验中,咱们选用了 OceanBase 2.0 版别开端支撑的 Oracle 兼容形式,存储进程和 SQL 悉数运用了兼容 Oracle 的数据类型和语法,这样做也是为了在寻求极致优化的一起,保证产品迭代能够沿着通用和正规的方向开展。从 OceanBase 2.0 版别开端,OceanBase 就不断朝着 Oracle 兼容这个大的方针行进,跟着 2.2 版别支撑的存储进程(PL/SQL)功用的完善,咱们的产品功用也完结了一轮新的迭代。咱们深信这次的 TPC-C 测验成果不只仅见证了 OceanBase 的极致功用,也将成为 OceanBase 数据库走向老练产品的一个新起点。

作者介绍

陈萌萌,现任蚂蚁金服 OceanBase 团队资深技能专家,担任 OceanBase SQL 方向的研制作业。2006 年结业于清华大学,2006 年到 2008 年在欧洲核子研讨中心(CERN)担任网格核算调度器的开发作业,2009 年在美国威斯康星大学麦迪逊分校取得核算机硕士学位,先后在 Oracle、华为美国研讨所从事数据库的开发和研讨。

潘毅,现任蚂蚁金服 OceanBase 团队资深技能专家,担任 OceanBase 的并行查询和新一代 OLAP 引擎。曾上任于美国 Oracle 公司,担任 Oracle 数据库并行查询研制作业并有多项专利申请。

>>>>

欢迎检查以下 OceanBase 创始人阳振坤采访视频,了解国产自研分布式数据库这十年的进程: