2012年和2013年，Google发表了两篇系统论文：Spanner和F1，让业界第一次看到了关系模型和NoSQL的可扩展性在在大规模生产系统上集成的可能性，这种新的数据库架构被行业分析师Matthew Aslett称为“NewSQL”。

在接下来的几年里，NewSQL 数据库出现爆炸式增长。各大云服务厂商基于Spanner+F1论文推出了自己的NewSQL数据库服务。开源领域也涌现了CockroachDB、TiDB等热门项目。

近日，浪潮宣布开源NewSQL分布式数据库ZNBase，引起了社区开发者的关注。据悉，浪潮ZNBase数据库还参考了谷歌Spanner+F1系统的设计思想，具有强一致性、高可用分布式架构、分布式水平扩展、高性能、企业级安全等特点。

作为一款专注于 HTAP 混合场景的分布式数据库产品，TiDB 此前受到资本市场的青睐，并霸占国内数据库排行榜。后来阿里巴巴、百度等厂商陆续推出了自己的HTAP分布式数据库产品，而浪潮的ZNBase又将凭借什么优势在国内市场站稳脚跟呢？

ZNBase是什么？

ZNBase产品经理陈雷介绍，ZNBase是一款采用云原生分布式架构的HTAP分布式数据库。 Share Nothing 中的所有节点都是平等的，每个节点都是一个功能齐全的数据库节点。每个节点包括SQL层、事务层、副本层和存储层。 SQL层包括协议和语法解析、优化器和执行器。事务层主要负责分布式事务。副本层负责副本调度，使用Raft算法保证多副本一致性。存储层采用KV存储引擎RocksDB。负责存储数据。

ZNBase 首先支持OLTP场景。该产品完全支持SQL和事务。表数据自动划分为多个Range，分布在不同的数据库节点上。因此，在使用ZNBase数据库时，无论数据表有多大，都不需要手动分表。数据库集群会自动处理，应用程序只需将其作为独立的数据库表使用即可。

在OLAP场景支持方面，我们在SQL执行上做了很多偏向OLAP场景的优化，包括算子并行、异步、向量计算、RBO优化器等，感谢产品分布式架构，可以利用多个节点的计算能力，产品可以满足业务应用的AP需求。

ZNBase 没有类似 TiDB 的集群管理模块（Placement Driver，简称 PD）。每个节点都是一个完整的数据库。每个节点都包含AP和TP能力，可以处理SQL请求、执行SQL计算，以及数据存储引擎的所有工作。然后通过这种分布式架构，将各个节点连接起来，形成ZNBase数据库系统。

取之社会，回馈社会

前面提到，市场上已经有一些相对成熟的分布式数据库解决方案，其中包括许多受到资本追捧的优秀开源项目。那么浪潮技术团队决定重做ZNBase的背后是出于什么考虑呢？

据陈雷回忆，ZNBase研发团队原本是浪潮内部的大数据团队。组内不同单位之间有很多交流，发现其他单位有很多大数据应用。由于浪潮开始信息化比较早，集团最初使用的是免费的MySQL、Oracle单机版、DB2单机版等。随着数据的不断积累，数据量越来越大，团队开始面临一些新的问题。问题：是否购买这些数据库的升级版本，或者是否升级硬件。然而，这些都不能解决根本问题。未来随着数据量的增长，一定程度上仍然会出现瓶颈。于是浪潮大数据团队根据各种需求开始探索解决方案。

经过初步研究，团队尝试使用分布式中间件。但对于其他业务部门来说，还是希望解决方案不会对业务代码本身进行侵入，中间件的维护过于复杂。由于浪潮的业务更多面向传统企业客户，这与很多在自身业务中使用分布式中间件的互联网公司不同。 “我们的业务优先考虑客户响应，必须为这些客户提供完整且易于使用的解决方案。”

“后来我们团队了解了Google发布的NewSQL技术路线，觉得这种分布式关系数据库更适合我们。最初，我们在内部引入了 CockroachDB，它是 Google NewSQL 产品 Spanner 的开源版本。当时CockroachDB刚刚发布，我们一直在关注这个项目，并开始向浪潮内部的一些业务应用推荐这个项目。但是这些业务部门在刚开始使用的时候遇到了一些问题，所以我们的大数据团队开始为他们提供一些技术支持工作，在这个过程中我们团队也深入CockroachDB社区参与贡献并提交向社区发送代码。”陈雷说。

2019年初，浪潮大数据团队的部分加入了云服务组团队，面临各项业务上云的工作。这时云服务团队希望他们也能把基于CockroachDB的分布式数据库放到云端。此时，CockroachDB官方已经修改了项目许可证，限制AWS等云厂商提供CockroachDB作为云服务。

“虽然我们可以理解CockroachDB Labs的这种做法，但我们也需要维护自己的业务。”于是团队只能基于CockroachDB的非商业限制版本重新fork建立项目，并投入大量人力进行维护和开发。它成为现在的ZNBase。 “当然，在这个过程中我们也收到了很多用户的反馈，并根据这些反馈做了一些工作，包括增强SQL分析性能、优化各种语法特性等。”

由于整个ZNBase分布式数据库系统最初是基于开源项目开发的，浪潮在开发过程中也积极回馈上游开源社区。据统计，浪潮技术团队已向Cockroach DB、RocksDB、kubernetes等项目社区提交了80余次commit、50余个issue，超过30名开发者参与了代码贡献。

看好 Rust，考虑用 Go 替代它

由于ZNBase是基于CockroachDB的，所以使用的开发语言也是项目原有的Go语言；存储层是基于RocksDB开发的，所以也使用了项目原有的C++。

Rust 语言近年来在社区中非常流行，很多大公司内部都开始大规模使用 Rust 来替代 C++。当被问及 ZNBase 未来是否考虑过用 Rust 替代 C++ 时，陈雷表示：“Rust 最近确实很流行，我个人早在 2016 年就开始关注 Rust 1.0 版本，在它正式发布之前，它确实是一个潜力巨大的编程语言，但我们的工作更多的是解决客户的实际问题。但我们仍然保持对Rust的关注。”

陈磊认为，Rust 近年来的流行更多是因为一些大公司使用了这种语言，比如国外的亚马逊、微软、谷歌，国内的阿里巴巴、华为等。首先，这些大公司自有软件的规模是足够的。巨大，C/C++语言的内存管理问题很难解决，所以他们可以引入Rust来解决这些内存安全陷阱。

其实，ZNBase作为一个新产品，在选择技术路线时确实需要考虑到这个未来的趋势，但目前ZNBase团队还没有考虑用Rust彻底去重。 RocksDB最初是用C++编写的。 “RocksDB本身是用C++编写的，除非我们发现RocksDB的哪些功能或问题不能满足我们的产品需求，否则我们会尝试对其进行改造。”

值得一提的是，虽然ZNBase团队暂时不会考虑用Rust替代C++，但出于性能考虑，他们可能会在SQL层使用Rust替代Go语言。 “Rust 确实是一门性能非常高的语言，从技术规划的角度来看，我们未来有计划用 Rust 来替代 Go 语言，因为 Go 的性能确实没有 C/C++ 和 Rust 高。我们可能在SQL层和复制层使用Rust替代GO语言。”陈雷说道。

浪潮的硬件优势

浪潮在国内市场以服务器硬件技术闻名。那么ZNBase团队在硬件上做了什么特别的工作吗？

陈雷透露，他们确实在硬件方面做了一些工作。比如在硬件存储方面，浪潮研发了一款新型的ZNSSD存储设备，团队也第一时间拿到了这款设备。软硬件结合的适配，包括底层硬件与ZNBase交互的优化、RDMA的软硬件融合等开发。此外，浪潮本身也有K1主机服务器，目前正在与ZNBase进行底层适配，以提高产品性能和可用性。

总体来说，得益于浪潮的硬件优势，ZNBase团队的硬件工作一直比较顺利。这也是浪潮ZNBase相对于其他分布式数据库的优势。

与TiDB等分布式数据库的区别

说到 HTAP 分布式数据库，就不得不提近几年社区里热门的明星项目 TiDB，以及一些同样主打 HTAP 场景集成的数据库产品，比如国外的 Greenplum、阿里云的HybridDB for MySQL、百度的BaikalDB等。陈雷认为，与这些数据库相比，ZNBase的优势主要体现在两个方面。

首先是背景不同。其他产品则由大型互联网公司开发或面向互联网应用。浪潮是大型IT公司针对政府大数据和大型企业应用而创建的。

第二是架构或者技术栈不同。虽然大多数分布式数据库都使用 KV 存储，但我们刚才提到 ZNBase 是 ShareNothing 架构，而 TiDB 是共享存储架构。因此，浪潮ZNBase的优势在于具有更好的扩展性，更容易部署和运维，并且为用户提供了可以直接启动的二进制包。此外，根据浪潮所服务的部分客户的使用习惯，ZNBase将兼容更多Oracle、DB2等传统商业数据库的功能和语法。

在硬件方面，浪潮技术团队在国产芯片和操作系统的兼容和优化方面做了更多的工作。浪潮拥有自己的分布式存储、操作系统、云平台研发团队，做了大量的底层适配和优化工作，使得ZNBase更加稳定可靠。

具体来说，同样基于Spanner+F1设计理念的ZNBase和TiDB在HTAP架构上比较相似，即都提供了列式存储的副本，侧重于OLTP使用场景，而OLAP场景的应用性能比较轻。幅度在不断增大。两者之间的主要区别在于它们针对的客户群体不同。基于浪潮长期积累的大量政府、金融和传统企业客户的需求，ZNBase针对Oracle、DB2等传统商业数据库做了很多兼容工作，这对浪潮有很大帮助客户迁移到 ZNBase；而 TiDB 可能更多的是针对互联网行业的客户，与 MySQL 生态更加兼容。

国外比较流行的Greenplum是一款主打OLAP场景的产品，其OLTP方面也在不断增强； HybridDB for MySQL 和 BaikalDB 实际上与 Greenplum 类似。它们都有独立的列存储引擎，即表是列存储表还是行存储表在创建之前就已经定义好了。 ZNBase 和 TiDB 都有行存储数据副本和列存储数据副本。这其实是一个本质的区别。

“所以目前主流的HTAP分布式数据库采用行存储和列存储副本，对同一份数据采用不同的存储格式，这应该是未来的一个方向。”陈雷说道：“不过，我们目前还无法提供具体的对比数据，如果大家有兴趣的话，可以自己对比一下，也可以分享给我们。”

HTAP 有很多东西可以提供

针对近年来兴起的HTAP概念，陈磊结合浪潮客户对数据库产品需求的变化历史，为我们讲述了分布式数据库从OLTP场景需求到与OLAP场景需求融合的演进过程。

从浪潮接触到的一些客户使用场景来看，目前传统企业的市场需求仍然以OLTP为主。这主要体现在这些客户业务量的扩大。例如，他们需要添加10台服务器，可能需要同时维护一个包含数百亿数据的表。这时候就需要不断的添加数据。这种场景就是分布式数据库的OLTP部分可以满足他们的需求。

在解决OLTP需求的基础上，整个数据库系统不可避免地会有一些数据积累。人们需要从这些数据中挖掘出对自己的业务有意义的价值，这就产生了对这些数据进行分析的需求。 。分布式数据库承载的数据量通常比传统数据库大得多。使用传统技术进行数据分析是非常痛苦的。一次查询操作可能需要几天的时间，甚至可能不会返回结果。 “这就是为什么我们必须在解决 OLTP 的基础上添加 OLAP 功能，并创建一个将两者集成的 HTAP 数据库。”

HTAP数据库将两种需求场景合而为一的愿景很美好，但在实际开发过程中，实现HTAP并不容易。陈雷介绍，实施HTAP主要有几个难点：

首先需要解决的是数据存储。大家都知道列式存储可以做这种分析操作。开发高性能的列存储引擎是很困难的。当然，已经有一些优秀的开源列存储引擎了。开发者可以在此基础上进行复用。

然后就是行存和列存数据的一致性问题。传统HTAP数据库中，行存储和列存储是两个独立的表，行和列之间不需要维护数据一致性。然而，像 ZNBase 和 TiDB 这样的新 HTAP 数据库对于相同的数据同时具有行存储和列存储。保证数据的一致性是必要的，但是解决数据一致性问题也会带来新的问题，比如影响数据写入的性能。如何解决数据写入性能问题也是一个难点。

此外，数据存储方式有列存储和行存储两种。当查询命令到来时，应该选择哪种存储引擎进行计算？这时候给数据库系统的SQL层、优化器和执行器带来的挑战就会更大。

数据库和人工智能

人工智能的快速发展影响着各行各业。如今，一些数据库厂商正在尝试加入AI来辅助OLAP场景中的数据分析。那么这一趋势是否会给ZNBase未来的发展方向带来一些启发呢？

陈雷告诉我们，目前业界引用数据库AI辅助的模式主要有两种，一种是AI for DB，另一种是DB for AI。

DB for AI是为分布式数据库提供AI分析的能力。就像Greenplum通过MADlib第三方插件实现一些机器学习、图计算或深度学习算法一样，客户直接使用AI算法来计算库中的数据。 “确实有厂家在做这样的工作，但我认为还不足以形成趋势。”陈雷说道。

另一个模型是AI for DB。该型号有两种类型。第一个是是一些数据库厂商提供的类似于“数据库大脑”或“数据库自动驾驶仪”的外部模型。通过分析数据库日志或一些视图来确定数据库的性能，然后动态调整数据库参数以优化数据库性能的工具。另外，使用了一些AI算法来优化数据库，包括内核优化、运维优化等。比如在核心数据库执行计划、执行计划生成、优化器等部分加入AI算法能力来实现性能优化确实是目前数据库行业的趋势，也是陈雷认为最难的部分。

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

未来规划

最后，陈雷从开源运营和产品研发的角度介绍了ZNBase未来的发展规划。

首先是开源规划。目前，团队仅开源了ZNBase的KV存储部分。他们的计划是在6月底之前开源所有ZNBase代码，包括SQL层和一些上下层封装接口，全部使用Apache 2.0协议。 。

关于研发计划，陈雷向我们透露了大致的方向：“目前我们正在开发一个列存储引擎，以及前面提到的AI优化​​，并用C++或Rust来重写，而不是用Go语言。SQL ZNBase层，这些任务都在我们的日程安排中，感谢大家对ZNBase的关注，我们也会尽快将所有代码开源，届时欢迎感兴趣的开发者加入我们的社区并做出贡献。”

嘉宾介绍

陈雷，浪潮云熙数据库研发副总经理、产品负责人

ZNBase 详细信息： 点击查看

ZNBase下载地址： 点击下载