分布式NewSQL数据库-ZNBase
2021-04-25 17:36:42 
阿炯
ZNBase 是一款分布式数据库产品，具备强一致、高可用分布式架构、分布式水平扩展、高性能、企业级安全等特性，自研的原生分布式存储引擎支持完整 ACID，支持 PostgreSQL 协议访问。同时提供自动化运维、监控告警等配套服务，为用户提供完整的分布式数据库解决方案。主体目前是采用Apache协议授权，请以其主页声明的协议为准。
ZNBase 数据库公司是浪潮集团控股的基础软件企业，汇聚了全球领先的数据库人才致力于打造自主、先进、安全的国产化分布式数据库。产品采用“去中心”架构，具备云原生、多中心、高可用、事务强一致等特性，满足HTAP场景需求，赋能智慧城市与工业互联网建设，并面向政府、金融、能源等关键性领域提供分布式数据存储与运算服务。浪潮ZNBase数据库已经组建世界一流的全球化的研发体系，具有多为世界顶尖数据库专家，研发团队遍布全球各地，分别是美国、上海、北京、 天津、济南等研发团队，ZNBase数据库致力打造成为一款支撑国家战略的产品。
特性
完全去中心化架构
ZNBase 集群中各个节点的地位完全对等，同时所有功能封装在一个二进制文件中，可以做到尽量不依赖配置文件直接部署。对外提供标准 SQL 接口，集群中任意节点都可以作为接入节点处理用户的 SQL 请求。
高可用性
支持不停机在线扩容、故障秒级恢复，可跨数据中心和跨地域分布，以应对来自数据中心电源中断或网络中断，以及区域电力故障等问题。
弹性扩展
原生分布式存储引擎与上层数据库实例均支持 EB 级数据弹性扩展，提供可动态无限扩展的存储容量。客户端查询请求可以发送到集群任意节点，且每个查询可独立并发执行（无论有无冲突），意味着集群的吞吐能力可以随着节点数的增加线性提升。
强一致性
支持分布式事务 ACID，使用高效的无锁分布式事务保障 ACID 语义；Raft 算法保证分布式多副本强一致、外部读写一致。
云原生
提供托管、Docker、二进制进程多种运行态，扩展运维管理容易；逻辑集中，物理分布，资源透明分片。托管服务提供自动故障恢复，自动拓展功能。
安全可靠
支持权限管理、数据库审计、加密、VPC 协同等功能；可靠性上，数据库引擎原生支持多数据中心容灾机制，无单点故障。多租户隔离，以平台化形式对上层应用与微服务提供数据访问能力，不同微服务的底层数据逻辑隔离。
易于使用
安装包仅为一个二进制文件，将所有功能、插件、工具都融合其中，极易部署管理。通过管理控制台可在几分钟内启动并投入生产的数据库。控制台提供常见的数据库运维操作，提供常见的系统监控数据和性能分析数据。
协议级兼容
高度兼容 postgre 通信协议、语法及客户端。对已有应用程序，无需应用程序代码调整，即可无缝切换。
多元业务场景支持
同时支持联机事务处理 (Online Transactional Processing ,OLTP) 及联机分析处理 (Online Analytical Processing ,OLAP)，帮助用户基于一套系统同时承载在线交易及数据分析业务，可广泛应用于工业物联网、商业智能分析、电商推荐系统、搜索引擎等业务场景。
成熟稳定
存储节点为浪潮云存储产品，由浪潮成熟度和稳定性得到保证，ZNBase 团队专注于分布式数据库研发，提优质定的企业级支持。
基本功能
应用场景
金融级商业数据库应用场景
ZNBase 数据库系统分布式数据库基于通用 x86 服务器便可轻松支撑起上亿的用户访问，并且完整支持分布式事务、强一致、多副本高可用，满足分布式核心交易业务需求完全基于云计算理念实现，同时支持云服务模式与独立部署，既具有云架构的敏捷与弹性，也兼顾了独立性与高性能，既可满足传统核心应用对安全与性能的要求，又能轻松实现业务上云。
多地部署异地多活场景
ZNBase 数据库系统具有原生数据强一致性的独特优势，支持统一部署，数据地理分区，高延迟网络条件下的数据一致性技术、分布式的多副本强一致，可以满足“中央-地方”多级多地部署需求。分部和各地分支机构在各自数据中心的集群进行常规业务操作，总部通过统一逻辑视图进行数据透明汇总和分析。
海量数据存储访问场景
ZNBase 数据库系统支持节点快速弹性完成垂直、水平扩展缩容，存储容量最大到 4EB，完全满足用户的海量数据存储和查询要求。可以广泛应用于工业远程监控和远程控制、智慧城市的延展、智能家居、车联网、充电桩加油站等传感监控设备多、采样率高、数据上报存储数据量大的场景。
HTAP 混合场景
ZNBase 数据库系统充分实现了 HTAP (Hybrid Transactional and Analytical Processing, HTAP) 解决方案，能做到针对同样数据的 OLTP 与 OLAP 业务同时运行且互不干扰，降低数据存储成本。可广泛应用于工业物联网、商业智能分析、电商推荐系统、搜索引擎等业务场景。
解决方案
赋能智慧城市与工业互联网建设，并面向政府、金融、能源等关键性领域提供分布式数据存储与运算服务。数据库基于Google的Spanner设计理念自主开发，代码覆盖率已经超过70%，并且与中标麒麟、银河麒麟、飞腾、海光等国产化操作系统和硬件平台完成了兼容性适配，是金融行业推进数据库安全存储、可信存储的最佳解决方案。
产品采用全对等（去中心）架构，每个节点都参与到数据的存储和运算，可以通过不断扩展节点的方式使数据库存储和运算能力呈线性提升，以此实现PB级数据存储
多副本分布式存储方案，并支持多中心部署和数据同步，实现数据高可用存储。各节点均支持故障自动转移，单节点故障不影响整体应用环境运行，保障业务连续性
在数据库分布式存储的前提下支持事务强一致性，支持多节点处理同一事务以提高数据库整体性能，可以通过节点的不断增加，以适应业务扩展带来的性能需求。并且支持多核、多线程并行处理，以提高单节点性能
数据库采用云原生设计，支持云上PaaS层服务，已经与浪潮云等多种云环境完成了适配和对接，并且可按实例进行资源切割和安全管控，对金融行业云上业务迁移提完善的方案和案例参考
产品兼容性
高度兼容 Postgres 通信协议、语法及客户端。对已有应用程序，无需应用程序代码调整，即可无缝切换。SQL方面兼容PostgreSQL、MySQL的大部分语法基本数据类型和函数功能。
总体架构
ZNBase 数据库系统参考自谷歌 Spanner+F1 的设计思想，包含上下两层结构。其中 SQL 层使用 Go 语言开发，基于开源 Cockroach DB 修改，消化吸收并重写、优化其商业代码和开源部分代码，源代码修改率（自主可控度）已达 76%。存储层使用 C++ 开发，采用多模存储引擎，涵盖结构化（行、列存储）、KV 键值存储、文件存储、时序存储、图存储、区块链存储等，目前已实现结构化（行、列存储）和 KV 存储。
ZNBase 目前已经将存储层部分的 KV 存储组件 ZN-KVS 开源，未来还将陆续开源 SQL 层、多模存储引擎以及基于 Go 语言的上下层封装 API。
分布式存储的负载均衡
作为分布式数据库，为了更有效利用不同物理机节点的资源，避免服务器性能的浪费，在数据库高负载的情况下需要尽量将压力平衡到各个物理机节点上。这也是分布式数据库的研究重点之一。
云溪数据库 ZNBase 在存储上采用三副本策略，即每份数据默认同时存在三个节点中，每个副本为一个 Replica。数据库在进行读写时，其中一份副本会获得一定时间内的租约，成为 lease，该 lease 的节点即为该 range 的 leaseholder。系统的读写都是通过 leaseholder 进行的，leaseholder 会将对该副本的读写同步到其他的 Replica。ZNBase 在启动时会创建 StoreReblancer，用于自适应的对副本进行均衡。ZNBase 通过对 Replica 以及 lease 进行迁移以平衡数据库的压力负载。StoreReblancer 会以 10 秒的周期反复执行，如果存储的压力超过阈值，则会循环对每个 range 分两个部分进行平衡，包括租约平衡和副本平衡。
图：负载均衡基本流程图
租约平衡
ZNBase 会维护当前节点存储的副本，其中的 lease 会维护该副本的 QPS(每秒查询率)，并按照 QPS 降序进行排序。压力不够阈值的 range，不进行平衡。StoreReblancer 会循环遍历一个 range 的多个副本，排除本地的，排除压力不符合阈值的，排除不正常的，排除 zone 限制的副本，选择剩下的副本转移租约。租期的选举和迁移不涉及到 replica 的复制和传输。对于需要迁移的 range 来说，StoreReblancer 对其租约迁移的副本选取规则如下：
非本地副本。
当前 store 拥有的租期是合法的。
判断租期转移后本地 range 的 QPS 可以转到阈值以内。
待迁移的 replica 的 raftStatus 领先于候选的 replica 的 raftStatus。
满足 zone(分区信息)的约束条件。一些表可能会带有租期的限制条件，规定了该数据表的副本所在的结点，以及租期所在的结点。对于固定了租期的数据表，StoreReblancer 不会迁移其 range 的租期。
Lease 选取的基本流程如下图所示：
图：待选取 lease 流程
如果当它的 QPS 大于当前的阈值范围，数据库会将其租约转移到该存储该副本的其他节点上。因为数据库是直接对 leaseholder 进行读写，并由 leaseholder 同步到其他副本，故当节点负载过大时，只要将较大读写负载的副本租约转换到其他节点，就可以把该部分的压力均衡出去。
副本平衡
如果保存某副本的三台节点压力负载都不符合 lease 的迁出条件时，数据库会选择将该副本同步到三副本以外的节点，然后将 lease 迁出，以动态平衡压力。系统会对需要平衡的 range 进行筛选，对于压力没有达到阈值的 range 或迁移后对该 store 的 QPS 影响较小时，则不会进行平衡操作。 系统首先设定目标 store 数量，通常等于 range 的副本数。循环一个 range 的多个副本，排除本地副本后，如果副本所在的 store 压力符合阈值，或者不存在，将该 store 放入目标数组。
如果目标数组的目标数量不足，则继续从其他所有 store 中选择，直到符合目标数量。选择 Store 目标数组的过程需要符合 zone（分区）限制，容量限制，压力阈值限制，并排序。如果还是不足，则放弃平衡。同时，副本的迁移应该满足多样性的限制，多样性指副本所在的多级分区的分散程度，副本所在的多级分区越分散，多样性分值越高。在选择目标 store 时，需要将新的多样性分值同原来的多样性分值进行比较，如果不如以前，则放弃平衡。
ZNBase 会循环目标数组，计算新的租约和压力值，然后选择目标数组进行副本迁移。迁移过程首先用 batch 命令，副本收到命令，并发送快照。
热数据分裂
如果同时对某副本的数据进行大量的读写，压力负载是由于该副本引起时，单纯的迁移 lease 或者 replica 都无法较好的调节该情况。该部分功能由 splitQueue 进行管理。ZNBase 会选择对热点数据的 range 进行分裂，从而把压力从单个 range 上分开，该步骤会导致创建新的 replica，从而分散了压力和流量。创建新的 replica 之后的均衡仍由 store-reblancer 进行。数据库会在 range 分裂后再进行 reblance。当压力降低后，系统会自动进行 range 的合并。
小结
以上就是 ZNBase 在处理高负载存储时采用的负载均衡策略，通过租约平衡、副本平衡与热数据分裂三种不同维度的均衡策略，避免了单个节点在高负载情况下出现性能瓶颈，提升了数据库系统的读写性能。
浪潮云溪数据库研发副总经理兼产品负责人陈磊谈项目的背景与未来
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 是一个 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 单机版等。随着数据不断积累，数据量越来越大，团队开始面临一些新的问题：要不要购买这些数据库的升级版本，或者要不要再升级硬件，但这些都不能解决根本问题，到未来数据量发展到一定程度时，还是会出现瓶颈。于是浪潮大数据团队综合多方述求开始探索解决方案。
最初经过调研，团队尝试过使用分布式中间件的方法。但对于其他业务部门来说，他们还是希望解决方案对业务代码本身没有侵入，并且中间件的维护也过于复杂。因为浪潮的业务更多是面向传统企业客户，这与很多在自己的业务中使用分布式中间件的互联网公司不同。“我们的业务以响应客户为优先级，必须为这些客户提供一套完整且易用的解决方案。”
“后来，我们的团队了解到了谷歌发布的 NewSQL 技术路线，觉得这种分布式的关系型数据库还比较适合我们。最初我们是在内部引入 CockroachDB，这是谷歌 NewSQL 产品 Spanner 的开源版本。当时 CockroachDB 刚刚发布不久，我们就一直在关注这个项目，也开始给浪潮内部的一些业务应用推荐这个项目。但刚开始用的时候这些业务部门多多少少会遇到一些问题，于是我们大数据团队就开始给他们做一些技术支持的工作，在这个过程中我们的团队也深入到 CockroachDB 社区参与贡献，并为社区提交代码。”陈磊介绍。而到了 2019 年初，浪潮大数据团队部分已经加入云服务集团团队，面临各项业务上云的工作。这时云服务团队就希望他们把基于 CockroachDB 的分布式数据库也上云。而此时正好赶上了 CockroachDB 官方为了限制 AWS 等云厂商修改了项目的 License，不能把 CockroachDB 当做云服务提供。
“虽然我们能够理解 CockroachDB Labs 的这种做法，但我们也需要维持自己的业务。”于是团队只能基于 CockroachDB 的非商业限制版本重新分支立项，并投入大量人力来维护和开发，也就成了现在的 ZNBase。“当然，我们在这个过程中也收到了很多用户的反馈，也根据这些反馈做了一些工作，包括 SQL 的分析性能增强和各种语法特性优化等。”
因为 ZNBase 整个分布式数据库系统最初都是基于开源项目研发，所以在开发过程中，浪潮也积极地回馈上游的开源社区。据统计，浪潮的技术团队为 Cockroach DB、RocksDB、kubernetes 等项目社区提交了 commit 80 多个，issue 50 多个，参与代码贡献的开发者有 30 余人。
看好 Rust，考虑替换 Go
由于 ZNBase 是基于 CockroachDB 而来，所以使用的开发语言也是该项目原本的 Go 语言；存储层则是基于 RocksDB 开发，因此使用的也是该项目原本的 C++。Rust 语言近年来在社区中的声量很高，不少大厂也开始在内部大规模启用 Rust 来替换 C++。被问到 ZNBase 是否考虑过在未来将 C++ 替换为 Rust 时，陈磊表示：“Rust 最近确实很火。我个人其实早在 2016 年，也就是 Rust 的 1.0 版本还没有正式发布的时候就开始关注了，它确实是一门非常有潜力的编程语言，不过我们的工作内容更多的是解决客户的实际问题。但目前也仍然保持对 Rust 的关注。”
陈磊认为，Rust 近年来的火爆，更多的是一些大公司在用这门语言，比如国外的亚马逊、微软、谷歌，国内的阿里、华为等，首先这些大公司自身的软件规模足够庞大，C/C++语言在内存管理方面的问题难以解决，他们就可以引入 Rust 来解决这些内存安全的坑。
事实上，ZNBase 作为一款新的产品，在选择技术路线的时候也确实会需要考虑这种未来的趋势，但目前 ZNBase 团队还没有考虑到用 Rust 完全去重写原本用 C++ 开发的 RocksDB。“RocksDB 本身就是一个 C++ 写的东西，除非我们发现 RocksDB 的哪些特性，或者哪些问题无法满足我们的产品需求时，我们才会去尝试改造它。”
值得一提的是，虽然 ZNBase 团队暂时不会考虑用 Rust 去替换掉 C++，但出于对性能的考虑，他们可能会用 Rust 将 SQL 层的 Go 语言替换掉。“Rust 确实是一门性能很高的语言，从技术规划的角度来说，后边我们是有计划把 Go 语言替换成 Rust 的，因为 Go 的性能确实没有 C/C++ 和 Rust 高，我们可能会用 Rust 替换掉 SQL 层和副本层的 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 更加稳定可靠。
详细来说，ZNBase 与同样基于 Spanner+F1 设计理念的 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
AI 的高速发展影响着各行各业，如今也有一些数据库厂商尝试在 OLAP 的场景中加入 AI 辅助进行数据分析，那么这种趋势是否会给 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 语言来重写 ZNBase 的 SQL 层，这些工作都在我们的日程中。感谢大家对 ZNBase 的关注，我们也会尽快把所有的代码开源出来，届时欢迎感兴趣的开发者加入到我们的社区中参与贡献。 ”
最新版本：2.0
官方主页：http://www.znbase.com/
ZNBase 数据库公司是浪潮集团控股的基础软件企业，汇聚了全球领先的数据库人才致力于打造自主、先进、安全的国产化分布式数据库。产品采用“去中心”架构，具备云原生、多中心、高可用、事务强一致等特性，满足HTAP场景需求，赋能智慧城市与工业互联网建设，并面向政府、金融、能源等关键性领域提供分布式数据存储与运算服务。浪潮ZNBase数据库已经组建世界一流的全球化的研发体系，具有多为世界顶尖数据库专家，研发团队遍布全球各地，分别是美国、上海、北京、 天津、济南等研发团队，ZNBase数据库致力打造成为一款支撑国家战略的产品。
特性
完全去中心化架构
ZNBase 集群中各个节点的地位完全对等，同时所有功能封装在一个二进制文件中，可以做到尽量不依赖配置文件直接部署。对外提供标准 SQL 接口，集群中任意节点都可以作为接入节点处理用户的 SQL 请求。
高可用性
支持不停机在线扩容、故障秒级恢复，可跨数据中心和跨地域分布，以应对来自数据中心电源中断或网络中断，以及区域电力故障等问题。
弹性扩展
原生分布式存储引擎与上层数据库实例均支持 EB 级数据弹性扩展，提供可动态无限扩展的存储容量。客户端查询请求可以发送到集群任意节点，且每个查询可独立并发执行（无论有无冲突），意味着集群的吞吐能力可以随着节点数的增加线性提升。
强一致性
支持分布式事务 ACID，使用高效的无锁分布式事务保障 ACID 语义；Raft 算法保证分布式多副本强一致、外部读写一致。
云原生
提供托管、Docker、二进制进程多种运行态，扩展运维管理容易；逻辑集中，物理分布，资源透明分片。托管服务提供自动故障恢复，自动拓展功能。
安全可靠
支持权限管理、数据库审计、加密、VPC 协同等功能；可靠性上，数据库引擎原生支持多数据中心容灾机制，无单点故障。多租户隔离，以平台化形式对上层应用与微服务提供数据访问能力，不同微服务的底层数据逻辑隔离。
易于使用
安装包仅为一个二进制文件，将所有功能、插件、工具都融合其中，极易部署管理。通过管理控制台可在几分钟内启动并投入生产的数据库。控制台提供常见的数据库运维操作，提供常见的系统监控数据和性能分析数据。
协议级兼容
高度兼容 postgre 通信协议、语法及客户端。对已有应用程序，无需应用程序代码调整，即可无缝切换。
多元业务场景支持
同时支持联机事务处理 (Online Transactional Processing ,OLTP) 及联机分析处理 (Online Analytical Processing ,OLAP)，帮助用户基于一套系统同时承载在线交易及数据分析业务，可广泛应用于工业物联网、商业智能分析、电商推荐系统、搜索引擎等业务场景。
成熟稳定
存储节点为浪潮云存储产品，由浪潮成熟度和稳定性得到保证，ZNBase 团队专注于分布式数据库研发，提优质定的企业级支持。
基本功能
| 功能 | 描述 |
|---|---|
| CPU架构 | 支持x86和ARM架构 |
| 数据类型 | 数值类型：INT、DECIMAL、FLOAT 等； 字符类型：STRING、VARCHAR、CHAR 等； 日期类型：TIME、DATE、TIMESTAMP 等； 二进制类型：BYTES、BIT 等； |
| 数据库对象 | 提供了数据库、表（普通表及分区表）、索引、视图、约束等常用数据库对象的创建、修改和删除操作；数据库用户的创建、修改和删除，权限 的赋予与撤回。 |
| 结构化查询语言（SQL） | BINI 语法兼容支持 MySQL 和 PostgreSQL，支持大部分 ANSI 标准 SQL，比如 DDL：CREATE、ALTER、DROP、TRUNCATE； DML：INSERT、DELETE、 UPDATE、SELECT； TCL:BEGIN/START [TRANSACTION]、SAVEPOINT、COMMIT、ROLLBACK、END [TRANSACTION]; 支持单表查询、多表联合查询等。 |
| 接口 | 支持大多数与 PostgreSQL 兼容的驱动程序以及许多 PostgreSQL ORM，如 GORM（Go）和 Hibernate（Java），JDBC，ODBC。 |
| 图形化工具 | 提供图形化数据库管理工具和集群监控工具，管理工具可以实现数 据库对象，如表单、视图、约束、分区表、索引、用户管理等功能的 图形化管理和操作；集群监控工具提供有关群集和数据库配置的详 细信息以及各类指标监控信息。 |
应用场景
金融级商业数据库应用场景
ZNBase 数据库系统分布式数据库基于通用 x86 服务器便可轻松支撑起上亿的用户访问，并且完整支持分布式事务、强一致、多副本高可用，满足分布式核心交易业务需求完全基于云计算理念实现，同时支持云服务模式与独立部署，既具有云架构的敏捷与弹性，也兼顾了独立性与高性能，既可满足传统核心应用对安全与性能的要求，又能轻松实现业务上云。
多地部署异地多活场景
ZNBase 数据库系统具有原生数据强一致性的独特优势，支持统一部署，数据地理分区，高延迟网络条件下的数据一致性技术、分布式的多副本强一致，可以满足“中央-地方”多级多地部署需求。分部和各地分支机构在各自数据中心的集群进行常规业务操作，总部通过统一逻辑视图进行数据透明汇总和分析。
海量数据存储访问场景
ZNBase 数据库系统支持节点快速弹性完成垂直、水平扩展缩容，存储容量最大到 4EB，完全满足用户的海量数据存储和查询要求。可以广泛应用于工业远程监控和远程控制、智慧城市的延展、智能家居、车联网、充电桩加油站等传感监控设备多、采样率高、数据上报存储数据量大的场景。
HTAP 混合场景
ZNBase 数据库系统充分实现了 HTAP (Hybrid Transactional and Analytical Processing, HTAP) 解决方案，能做到针对同样数据的 OLTP 与 OLAP 业务同时运行且互不干扰，降低数据存储成本。可广泛应用于工业物联网、商业智能分析、电商推荐系统、搜索引擎等业务场景。
解决方案
赋能智慧城市与工业互联网建设，并面向政府、金融、能源等关键性领域提供分布式数据存储与运算服务。数据库基于Google的Spanner设计理念自主开发，代码覆盖率已经超过70%，并且与中标麒麟、银河麒麟、飞腾、海光等国产化操作系统和硬件平台完成了兼容性适配，是金融行业推进数据库安全存储、可信存储的最佳解决方案。
产品采用全对等（去中心）架构，每个节点都参与到数据的存储和运算，可以通过不断扩展节点的方式使数据库存储和运算能力呈线性提升，以此实现PB级数据存储
多副本分布式存储方案，并支持多中心部署和数据同步，实现数据高可用存储。各节点均支持故障自动转移，单节点故障不影响整体应用环境运行，保障业务连续性
在数据库分布式存储的前提下支持事务强一致性，支持多节点处理同一事务以提高数据库整体性能，可以通过节点的不断增加，以适应业务扩展带来的性能需求。并且支持多核、多线程并行处理，以提高单节点性能
数据库采用云原生设计，支持云上PaaS层服务，已经与浪潮云等多种云环境完成了适配和对接，并且可按实例进行资源切割和安全管控，对金融行业云上业务迁移提完善的方案和案例参考
产品兼容性
高度兼容 Postgres 通信协议、语法及客户端。对已有应用程序，无需应用程序代码调整，即可无缝切换。SQL方面兼容PostgreSQL、MySQL的大部分语法基本数据类型和函数功能。
总体架构
ZNBase 数据库系统参考自谷歌 Spanner+F1 的设计思想，包含上下两层结构。其中 SQL 层使用 Go 语言开发，基于开源 Cockroach DB 修改，消化吸收并重写、优化其商业代码和开源部分代码，源代码修改率（自主可控度）已达 76%。存储层使用 C++ 开发，采用多模存储引擎，涵盖结构化（行、列存储）、KV 键值存储、文件存储、时序存储、图存储、区块链存储等，目前已实现结构化（行、列存储）和 KV 存储。
ZNBase 目前已经将存储层部分的 KV 存储组件 ZN-KVS 开源，未来还将陆续开源 SQL 层、多模存储引擎以及基于 Go 语言的上下层封装 API。
分布式存储的负载均衡
作为分布式数据库，为了更有效利用不同物理机节点的资源，避免服务器性能的浪费，在数据库高负载的情况下需要尽量将压力平衡到各个物理机节点上。这也是分布式数据库的研究重点之一。
云溪数据库 ZNBase 在存储上采用三副本策略，即每份数据默认同时存在三个节点中，每个副本为一个 Replica。数据库在进行读写时，其中一份副本会获得一定时间内的租约，成为 lease，该 lease 的节点即为该 range 的 leaseholder。系统的读写都是通过 leaseholder 进行的，leaseholder 会将对该副本的读写同步到其他的 Replica。ZNBase 在启动时会创建 StoreReblancer，用于自适应的对副本进行均衡。ZNBase 通过对 Replica 以及 lease 进行迁移以平衡数据库的压力负载。StoreReblancer 会以 10 秒的周期反复执行，如果存储的压力超过阈值，则会循环对每个 range 分两个部分进行平衡，包括租约平衡和副本平衡。
图：负载均衡基本流程图
租约平衡
ZNBase 会维护当前节点存储的副本，其中的 lease 会维护该副本的 QPS(每秒查询率)，并按照 QPS 降序进行排序。压力不够阈值的 range，不进行平衡。StoreReblancer 会循环遍历一个 range 的多个副本，排除本地的，排除压力不符合阈值的，排除不正常的，排除 zone 限制的副本，选择剩下的副本转移租约。租期的选举和迁移不涉及到 replica 的复制和传输。对于需要迁移的 range 来说，StoreReblancer 对其租约迁移的副本选取规则如下：
非本地副本。
当前 store 拥有的租期是合法的。
判断租期转移后本地 range 的 QPS 可以转到阈值以内。
待迁移的 replica 的 raftStatus 领先于候选的 replica 的 raftStatus。
满足 zone(分区信息)的约束条件。一些表可能会带有租期的限制条件，规定了该数据表的副本所在的结点，以及租期所在的结点。对于固定了租期的数据表，StoreReblancer 不会迁移其 range 的租期。
Lease 选取的基本流程如下图所示：
图：待选取 lease 流程
如果当它的 QPS 大于当前的阈值范围，数据库会将其租约转移到该存储该副本的其他节点上。因为数据库是直接对 leaseholder 进行读写，并由 leaseholder 同步到其他副本，故当节点负载过大时，只要将较大读写负载的副本租约转换到其他节点，就可以把该部分的压力均衡出去。
副本平衡
如果保存某副本的三台节点压力负载都不符合 lease 的迁出条件时，数据库会选择将该副本同步到三副本以外的节点，然后将 lease 迁出，以动态平衡压力。系统会对需要平衡的 range 进行筛选，对于压力没有达到阈值的 range 或迁移后对该 store 的 QPS 影响较小时，则不会进行平衡操作。 系统首先设定目标 store 数量，通常等于 range 的副本数。循环一个 range 的多个副本，排除本地副本后，如果副本所在的 store 压力符合阈值，或者不存在，将该 store 放入目标数组。
如果目标数组的目标数量不足，则继续从其他所有 store 中选择，直到符合目标数量。选择 Store 目标数组的过程需要符合 zone（分区）限制，容量限制，压力阈值限制，并排序。如果还是不足，则放弃平衡。同时，副本的迁移应该满足多样性的限制，多样性指副本所在的多级分区的分散程度，副本所在的多级分区越分散，多样性分值越高。在选择目标 store 时，需要将新的多样性分值同原来的多样性分值进行比较，如果不如以前，则放弃平衡。
ZNBase 会循环目标数组，计算新的租约和压力值，然后选择目标数组进行副本迁移。迁移过程首先用 batch 命令，副本收到命令，并发送快照。
热数据分裂
如果同时对某副本的数据进行大量的读写，压力负载是由于该副本引起时，单纯的迁移 lease 或者 replica 都无法较好的调节该情况。该部分功能由 splitQueue 进行管理。ZNBase 会选择对热点数据的 range 进行分裂，从而把压力从单个 range 上分开，该步骤会导致创建新的 replica，从而分散了压力和流量。创建新的 replica 之后的均衡仍由 store-reblancer 进行。数据库会在 range 分裂后再进行 reblance。当压力降低后，系统会自动进行 range 的合并。
小结
以上就是 ZNBase 在处理高负载存储时采用的负载均衡策略，通过租约平衡、副本平衡与热数据分裂三种不同维度的均衡策略，避免了单个节点在高负载情况下出现性能瓶颈，提升了数据库系统的读写性能。
浪潮云溪数据库研发副总经理兼产品负责人陈磊谈项目的背景与未来
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 是一个 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 单机版等。随着数据不断积累，数据量越来越大，团队开始面临一些新的问题：要不要购买这些数据库的升级版本，或者要不要再升级硬件，但这些都不能解决根本问题，到未来数据量发展到一定程度时，还是会出现瓶颈。于是浪潮大数据团队综合多方述求开始探索解决方案。
最初经过调研，团队尝试过使用分布式中间件的方法。但对于其他业务部门来说，他们还是希望解决方案对业务代码本身没有侵入，并且中间件的维护也过于复杂。因为浪潮的业务更多是面向传统企业客户，这与很多在自己的业务中使用分布式中间件的互联网公司不同。“我们的业务以响应客户为优先级，必须为这些客户提供一套完整且易用的解决方案。”
“后来，我们的团队了解到了谷歌发布的 NewSQL 技术路线，觉得这种分布式的关系型数据库还比较适合我们。最初我们是在内部引入 CockroachDB，这是谷歌 NewSQL 产品 Spanner 的开源版本。当时 CockroachDB 刚刚发布不久，我们就一直在关注这个项目，也开始给浪潮内部的一些业务应用推荐这个项目。但刚开始用的时候这些业务部门多多少少会遇到一些问题，于是我们大数据团队就开始给他们做一些技术支持的工作，在这个过程中我们的团队也深入到 CockroachDB 社区参与贡献，并为社区提交代码。”陈磊介绍。而到了 2019 年初，浪潮大数据团队部分已经加入云服务集团团队，面临各项业务上云的工作。这时云服务团队就希望他们把基于 CockroachDB 的分布式数据库也上云。而此时正好赶上了 CockroachDB 官方为了限制 AWS 等云厂商修改了项目的 License，不能把 CockroachDB 当做云服务提供。
“虽然我们能够理解 CockroachDB Labs 的这种做法，但我们也需要维持自己的业务。”于是团队只能基于 CockroachDB 的非商业限制版本重新分支立项，并投入大量人力来维护和开发，也就成了现在的 ZNBase。“当然，我们在这个过程中也收到了很多用户的反馈，也根据这些反馈做了一些工作，包括 SQL 的分析性能增强和各种语法特性优化等。”
因为 ZNBase 整个分布式数据库系统最初都是基于开源项目研发，所以在开发过程中，浪潮也积极地回馈上游的开源社区。据统计，浪潮的技术团队为 Cockroach DB、RocksDB、kubernetes 等项目社区提交了 commit 80 多个，issue 50 多个，参与代码贡献的开发者有 30 余人。
看好 Rust，考虑替换 Go
由于 ZNBase 是基于 CockroachDB 而来，所以使用的开发语言也是该项目原本的 Go 语言；存储层则是基于 RocksDB 开发，因此使用的也是该项目原本的 C++。Rust 语言近年来在社区中的声量很高，不少大厂也开始在内部大规模启用 Rust 来替换 C++。被问到 ZNBase 是否考虑过在未来将 C++ 替换为 Rust 时，陈磊表示：“Rust 最近确实很火。我个人其实早在 2016 年，也就是 Rust 的 1.0 版本还没有正式发布的时候就开始关注了，它确实是一门非常有潜力的编程语言，不过我们的工作内容更多的是解决客户的实际问题。但目前也仍然保持对 Rust 的关注。”
陈磊认为，Rust 近年来的火爆，更多的是一些大公司在用这门语言，比如国外的亚马逊、微软、谷歌，国内的阿里、华为等，首先这些大公司自身的软件规模足够庞大，C/C++语言在内存管理方面的问题难以解决，他们就可以引入 Rust 来解决这些内存安全的坑。
事实上，ZNBase 作为一款新的产品，在选择技术路线的时候也确实会需要考虑这种未来的趋势，但目前 ZNBase 团队还没有考虑到用 Rust 完全去重写原本用 C++ 开发的 RocksDB。“RocksDB 本身就是一个 C++ 写的东西，除非我们发现 RocksDB 的哪些特性，或者哪些问题无法满足我们的产品需求时，我们才会去尝试改造它。”
值得一提的是，虽然 ZNBase 团队暂时不会考虑用 Rust 去替换掉 C++，但出于对性能的考虑，他们可能会用 Rust 将 SQL 层的 Go 语言替换掉。“Rust 确实是一门性能很高的语言，从技术规划的角度来说，后边我们是有计划把 Go 语言替换成 Rust 的，因为 Go 的性能确实没有 C/C++ 和 Rust 高，我们可能会用 Rust 替换掉 SQL 层和副本层的 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 更加稳定可靠。
详细来说，ZNBase 与同样基于 Spanner+F1 设计理念的 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
AI 的高速发展影响着各行各业，如今也有一些数据库厂商尝试在 OLAP 的场景中加入 AI 辅助进行数据分析，那么这种趋势是否会给 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 语言来重写 ZNBase 的 SQL 层，这些工作都在我们的日程中。感谢大家对 ZNBase 的关注，我们也会尽快把所有的代码开源出来，届时欢迎感兴趣的开发者加入到我们的社区中参与贡献。 ”
最新版本：2.0
官方主页：http://www.znbase.com/