分布式数据库发展路径研究.pdf

分布式数据 库发展路径研究 中国软件评测中心 （工业和信息化部软件与集成电路促进中心） 二 二一 年 一 月 主要编写单位及人员 中国软件评测中心： 吕韬 、曾晋、 翟艳芬、庄金鑫 中兴通讯 股份 有限公司：吕伟初 、 朱业 蚂蚁科技集团股份有限公司：王栩、付万琳 华为技术有限公司： 张昆、杨锐、张霄鸾 贵州易鲸捷信息技术有限公司： 刘明、刘耀华、陶晟 腾讯云 计算（北京）有限责任公司： 陈昊、秦玮 武汉达梦数据库股份有限公司 ： 张寒、冯源 前 言 分布式数据 库是传统数据库技术与计算机网络的有机 结合， 相比于传统的单机或主备模式的集中式数据库， 分布 式数据 库在平滑扩展 、 高性能、高可靠、高可用、低成本等 方面具有优势，特别是在性能方面可突破集中式数据库的瓶 颈，具有很强的研究和应用价值，目前很多数据库企业研发 了 分布式数据 库产品，并在 金融、电信、互联网等重点 行业 进行了成功应用，具有良好的发展前景。 本报告旨在梳理 分布式数据 库的技术体系和应用现状， 结合金融、互联网等领域应用需求，分析制约 分布式数据 库 大规模应用的 因素 ，对未来的技术和应用趋势进行研判 ，并 提 出 发展路径 建议。报告的第一章基于目前的技术发展情况， 给出 分布式数据 库的概念和分类；第二章综合分析 分布式数 据 库发展现状，研判其适用场景，分析制约其发展的技术和 应用 因素 ；第三章 分析 分布式数据 库发展趋势；第四章 提出 推动 分布式数据 库技术发展和 行业 应用的 路径 建议。 由于时间仓促，水平所限，报告中错误和不足之处在所 难免，诚恳欢迎各位读者批评指正，意见建议请发送至 。 目 录 前 言 . 3 1 分布式数据 库的概念及分类 . 6 1.1 分布式数据 库的概念 . 6 1.2 分布式数据 库的主要技术 . 7 1.2.1 分布式事务处理技术 . 7 1.2.2 分布式存储技术 . 11 1.3 分布式数据 库的分类 . 13 1.3.1 联机事务处理 . 13 1.3.2 联机分析处理 . 14 1.3.3 混合事务分析处理 . 15 2 分布式数据 库发展的现状及问题 . 16 2.1 分布式数据 库的发展现状 . 16 2.1.1 技术现状 . 16 2.1.2 重点领域应用 . 18 2.2 分布式数据 库发展面临的问题 . 22 2.2.1 应用系统面对 分布式数据 库的合理选择问题 . 22 2.2.2 遗留系统面对 分布式数据 库的迁移改造问题 . 23 2.2.3 分布式数据 库运维管理较为复杂 . 24 2.2.4 分布式数据 库产品成熟度有待提升 . 25 3 分布式数据 库发展趋势 . 25 3.1 分布式数据 库的产品化日趋成熟 . 25 3.2 与人工智能等新技术融合实现高效运维 . 26 3.3 分布式数据 库的服务方式将向云化发展 . 26 4 分布式数据 库发展路径建议 . 26 4.1 政策引导，形成 分布式数据 库的典型案例 . 27 4.2 产用协同，提升 分布式数据 库产品成熟度 . 27 4.3 营造环境，打 造 分布式数据 库的生态体系 . 28 1 分布式数据 库的概念及分类 1.1 分布式数据 库的概念 分布式数据 库最早 于 20世纪 80年代提出，受限于当时 的计算机软硬件及网络发展水平， 数据库专家 M.Tamer zsu 和 Patrick Valduriez 在经典著作 分布式数据 库系统原理（第 3 版）中，把 分布式数据 库定义为 一群分布在计算机网络上 、 逻辑上相互关联 的数据库。随着信息技术的发展，集中式数 据库 也 正向基于网络的共享集群路线发展，而市场上的 分布 式数据 库也不仅 限于 网络分布 、 逻辑关联 等 特性，经典的 分 布式数据 库定义显然已不能 体现 分布式数据 库 当前 技术特 点 ，难以 满足数据库种类区分 要求 。 根据目前我国 分布式数据 库技术现状，我们认为 分布式 数据 库是 具备分布式事务处理能力、可平滑扩展、分布 于 计 算机网络 且 逻辑上统一的数据库。 主要特征如下： 分布式事务处理 。 分布式数据 库与集中式数据库的 主要区别就是是否具备分布式事务的处理能力。通过对数据 库 各种操作的并行计算、全局事务管理等机制，实现真正的 分布式事务处理，并 实现 与集中式数据库 一致 的 ACID特性。 平滑扩展 。 分布式数据 库可根据业务的增长需要 ， 动态扩展物理节点，以提升整体处理能力，且扩展过程不需 停机，不影响在线业务。理论上可以进行无限扩展，扩展之 后在逻辑上仍然是一个统一的数据库。 物理分布 、 逻辑统一 。 分布式数据 库的数据不是存 储在一个物理节点中，而是存储在计算机网络上的多个节点 上，且通过网络实现了真正的物理分布 。而 逻辑上仍是一个 数据库 ， 为用户提供统一的访问入口，实现对分布在网络节 点上的数据的统一操作，即用户可以像使用传统集中式数据 库一样使用 分布式数据 库，而不是分别操作多个数据库。 1.2 分布式数据 库的主要技术 1.2.1 分布式事务处理技术 分布式数据 库为了保障跨多个节点的事务原子性、一致 性，一般使用分布式协议来处理分布式事务。常用两阶段提 交协议、三阶段提交协议保障事务的原子性；使用 Paxos、 RAFT 等协议 同步数据库事务日志从而保证分布式 事务的一 致性。 两阶段提交协议 在事务处理、网络通信等领域，两阶段提交（ tow-phase commit，下文简称 2PC）是一种常用的 原子性保障 协议。在 分布式事务场景下， 2PC 能够协调所有参与者共同达到 commit/rollback 的结果，保证事务的原子性。该协议分为两 步（ PREPARE， COMMIT），因此称为两阶段提交。 2PC 协议中包含两种角色，分别为协调者（ Coordinator） 和参与者（ Participant）。其中协调者推动参与者执行，负责 整个协议的推进，从而最终达到一致的决议。参与者负责提 出决议并接受决议。协调者收到 COMMIT/ROLLBACK 的命 令，开启两阶段提交。 在没有宕机的 情况 下， 2PC 很好地 完成了事务提交原子 性保证 ， 但如果协调者收齐所有的 prepare 完成 之后发生宕 机，此时参与者会一直等待协调者恢复， 2PC 的状态机会卡 住，无法推进。因此 2PC协议是一个阻塞性协议，机器宕机 情况 下 会 影响系统的可用性。 图 1-1二阶段协议步骤 三阶段提交协议 为了解决 2PC 协议宕机 情况 下状态机卡住的问题，三阶 段提交协议（ Three-Phase Commit， 3PC）诞生了。 3PC 是为 了解决两阶段提交的阻塞问题，即在执行过程中需要锁住其 他更新且不能容错的缺点，而在两阶段协议上进行的改进。 阶段节点的角色分配与两阶段协议一致，执行过程上， 3PC 协议在 2PC 基础之上，增加了一个 PRE_COMMIT 阶段。 针对 2PC的问题，参与者宕机重启之后，会问其他参与 者的状态，如果其他参与者均处于 PREPARE 阶段，则该参 与者告诉其他参与者事务回滚。如果其他参与者至少有一个 出于 PRE_COMMIT 或者 COMMIT 阶段，则通知所有参与 者事务提交。因此，有了 3PC 协议，即使协调者宕机，参与 者也能通过回查其他参与 者的状态，把事务状态机推进结束。 Paxos 协议 Paxos 协议用来解决的问题可以用一句话来 概括 ：将所 有节点都写入同一个值，且被写入后不再更改。 Paxos 协议 涉及三个角色，提议发起者（ Proposer），提议接受者（ Acceptor） 和提议学习者（ Learner）。提议发起者 Proposer可以有多个， 提出议案（ Value），但对同一轮 Paxos 过程，最多只有一个 Value被批准。提议接受者 Acceptor有 N个， Proposer 提出 的 Value必须获得超过半数 (N/2+1)的 Acceptor批准后才能 通 过。 Acceptor 之间完全对等独立。上面提到只要超过半数 Accpetor 通过即可获得通过，那么提议学习者 Learner 角色 的目的就是把通过的确定性取值同步给其他未确定的 Acceptor。 图 1-2 paxos协议图解 Raft协议 Raft协议是 Paxos 协议的一种简化实现。包括三种角色： Leader， Candidate 和 Follower。所有节点都以 Follower的状 态开始，如果没有收到 Leader消息则会变成 Candidate状态。 Candidate会向其他节点拉选票，如果得到大部分的票则成为 Leader，这个过程是 Leader 选举。相比 Paxos， Raft 强化了 节点间的日志同步，在领导者选举方面和选举之后的日志同 步方面更加清晰，算法的详细过程本报告不再赘述。 Raft 相较于 Paxos 有大幅度的简化且在分布式一致性上 具有完全等价的特性，这使得 Raft应用广泛 ， 但 Raft 相较于 Paxos 也有其自身的不足，主要体现在两个方面： 一是 Raft 相较于 Paxos 的并发度是不足的。 Paxos 支持 多 Leader，这本身就带来了并发度上的优势。其次，每一个 Paxos 节点能够同时进行多个投票而 Raft 则不支持，其 Follower 节点必须一个一个地处理投票，这两点就决定了在 并发度上 Raft 无法和 Paxos媲美。 二是 Raft 相较于 Paxos 在新节点加入的时候不太友好。 Paxos 在新节点加入的时候可以立刻投入服务不用确认节点 加入前的数据或日志，但是 Raft则不然，新的节点加入后首 先要进行日志复制操作，必须要等之前的日志得到确认之后 才能提供服务，这无疑带来了额外的风险。 在 分布式数据 库场景下，采用 Paxos/Raft 等协议在多个 副本之间同步数据库事务日志，确保至少一半以上数量的副 本中保存的事务日志一致，从而实现分布式事务 的一致性。 1.2.2 分布式存储技术 分布式数据 库一般采用无共享（ Shared-nothing）架构， 数据分布在网络上多个互联的节点上，这样做有多种 好处 ： 1）数据量、读取负载、写入负载超过单台机器的处理能 力。 2） 满足 容错和高可用需求，单台机器（或多台机器、网 络或整个数据中心）出现故障的情况下，仍然能继续工作。 多台机器可以提供冗余，一台出现故障，另一台可以接管。 3）降低延迟，每个用户可以从地理上最近的数据中心获 取服务，避免等待数据包 远距离传输 。 数据分布 存储 有两种常见方式：复制（ Replication）和分 区 (Partitioning)，两者 通常结合使用，使得每个分区的副本存 储在多个节点上。这意味着，即使每条记录属于一个分区， 它仍然可以存储在多个不同的节点上以获得容错能力。 数据分区技术 对于数据量很大的数据集，将数据进行拆分，分布存储 在不同物理节点上，每个节点存储全部数据的一个子集，这 种对数据进行拆分的方式叫做分区（ partition）。不同数据库 中对分区的名称定义有所差异，有些称之为分区（ partition）， 有些称之为分片（ sharding），还有一些称之为区域（ Region）， 但是其含义都是基本相同的。 分区可以采用不同的策略，如 Hash、 Range、 List等。分区的目标是将大量数据和访问请求 均匀分布在多个节点上。 分区的优点一是提高可扩展性，一个表的不同分区可以 分布在不同的机器上，使得单表的容量可以超过单机的容量。 二是提高可管理性，对于数据操作的粒度可以控制在单个分 区，例如按照时间分区的数据，可以通过删除 一个分区来实 现数据过期功能。三是提高性能，通过分区裁剪，可以快速 定位到用户需要查询的分区，提高查询性能。 数据复制技术 数据复制是一种实现数据备份的技术，指 在 不同节点上 保存相同的数据副本，提供冗余。当一 个节点故障后，可以 从其他存储该数据的节点获取数据，避免数据丢失，进而提 高了系统可靠性。 分布式数据 库一般具有多个副本，副本间 通过 Paxos 或 Raft协议保证副本间的数据强一致。 1.3 分布式数据 库的分类 分布式数据 库 分类与 传统集中式关系数据库 相似 ，按对 数据处理的方式不同一般分为两类：联机事务处理、联机分 析处理。随着技术的发展，用户对于数据库的要求越来越高， 事务处理类的数据库在满足功能、性能时，还需要有一定的 数据分析能力 ， 因此目前 分布式数据 库又产生一个新的分类 混合事务分析处理 。 1.3.1 联机事务处理 联机事务处理（ On-Line Transaction Processing， OLTP） 是事件驱动、面向应用的，也称为面向交易的处理过程。其 基本特征是前台接收的用户数据可以立即传送到计算中心 进行处理，并在很短的时间内给出处理结果，是对用户操作 的快速响应。例如银行类、电子商务类的交易系统就是典型 的 OLTP系统。其具备以下特点： 直接面向应用，数据在系统中产生。 基于交易的处理系统。 每次交易牵涉的数据量很小；对响应时间要求非常高。 用户数量非常庞大，其用户是操作人员，并发度很高。 数据库的各种操作主要基于索引进行。 以 SQL作为交互 载体。 总体数据量相对较小。 1.3.2 联机分析处理 联机 分 析 处理 （ On-Line Analytical Processing， OLAP） 是面向数据分析的，也称为面向信息分析处理过程。它使分 析人员能够迅速、一致、交互地从各个方面观察信息，以达 到深入理解数据的目的。其特征是应对海量数据，支持复杂 的分析操作，侧重决策支持，并且提供直观易懂的查询结果。 例如数据仓库是典型的 OLAP系统。其具备以下特点： 本身不产生数据，其基础数据来源于生产系统中的操 作数据 。 基于查询的分析系统；复杂查询经常使用多表联结、 全表扫描等，牵涉的数量往往十分庞大 。 每次查询设计的数据量很大，响应时间与具体查询有 很大关系 。 用户数量相对较 少 ，其用户主要是业务人员与管理人 员 。 由于业务问题不固定，数据库的各种操作不能完全基 于索引进行 。 以 SQL为主要载体，也支持语言类交互 。 总体数据量相对较大 。 1.3.3 混合事务分析处理 混合事务分析处理（ Hybrid Transaction/Analytical Process， HTAP） 由 Gartner 于 2014年提出。目前 HTAP 方案主流大 体有两个方向，根据 OLTP和 OLAP 负载是否使用相同的节 点或者引擎，分为统一架构和分离架构。 1）统一架构的特点是一个节点同时提供 OLTP和 OLAP 能力，存储结构上通常使用行列混合的架构。 2）分离架构采用不同的子系统实现 OLTP 和 OLAP 功 能，中间使用高效的同步协议把 OLTP 子系统的数据更新实 时同步到 OLAP子系统，而用户层（ SQL）可以自动选择最 优的数据源。 HTAP 避免了繁琐且昂贵的 ETL（抽取、转换、加载） 操作，而且可以更快地对最新数据进行分析。这种快速分析 数据的能力将成为未来企业的核心竞争力之一。主要特点如 下： 底层数据要么只有一份，要么可快速复制，并且同时满 足高并发的实时更新。 满足海量数据的容量问题，在存储、计算都具有很好的 线性扩展能力。 具有很好的优化器，可满足事务类、分析类的语句需求。 具备标准的 SQL，并支持诸如二级索引、分区、列式 存储等技术。 2 分布式数据 库发展的现状及问题 2.1 分布式数据 库的发展现状 2.1.1 技术 现状 相比于集中式数据 库 ， 分布式数据 库具有平滑扩展、高 可靠、高可用、低成本等关键特性和显著优点。目 前部分 分 布式数据 库实现了分布式事务的强一致性，保证分布式事务 的 ACID 要求，为 分布式数据 库在关键领域的领域奠定了基 础，而且成熟的 分布式数据 库透明性较好，上层应用系统可 以像使用集中式数据库一样使用 分布式数据 库事务，无需关 注 分布式数据 库的内部细节。 平滑扩展与高性能。 分布式数据 库的最大优势就是可以 平滑 地 进行节点扩展，这样使得在系统运行初期， 分布式数 据 库暂时不需要规划部署大量机器，随着业务增长，可动态 增加节点，提升整体存储容量和处理性能，同时实现了业务 无感知的平滑扩容，以满足业务连续性要求。正是通过这种 扩展能力，使得 分布式数据 库通过机器横向堆叠实现存储容 量和处理性能的提升，突破了集中式数据库由于硬件配置带 来的存储和性能限制，以满足海量数据存储和高并发处理要 求，可以达到几十万级 TPS、百万级 QPS 以上的处理性能。 容灾备份与高可靠。 分布式数据 库通常都会采用多副本 机制，比如三副本或五副本，一份数据在多个节点上保 存， 副本间通过 Raft、 Paxos 等一致性协议保证数据一致性。当 某个节点或者 部分 节点故障时，数据不会丢失，上层业务不 受影响。在多地多活的分布式方案中， 分布式数据 库亦可以 实现分布式单元化架构，保证数据一致性的前提下，向外提 供稳定可靠高效的服务能力。 分布式数据 库的多副本机制实 现了系统的容灾能力，提升系统可靠性。 高可用。 可用性一般是指在要求的外部资源得到保证的 前提下，系统在规定的条件下和规定的时间内（不包括计划 内服务中断时间）处于可执行规定功能状态的能力，一般按 允许计划外年服务中断时间 、 可用程度至少达到 “n个 9”来衡 量。比如一个服务如果有 5个 9的可用性，指的就是一年里 99.999%时间里服务都是可用的。由于 分布式数据 库采用了 多副本及分布式事务处理等机制，使得其可以保证较高的可 用性，以适应金融等一些关键领域的技术要求。需要说明的 是，根据 Brewer 等人的分布式系统 CAP 理论，不存在一个 分布式系统，既能保证数据一致性（ C），也能保证可用性（ A）， 还能保证分区容错性（ P）。所以通常情况下，一般的 分布式 数据 库会选择 CA 或者 CP，或者牺牲一部分 C 来换取 A 的 提升。 低成本。 分布式数据 库一般基于通用的 PC 服务器和操 作系统，数据 也存储在本地磁盘中，使得在硬件成本上，比 传统小型机和高端磁阵有明显优势。特别是在节点扩展到一 定规模后，不仅实现了集中式数据库无法实现的高并发，而 且单个事务处理消耗的成本也会比集中式数据库显著降低。 2.1.2 重点领域应用 2.1.2.1 互联网领域 互联网是 分布式数据 库 首先被 重点应用 的 领域。从成本 考虑，随着数据量 和 系统访问量增加 ， 依赖纵向扩展的传统 数据库架构，采用小型机、磁阵和商用数据库软件的购买和 维护成本会越来越高。而采用廉价 PC 服务器 、 使用本地存 储的 分布式数据 库，成本显著下降，同时还带来良好的系统 成长性。另外，互联网应用，包括各 种大促、春节抢票、秒 杀等场景，都有短时间内并发量激增的情形。如果按照业务 峰值提前采购计算资源，必 然会 导致资源浪费。 借助 分布式 数据 库的弹性扩缩容的能力，能更好满足业务场景的需求， 并 避免资源浪费。 以淘宝为例，成立至今，淘宝已积攒了万亿级海量订单 数据，百亿级图片数据。从 2009 年第一个双十一，到 2020 年双十一，订单峰值从 400 笔 /秒提升到 58.3 万笔 /秒，增长 1500倍。如此海量的数据 和 高并发的数据库访问请求，远远 突破了单点设备所能提供的存储容量 和 计算能力上限，纵使 再优秀的传统集中式数据库 也 无法支撑。 2014年 开始 ，淘宝 逐渐用其 OceanBase 分布式数据 库替换 Oracle数据库 ，并最 终支持 支付宝内部全部业务 。 OceanBase 的实践，证明 分布 式数据 库适用于互联网应用场景，现在越来越多的互联网应 用运行在 分布式数据 库之上。 2.1.2.1 金融领域 金融领域是使用 分布式数据 库的另一个重要场景，但和 互联网在应用场景、技术条件和关键诉求上存在显著差异。 以分布式事务一致性方案为例，互联网普遍采用最终一致性 方案以获得更高的性能，同时对该方案存在的同步阻塞、数 据脏读等 问题，需要应用代码参与控制一致性，互联网企业 因为应用和数据库都是自己开发，所以不存在相互配合等问 题。但金融核心业务要求数据库必须支持强一致性方案，这 是金融行业对数据正确性的基本要求，同时也是减少现有第 三方开发的数百个应用迁移和改造成本的必然要求。 目前金融核心业务架构普遍采用 “大 /小机 +Oracle/DB2” 集中式数据库系统。一方面随着我国经济和科技，尤其是移 动支付的发展，现有系统已无法满足金融类企业高安全、高 性能、低成本及高质量等要求；另一方面随着国际形势的变 化，现有系统可能会面临服务下降甚至断供的风险。 所以逐 步以自主可控的 分布式数据 库替换现有集中式数据库成为 金融行业的必然选择之一。 据了解，中信银行是最早完成核心业务基于国产 分布式 数据 库 GoldenDB 上线的大型银行，其数据库按照两地三中 心（北京生产机房、同城机房；合肥异地容灾机房）建设， 实现同城 RPO=0，异地 RPO=5s 的关键指标，满足金融行 业 5 个 9 以上的高可用要求。 2019 年 10月 26日，信用卡核 心投产，计算节点每中心 10台，数据节点 40个分片（部分 合设），三中心一主五备（ 2+2+2），约 200 台机器； 2020 年 5 月 3 日，账务核心投产，计算节点每中 心 20台，数据节点 40个分片，三中心一主七备（ 3+3+2），共 400台机器，至此 原来承载中信银行核心业务的 IBM AS400+DB2 正式下线。 2020年 10 月 31日，平安银行“ A+信用卡核心系统”正 式由腾讯云 TDSQL 分布式数据 库承载。系统基于 分布式架 构， 采用 私有云和 PssS平台建设， 实现 了应用微服务化， 能 够 按客户维度进行分片， 行方 所有的客户的业务均可以在单 个分片完成，包括交易授权、用卡业务，也包括 行方 的批量 业务 ，通过 shard-nothing 分布式架构，可以实现透明水平扩 容 。系统 采用 两地三中心的部署架构 ， 主机房在深圳的观澜 区（ 1 主 1备），备机房分别在深圳的福田区（ 2备）和上海 （ 2 备）。福田作为同城灾备中心，在观澜本地的主机和备机 都出现问题时，会自动切换到福田的机房 ， 上海作为异地灾 备中心 。 达梦透明 分布式数据 库于 2019 年上线某国有大行的员 工一体化系统，面向该行国内 30 多万员工的 人力资源服务 业务，在业务复杂度和系统并发度方面，对 分布式数据 库形 成较高挑战。同时该项目还是首个基于国产 CPU 的 分布式 数据 库的成功上线案例，从软件层面较好的解决了国产 CPU 系统性能问题，并能支撑 30 万用户的压力 ，通过 1 主 2 副 的数据 3 副 本方案，提供数据冗余保护。 易鲸捷公司的 分布式数据 库产品“钱库”与长亮公司的 “ V7”应用在 2020 年 4 月 5 日正式在贵阳银行核心沙箱项 目上线。该项目引入了全国产化解决方案，并涵盖了贵阳银 行的 各类业务，包括：客户、存款、贷款、借记卡、结算、 中间业务、核算、机构、柜员、现金、权限以及互联网业务 等 。该项目首次提出“双库并行”的技术架构，通过新建一 套核心应用系统集群 B 基于 钱库 数据库运行，并 与 原核心业 务 系统并行 ，实现了两个系统间的秒级切换，在系统平滑过 渡的同时也实现了业务层面的“灾备”。 这些 项目的成功投产和稳定运行， 证明 分布式数据 库可 以满足金融核心领域高安全、高性能、低成本及高质量等要 求。 2.2 分布式数据 库发展面临的问题 分 布式数据 库 虽然具备独特 技术 应用 优势， 但其发展也 面临一系列问题 。 2.2.1 应用系统面对 分布式数据 库的合理选择问题 按照 CAP 理论，分布式系统不可能同时满足一致性 (Consistency)、可用性 (Availability)和分区容错性 (Partition tolerance)，而最多只能同时满足其中两个。在分布式系统中， 由于网络可能会出现延迟 、 丢包甚至中断等问题，导致分区 容错性是必须要实现的，因此一般在一致性和可用性之间进 行权衡，而不同的应用系统对一致性、可用性和性能的要求 各不相同。例如 ,很多互联网应用对一致性要求相对较低，但 希望可用性较高；而金融核心应用常常需要优先保证较高的 一致性又要保证 5 个 9 及 以上的高可用。因此，在 CAP 理论 约束下，如何根据应用的特点从种类繁多的 分布式数据 库系 统中做出合理选择，是大多数软件开发人员面临的一大难题。 图 2-1 CAP理论示意图 2.2.2 遗留系统面对 分布式数据 库的迁移改造问题 分布式数据 库的本质是在全局范围内，通过各 种调度设 计保证多个具备集中式数据库功能的单节点数据库协同工 作。在集中式数据库中应用比较成熟的存储过程、触发器、 视图、 DBLink、外键约束等功能需要迁移到全局层面实现， 实现难度较大。即使部分 分布式数据 库已经实现上述功能， 也可能是受限使用，并且执行效率低于集中式数据库。上层 业务在实现或者改造时，需要额外关心数据模型，数据模型 的主要工作是设计数据和数据之间的关系，后续的业务实现 是围绕数据关系实现相应的逻辑。考虑到硬件开销和充分发 挥性能优势，数据模型要考虑本数据及其相关的一组数据的 数据分布规则，后续的应用实现也需 要考虑这点，例如要尽 力避免分布式事务。如果分区设计良好， 分布式数据 库将表 现出非常高的并发能力和水平扩展特性，从而使迁移至 分布 式数据 库的应用受益，反之可能影响整体系统的性能。 值得注意的是，目前大量的外围业务由于功能杂、关联 数据多、复杂语句比例高，使用了较多的集中式数据库的特 定语法或者功能，迁移到新的 分布式数据 库上必须充分评估 改造和迁移工作量、投入收益比。相反不少核心业务一方面 因为性能要求高、业务相对简单等原因使用集中式数据库的 特定语法和功能要比外围应用少得多，另外一方面核心业务 改造迁移后可以获得原来不具备的 高可用、高性能等收益。 2.2.3 分布式数据 库运维管理 较为复杂 分布式数据 库 通常由几十台至数千台服务器组成，相对 于传统集中式数据库， 分布式数据 库的硬件、软件维护都是 非常大的挑战，对运维人员要求很高，这也是为什么 分布式 数据 库在互联网和金融领域率先应用的原因之一，因为互联 网企业和金融机构的运维队伍水平较高， 这就需要 数据库厂 商提供简单、方便的统一图形化运维管理控制平台，实现一 些常用的运维操作，比如：服务器资源管理、创建 /删除数据 库集群、查看集群状态信息、监控各个节点 /核心组件的运行 情况、备份、恢复等，以来降低 分布式数据 库的日常运维难 度，方便 分布式数据 库使用。未来还要考虑借助人工智能等 技术 进一步降低运维工作量和难度。 2.2.4 分布式数据 库产品成熟度 有待提升 相比于集中式数据库， 分布式数据 库还处于发展的初期， 自身的技术体系、标准规范、测评机制、产品推广等方面尚 不健全，甚至很多用户单位对 分布式数据 库 的理解也不尽相 同 。 分布式 数据 库 的优化器、数据类型、复杂查询、自定义 函数、存储过程等高级特性参差不齐，有待进一步提升 ， 而 传统集中式数据库已经过数十年的发展，语法丰富、功能完 善，部分主流集中式 数据库在标准的 SQL基础上衍生出很多 该数据库的特殊用法，应用系统如果过多的使用了这些特殊 用法，在迁移到 分布式数据 库时，语法适配改造通常会异常 困难，是推广 分布式数据 库使用的一大门槛。 3 分布式数据 库发展趋势 3.1 分布式数据 库的产品化日趋成熟 随着国产 分布式数据 库在金融、互联网等重点行业中的 应用，促使产品技术不断迭代，兼容性、易用性、可扩展性 等问题将一一克服。未来随着 分布式数据 库等的标准体系及 评价体系的健全， 分布式数据 库产品的生态体系也将逐渐完 善，在运维保障、数据迁移、运行监测等方面的配套工具也 将逐步成熟。 3.2 与人工智 能等新技术融合实现高效运维 在数字经济的推动下，数据的全生命周期管理尤为重要， 而 分布式数据 库数据通常由几十台至数千台服务器组成，数 据库的运维显得尤为重要。随着人工智能技术的发展，将人 工智能技术融入 分布式数据 库的全生命周期，实现自运维、 自管理、自调优、故障自诊断和自愈，是未来发展的必然趋 势。另外，在交易、分析和混合负载场景下，可以通过人工 智能的学习算法，实现数据库的自动调优。 3.3 分布式数据 库的服务方式将向云化发展 云计算技术已在我国各行业信息化建设中大规模应用， 为适应未来信创领域 信息化建设技术方向，降低数据库运维 成本，灵活调度资源，国内数据库厂商积极布局云数据库产 品及服务。阿里云、腾讯云、华为等已经发布了基于自有云 平台的云数据库产品，传统数据库厂商达梦也推出云数据库 产品。总体上，国内云数据库与国际先进水平基本持平，为 未来信创云数据库发展提供良好基础。 4 分布式数据 库发展路径建议 目前，国内绝大部分数据库企业均推出了 分布式数据 库 产品，我国 分布式数据 库发展基本与国际同步，在一些技术 指标 和应用层面处于领先水平，而且互联网、金融等领域应 用场景对 分布式数据 库具有切实需求， 当前 应大力发展 分布 式数 据 库的技术产品， 加快行业应用，促进 数据库产业 高质 量 发展。 4.1 政策引导，形成 分布式数据 库的典型案例 客观的说， 分布式数据 库不是传统集中式数据库的更新 换代，而是充分结合分布式计算技术，使得在一定规模的节 点和付出一定规模的成本后，实现了较高的性能水平，并不 是所有的应用场景都适合使用 分布式数据 库，既没有必要神 话 分布式数据 库的作用，也不应该去贬低其作用。因此我们 希望 在政产学研用 等多方 努力下 ，共同打造 分布式数据 库的 最佳实践，树立一批典型的行业解决方案，并加以宣传推广 4.2 产用协同，提升 分布式数据 库产品成熟度 分布式数据 库作为数据库领域的创新，目前其产品化程 度不高，甚至目前的一些所谓 分布式数据 库产品，其实更像 是产品与应用融合后的解决方案，并不利于市场推广。因此 我们建议充分利用好数据库 以及 基础软件领域的创新中心、 适配基地及重点实验室等机构，加强供需双方的产用协同， 形成良性的问题反馈机制，共同解决一些共性的技术和产品 问题，逐步打磨优秀的 分布式数据 库产品。 4.3 营造环境，打造 分布式数据 库的生态体系 从产业发展角度来看，相比于集中式数据库， 分布式数 据 库还处于发展的初期，技术体系、标准规范、测评机制、 产品推广等方面尚不健全 。建 议第三方研究 和服务机构前 牵 头 ，联合推进技术标准、测评认证、迁移验证、示范试点等 工作，共同营造良性的 分布式数据 库生态体系。目前华为、 PingCAP 等企业发起了 国产 数据库的开源社区，并形成了部 分商业发行版产品，这可能也是建设 分布式数据 库生态体系 的新思路。