2012~2013 年,Google 相继发表了 Spanner 和 F1 两套系统的论文,让业界第一次看到了关系模型和 NoSQL 的扩展性一个大规模生产系统上融合的可} } %能性,这种新型的数据库架} M _ t v U构被行业分析师 Matthew Aslett 称为“NewSQL”。

随后的几年里,NewSQL 数据库迎来大爆发,各大云服务厂商都基于 Spannek % – ; m m mr+F1 论文推出各自的 NewSQL 数据库服务,开源领域也涌现出 CockroachDB 和 TiDB 这样的人气项目。

近日,浪潮宣布开源一款 Newc p $ V [ r y h ?SQ4 J aL 分布式数据库 ZNBase,引发了社区开发者的关注。据悉,浪潮的 ZNBase 数据库同样参考自谷歌 Spanner+F1 系统的设计思想,具备强一致、/ 7 1 . # O W = f高可用分布式架构、分布式水平扩展、高性. b Q能、企业级安全等特性。

而作为一款主打 HTAP 混合场景的分布式数据库产品,前有 TiDB 获资本市场青睐并霸榜国产数据库,后有阿里、百度等厂商陆续推出的自家 HTAP 分布式数据库产品,浪潮的 ZNBase 又将凭借哪些优势在国内市场中立足?

什么是 ZNBase ?

据 ZNBase 产品负责人陈磊介绍,ZNBase 是一个 HTAP 分布式数据库,采用云原生分布式A 4 6 a架构,Share Notb K X rhing 所有节点全部对等,每个节点均是完整功P , s z E Q能的数据库节点,每个节点都包括 SQL 层、事务层、副本层和存储层。SQL 层包括协议和语法解析、优化器和执行器,事务层主要负责分布式事务,副本层负责副本调度和使用 Raft 算法保证多副本一致性,存储层采用 KV 存储引擎 RocksDB 负责存储数} 9 5 ^ Y l , = _据。

163252_lwf9_4487475.png

ZNBase 首先支持 OLTP 场景,产品完整的支持 SQL 与事务,表数H 6 5据自动的划分多个 Range 分布在不同的数据库节点上。因此使用 ZNBase 数据库再大数据表也不需要人工分库分表,数据库集群会自动处理,应用只需要当作单机库表使用即可。

在 OLAP 场景支持方面,在 SQL 执行方面做很多偏向 OLAP 场景的优化,包括算子并行、异步、矢量计算、RBO优化器等,得益于产品的分布式架构,可以利用多节点的计算能力,产品可y J c 1 T以满足业务应用的 AP 需求。

ZU I $ . \NBase 没有类似 TiDB 包含的集群管理模块(Placement Drf T /iver ,简称 PD),每个节点就是一个完整的数据库,在每个节点里同时包含 AP 和 TP 的能力,可以完成处理 SQL 请求,进行 SQL 计算,以及数据存储引擎的全部工作。再通过这种分布式的架构把每个节| w i . _ {点联系起来,形成 ZNBase 的数据库系统。

取自社区,回馈社区

前文提到,市面上已经有一些比较成熟的分布式数据库解决方案,其中不乏受到资本y ; H追捧的优秀开源项目,那么浪潮的技术团队当初决定要重新3 c . : s做 ZNBase 是出于怎样的考虑呢?

据陈磊回忆,ZNBase 的研发团队最开始是浪潮内部的大数据团队,集团内部不同单位之间有很多交流,他们发现其他的单位有很多的大数据量应用。因为浪潮做信息化比较早,最开始集团内部用的是免费的 MySQL,Oracle. } : P S p p m S 单机版,DB2 单机版等。随着数据不断积累,数据量越来越大,团队开始面临一些新的问题:要不要购买这些数据库的升级版本,或者要不要再升级硬件,但这些都不能解决根本问题,到未9 ! ) ) { . 0 X T来数据量发展到` ` \ c F @ z一定程度时,还是会出现瓶颈。于是浪潮大数据团队O \ n综合多方述求开始探索解决方案。

最初经过调研,团队尝试过使用分布式中间件的方法。但对于其他业务部门来说,他们还是希望解决方案对业务代码C } ^ \ \ M _ U本身没有侵入,并且中间件的维护也过于复杂。因为浪潮的业务更多是面向传统企业客户,这与很多在自己的业务中使用分布式中6 @ f 7 ) n b A间件的互联网公司不同。“我们的业务以响应客户为@ d t & 9 u +优先级,必须为这些客户提供一b ` @ a 8 1套完整且易用的解决方c – | H g \案。”

“后来,我们的团队了解到了谷歌发布的 NewSQL 技术路线,觉得这种n H e ! @ \分布r ^ ? u @ M N P式的关系型数据库还比较适合我们。X u k最初我们是在内部引入 CockroachDB,这是n Q c & \谷歌 NewSQL 产品 Spank I 7 : R x g {ner 的开源版^ E ` w q 0 J J X本。当时 CockroachDB 刚刚发布不久,我们就一直在关注这个项目,也开始给浪潮内部的一些业务应用推荐这个项目。但刚开始用的时候这些业务部门多多少k D o M P S ` :少会遇到一些问题X + ] M L C T,于是我们大数据团Z O X 6 a队就开始给他们做一些技术支持的工作,在这个过程中我们的团队也深入到 Cockroach& 5 1 [ [ ` xDB 社区参与贡献,并为E R 7 0社区提交代码。”陈磊介绍。

而到了 2019 年初,浪潮大数据团队部分已经加入云服务集团团队,面临各项业务上云的工作。这时云服务团队就希望他们把基于 CockroachDB 的分布式数据A 2 P J *库也上云。而此时正好赶上了 CockroachDB 官方h g o 0 9为了限制 AWS 等云厂商修改了项目的 License,不能把 CockroachDB 当做云服务提供。

“虽然我们能够理解 CockroachDB Labs 的这种做法,但我们也需要维持自己的业务。”于是团队只能基于 CockroachDB 的非商业限制版本重新分支立项,并投入大量人力来维护和开发,也就成了现– { V _ – r I a在的 ZNBase。“当然,我们在这个过程中也收到了很多用户的反馈,也根据这些反馈做了一些工作,包括 SQL 的分析性能增强和E k b / ~ ( K j \各种语法特性优化等。”

因为 ZNBase 整个W l T # ! ` N A F分布式数据库系统最初都是基于开源项目研发,所~ X 5以在开发过程中,浪潮也积Y F $ N极地回馈上游的开源社区。据统计,浪潮的技K ~ y M D 2 0 K Y术团队为 Cockroach DB、RocksDB、kubernetes 等项目社区提交了 commit 80 多个,issue 50 多个,参与代码. / x # N贡献的开发者有 30 余人。

看好 Rust,考虑替换 Go

由于 ZNBase 是基于 CoP _ SckroachDB 而来,所以使用的开发语言也是该项目原本的 Go 语言;存储层则是基于 RocksDB, Q H ` [ + n XT f ! t发,因此使用的也是该项目原本的 C++。

Rust 语言近年来在社区中的声量很高,不少大厂也开始在内部大规模启用 Ru+ V a W M x 4 P Yst 来替换 C++。被问到 ZNBase 是否考虑过在未来将 C++ 替换为 Rust 时,陈磊表示:“Rust 最近确实很火。我个人其实早在 2016 年,也就M 3 B E v 2 E是 Rust 的 1.0 版本还没有正式发布的时候就开始关注5 M G /了,它确实是一门非常有潜力的编程语言,不过我们的工作内容更多的是解决客户的实际问题。但目前也仍然保持对 Rust 的关注。”s P \

陈磊认为,Rust 近年来的火爆,更多的是一些大公司在用w = – I这门语言,比如国外的亚马逊、微软、谷歌,国内的阿j + O ) U里、华为等,首先这些大公司自身的软件规模足够庞大,C/CB T ~ w \ S (++语言在内存管理方面的问题难以解决,他们就可W ? ; / K E /以引入 Rust 来解决这些内存安全的坑。

事实上,ZNBase 作为一款新的产品,在y \ b A! ~ j p e y p择技术路线的时候也确实会需要S u U O e t Z Q考虑这种未来的趋势,但目前 ZNBase 团队还没有考虑到用 Rust 完全去重写原本用 C++ 开发的 RocksDB。“RX R )ocksDB 本身就是一个 C++ 写的东西,除非| W h P ) K \ u我们发现 RocksDB 的哪些特性,或者哪些问题无法满足我们的x ] 3产品需求时,我们才会去尝试改造它。”

值得一提的是,虽然 Zi 9 Q Q $ kNBase 团队暂时不会考虑用 Rust 去替换掉 C++,但出于对性能的考虑,他们可能会用 Rust 将 SQL 层的 Go 语言替换掉。“Rust 确实是一门性能很高的语言,从技术规划的角度来说,后边我们是有计划把 Go 语言替换成 Rust 的,因为 Go 的性能确实没有 C/C++ 和 Rust 高,我们可能会用 Rust 替换x X v n \ M p | J掉 SQL 层和副本层的 G\ 0 ; % G w NO 语言。”陈磊说。D ( \ y i R _ 2

浪潮的硬件优势

浪潮在国内市场以服务器硬件方面的k 1 Z P c p Z ;技术闻名,那么 ZNBase 团队是否在硬件方面做了特别的工作?I ; z i

陈磊透露,在硬件这一块他们确实做了一些工作,比如在硬件存储方面,浪潮开发了一种新型 ZNSSD 存储设备,团队也是第一时间拿到这款设备进行了软硬件结合的适配,包括硬件底层与 ZNBase 的交互优化,RDI e aMA 的软硬件融合等一些开发。另外浪潮本身还有 K1 的主机服务器,这部分目前也l D m ; * H {在与 ZNBase 进行底层的适配,从而提高产品的性能和可用性等。

总的来说,得益于浪潮的硬件优势,在硬件方面的工作 ZNBasw c z @ p / ; W Ee 团队做起来还是比较顺利的,这也是浪潮 ZNBase 相对于其他分布式数据库来说的一个优势。

与 TiDB 等分布式数据2 Q i w h # ( h ?p M Z o S &的区别

提到 HTAP 分布式数据库,我们不得不提近年来在社区中人气火爆的明星项目 TiDB,以及一些同样主打 HTAP 场景融合特性的数据库产品,比如国外的 Greenplum 、阿里云的 HybridDB for_ / m k MySQL、百度的 BaikalDB 等。陈磊认为,与这些数据库相比,ZNBase 的优势主要体现在两个方面^ s G

第一是背景不= @ O f { r n z A同,其他的产品都是大的互联网公司开发的或面向互联T ) J \ h j网应用的。浪潮是大型 Ig L \ V c A Y e sT 企业面向政府大数3 l ~ 4 3 0 T据、大型Y v { O企业应用而产生的。

第二是架构或技术栈有所区l y ` N J I K别。虽然大部分分布式数据库采用 KV 存储,但刚谈到 ZNBase 是 ShareNothing 架构的,TiDB 则是共享存储架构。由此,浪潮 ZNBase 的优势是扩展性更好,部署运维更加容易,为用户提供了可直接启动的二进制包;另外基于浪潮所服务的一些客户的使用习惯,ZNBase 会兼容更多的 Oracle、DB2 等传统商业数据库的函数与语法。

在硬件方面,浪潮的技术团队在国产芯片及操作系统兼容和优化方面做的更多些。浪潮有H N 6自己的分布式I P # . E N h S z存储、操作系统、云平台研发团队,做了很多底层适配与底层优化的工作,E u E [ `这使得 ZNBase 更加稳定可靠。

详细来说,ZNBase 与同样基于 Spanner+F1 设计理念的 TiDB 在 HTAP 架构上还是比较类似的,就是都会提供一个列存的副本,主打的是 OLTP 使用场景,OLAP 的场景应用性能偏轻量级,同时在不断# f c O h 8地增强中。二者的主要区别在于面向的客户群体不同。ZNBase 根据浪潮长期积累的大量政府、金融和传统企业客户的需求,对 Oracle、DB2 等传统商用数据库做了大量的兼容性工作,这对浪潮的客户迁移到 ZNBase 很有帮助+ k D = u :;而 TiDB 可能更多是面向互联网行业的客户,更多地兼容 MySQL 的生态。

而国外比较火的 Greenplum 是主打 OLAP 场i k k景的产品,OLTP 方面在不断增强;HybridDB for MySQL 和 BaikalDB 这两款产品实际上与 Greenplum 类似,他们都是有一个独立的列存引擎,也就是在L t M Y i R a 9 ]表建立之前就已经定义了是列存表还是行存表。而 Zn w H \ 7 7 oNBase 和 TiDB 都是既有行存的数据副本,也有列存的数据副本,这K % E / ( 5 h 1 (个实际上是一个本质的区别。

“所以说目前主C ! t # – = T 5 `流的 HTAP 分布式数据库采用行存和列存副本,对同一份数据采用不同的存储格式,应该是未来的一个方向。”陈磊表示,“不过目前q e . o h [ $ N ?我们暂时没有能提供的具体对比数据,各位技术爱好者如果有兴趣就可以自己拿来进行对比,也可以为我们分享。”

HTAP 大有可为

关于近年来兴起的 HTAP 概念,陈磊d w 9 W结合浪潮客户对数据库产品需求r @ O ]的变迁历史,为我们描述了分布式数据库从 OLTP 场景需求到与 OLAP 场景需求结合的进化过程。

从浪潮一直以来接触的一些客户使用场景来看,目前的传统企业市场需O – X O 7 P _求主要还J h M M 6 ? G n \是以 OLTP 为主。主要体现在这些客户的业务量规模扩大了以后,比如说他们需要增加 10 台服务器,可能同时要维护一个包含上百亿数据量的表,这个时候数据还需要不断往里加。这种场景就是分[ J J g r i布式数据库的 OLTP 部分可以满足他们的需求。

在解决 OLTP 需求的基础上,整个数据库? H @ d Q i w a p系统必然会有一些数据的沉淀,人们就需要从这& K X ? _ = h些数据中挖掘出对自身业务有意义的价值,这就产生了对这些数据进行分析的需求。而分布式数据库承载的数据量通常要比传统数据库大得多,用传统技术. & d J ?进行数据分析就会很痛苦,可能一c v ^ 3 % k 6 ! 8个查询操作就要等上好几天的时间,甚至无法返回结果。“这就是我们还要在解决 OLTP 的基础上增加 OLAP 功能,做成一个融合二者的 HTAP 数据库的原因。”

HTAP 数据库Q t 8将两种需求场景合二为一的愿景固然美好,但在实际x { . $ ? M W k 5的开发过程中,要想实现 HTAP) * Z ( B K 并不容易。陈磊介绍,实现 HTAP 的难点主要有几个方面:

首先需要解决的是数据存储,大家知道列存是可以做这种分析型的运算,研发高性能的列存引擎就是一个难点,当然现在已经有一些优秀的开源列存引擎,开发者可以在此基础上复用。

然后就是行存和+ k z ] 9 m @列存数据的一致性问题。传统的 HTAP 数据库行存与列存是分开的两张表,行列之间不& T 7 W + q需要保持数据一致性p g # U,但是像 ZNBase 以及 TiDB 这种新型的 HTAP 数据库,同h w i . 7 X 7样的数据同时有行存和列存,就需要保证数据的一致性,但解决数据一致性问题也会带来新的* 8 5 n 7问题,比如L 0 \ n _ 1 y影响数据写入的性能,如何去解决数据写入性能问题也是一= k l个难点。

还有的话就是数据同时保存在列存和p + { 0 $ 9 v d行存中,当一个查询命令过来的时候,应该选择哪一个存储引擎来计算?这个时候给数据库系统的 SQL 层、优化器和执行器带来的挑战也会更加大一些。

) ] e 0 } 7 v 2据库与 AI

AI 的高速发展影响着各行各业,如今6 s \ R * & } T也有一些数据库厂商尝试在 OLAP 的场景中加入 AI 辅助进行Y A ? 3 \ Y h数据分析,那么这种趋势是否会给 ZNBase 的未来发展方向带来一些启示呢?

陈磊告诉我们,目前业内在数据库中引用 AI 辅助的模式主要有两种,一种是 AI for DB,还有一种是 DB for AI。

DB for AI 就是为分布式数据库提供 AI 分析的能; W ?力。就像 Greenplum 通过 MADlib 的第三方插件来实现一些机器学习、图计算或者深度学习的一些算法,客户直接使用AI算法对库内的数据进行计算。“这样的工作确实有# l A厂商在做,但我认为还不足以形成一种趋势。”陈磊表示。

另外一种模式就是 AI for DB,这种模式有两种,第一种是一些数据库厂商提n D J z供的类似“数据库K S R n S W + %大脑”或“数据库自动驾驶”的外部工具,它通过分析数据库日志或者一些视图,得出数据库的性能表现$ P y x,然后去动态地调整数] H V . 7据库参数,来达到优化数据库性能的目的。另外就是在数据库中利用一些 AI 算法来进行优化,包括内核优a S z化、运维优化等。比如在数据库比较L B D o核心的执行计划、执行计划生成、优化器等部分加入 AI 算法的能力辅助来实现性能优化,^ g @ i这一块确实是数据s ! = F . L A ; A库行业目前的趋势,也是陈磊认为最难做的部分。

ZNBase 的团队实际上也在做数据库与 AI 结合的研究,而 AI for DB 是目前主要研究的一个方向。

未来规划

最后,陈磊分别从开源运营角度和产品研发角度介绍了 ZNBase 未来一段时间的发展规划。

首先是开源规划,目前团队暂时只开源了 ZNBase 的 KV 存储部分,他们的计划是争取 6 月底把 ZNBase 的所有代码全部开源,包括 SQH X 9 \ VLA 9 ` 层和一些上下层封装接口,全部采用 Apache 2.0 协议。

而关于研发的规划,陈磊向我们透露了大致的方向:“目前我们正在研发一个列存引擎,还有前面提到的 AI 方面的优化,以及用 C++ 或 Rust 替代 Go 语言来重写 Z\ 0 9 | 1 3NBase 的 SQL 层,这些工作都在我们的日程中。感谢大家对 ZNBase 的关注,我们也会尽快把所有的代码开源出来,届时欢迎感兴趣的开发者加入到我们的社区中参与贡献。“

嘉宾介绍

陈磊,浪潮云溪数据库研发副总经理兼产品负责人

ZNBase详细信息:
点击查看
ZNBase 下载地址:
点击下载

回答

发表回复

您的电子邮箱地址不会被公开。