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

《分布式数据库发展路径研究7622.pdf》由会员分享，可在线阅读，更多相关《分布式数据库发展路径研究7622.pdf（13页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、分布式数据库发展路径研究 相比集中式数据库，分布式数据库具有平滑扩展、高可靠、高可用、低成本等关键特性和显著优点，特别是在性能方面可突破集中式数据库的瓶颈，具有很强的研究和应用价值。分布式数据库是传统数据库技术与计算机网络的有机结合，相比于传统的单机或主备模式的集中式数据库，分布式数据库在平滑扩展、高性能、高可靠、高可用、低成本、容灾备份等方面具有优势，特别是在性能方面可突破集中式数据库的瓶颈，具有很强的研究和应用价值，目前很多数据库企业研发了分布式数据库产品，并在金融、电信、互联网等重点行业进行了成功应用，具有良好的发展前景。本报告旨在梳理分布式数据库的技术体系和应用现状，结合金融、互联网等

2、领域的应用需求，分析制约分布式数据库大规模应用的因素，对未来的技术和应用趋势进行研判，并提出发展路径建议。分布式数据库的概念及分类 分布式数据库的概念 分布式数据库最早于 20 世纪 80 年代提出，受限于当时的计算机软硬件及网络发展水平，数据库专家 M.Tamer?zsu 和 Patrick Valduriez 在经典著作分布式数据库系统原理（第 3 版）中，把分布式数据库定义为一群分布在计算机网络上、逻辑上相互关联的数据库。随着信息技术的发展，集中式数据库也正向基于网络的共享集群路线发展，而市场上的分布式数据库也不仅限于网络分布、逻辑关联等特性，经典的分布式数据库定义显然已不能体现分布式数

3、据库当前的技术特点，难以满足数据库种类区分的要求。根据目前我国分布式数据库技术现状，我们认为分布式数据库是具备分布式事务处理能力、可平滑扩展、分布于计算机网络且逻辑上统一的数据库，主要特征如下。第一，分布式事务处理。分布式数据库与集中式数据库的主要区别在于是否具备分布式事务的处理能力。通过对数据库各种操作的并行计算、全局事务管理等机制，实现真正的分布式事务处理，并实现与集中式数据库一致的 ACID 特性。第二，平滑扩展。分布式数据库可根据业务的增长需要，动态扩展物理节点，以提升整体处理能力，且扩展过程不需停机，不影响在线业务。理论上可以进行无限扩展，扩展之后在逻辑上仍然是一个统一的数据库。第三

4、，物理分布、逻辑统一。分布式数据库的数据不是存储在一个物理节点中，而是存储在计算机网络上的多个节点上，且通过网络实现了真正的物理分布。而逻辑上仍是一个数据库，为用户提供统一的访问入口，实现对分布在网络节点上的数据的统一操作，即用户可以像使用传统集中式数据库一样使用分布式数据库，而不是分别操作多个数据库。分布式数据库的主要技术 分布式事务处理技术 分布式数据库为了保障跨多个节点的事务原子性、一致性，一般使用分布式协议来处理分布式事务。常用两阶段提交协议、三阶段提交协议保障事务的原子性；使用 Paxos、RAFT 等协议保障事务的一致性。两阶段提交协议：在事务处理、网络通信等领域，两阶段提交（to

5、w-phase commit，下文简称 2PC）是一种常用的分布式一致性协议。在分布式事务场景下，2PC 能够协调所有参与者共同达到 commit/rollback 的结果，保证事务的原子性。该协议分为两步（PREPARE，COMMIT），因此称为两阶段提交。2PC协 议 中 包 含 两 种 角 色，分 别 为 协 调 者（Coordinator）和 参 与 者（Participant）。其中协调者推动参与者执行，负责整个协议的推进，从而最终达到一致的决议。参与者负责提出决议并接受决议。协调者收到COMMIT/ROLLBACK 的命令，开启两阶段提交。在没有宕机的情况下，2PC 很好地完成了事

6、务提交原子性保证，但如果协调者收齐所有的 prepare 完成之后发生宕机，此时参与者会一直等待协调者恢复，2PC 的状态机会卡住，无法推进。因此 2PC 协议是一个阻塞性协议，在机器宕机情况下会影响系统的可用性。三阶段提交协议：为了解决 2PC 协议在宕机情况下状态机卡住的问题，三阶段提交协议（Three-Phase Commit，3PC）诞生了。3PC 是为了解决两阶段提交的阻塞问题，即在执行过程中需要锁住其他更新且不能容错的缺点，而在两阶段协议上进行的改进。阶段节点的角色分配与两阶段协议一致，在执行过程中，3PC 协议在 2PC 基础之上，增加了一个 PRE_COMMIT 阶段。针对2P

7、C 的问题，参与者宕机重启之后，会问询其他参与者的状态，如果其他参与者均处于 PREPARE 阶段，则该参与者告诉其他参与者事务回滚。如果其他参与者至少有一个处于 PRE_COMMIT 或者 COMMIT 阶段，则通知所有参与者事务提交。因此，有了 3PC 协议，即使协调者宕机，参与者也能通过回查其他参与者的状态，把事务状态机推进结束。Paxos 协议：Paxos 协议用来解决的问题可以用一句话来概括：将所有节点都写入同一个值，且被写入后不再更改。Paxos 协议涉及三个角色，提议发起者（Proposer），提议接受者（Acceptor）和提议学习者（Learner）。提议发起者可以有多个，他

8、们都可以提出议案（Value），但对同一轮 Paxos 过程，最多只有一个 Value 被批准。提议 Acceptor 有 N 个，发起者提出的 Value必须获得超过半数(N/2+1)的接受者批准后才能通过。Acceptor 之间完全对等独立。上面提到只要超过半数 Acceptor 通过即可获得通过，那么提议学习者角色的目的就是把通过的确定性取值同步给其他未确定的 Acceptor。Raft 协议：Raft 协议是 Paxos 协议的一种简化实现。包括三种角色：Leader、Candidate 和 Follower。所有节点都以 Follower 的状态开始，如果没有收到 Leader 消息

9、则会变成 Candidate 状态。Candidate 会向其他节点拉选票，如果得到大部分的票则成为 Leader，这个过程是 Leader 选举。相比 Paxos，Raft 强化了节点间的日志同步，在领导者选举方面和选举之后的日志同步方面更加清晰。Raft 相较于 Paxos 有大幅度的简化且在分布式一致性上具有完全等价的特性，这使得 Raft 应用广泛。但 Raft 相较于 Paxos 也有其自身的不足，主要体现在两个方面：一方面，Raft 相较于 Paxos 的并发度是不足的。Paxos支持多 Leader，这本身就带来了并发度上的优势。其次，每一个 Paxos 节点能够同时进行多个投票

10、而 Raft 则不支持，其 Follower 节点必须一个一个地处理投票，这两点就决定了在并发度上 Raft 无法和 Paxos 媲美。另一方面，Raft 相较于 Paxos 在新节点加入的时候不太友好。Paxos 在新节点加入的时候可以立刻投入服务不用确认节点加入前的数据或日志，但是 Raft 则不然，新的节点加入后 Raft 要进行日志复制操作，必须要等之前的日志得到确认之后才能提供服务，这无疑带来了额外的风险。分布式存储技术：分布式数据库一般采用无共享（Shared-nothing）架构，数据分布在网络上多个互联的节点上，这样做有多种好处：数据量、读取负载、写入负载超过单台机器的处理能力

11、；满足容错和高可用需求，单台机器（或多台机器、网络或整个数据中心）出现故障的情况下，仍然能继续工作，多台机器可以提供冗余，一台出现故障，另一台可以接管；降低延迟，每个用户可以从地理上最近的数据中心获取服务，避免等待数据包远距离传输。数 据 分 布 存 储 有 两 种 常 见 方 式：复 制（Replication）和 分 区(Partitioning)，两者通常结合使用，使得每个分区的副本存储在多个节点上。这意味着，即使每条记录属于一个分区，它仍然可以存储在多个不同的节点上以获得容错能力。数据分区技术：对于数据量很大的数据集，将数据进行拆分，分布存储在不同物理节点上，每个节点存储全部数据的一个

12、子集，这种对数据进行拆分的方式叫做分区（partition）。不同数据库中对分区的名称定义有所差异，有些称之为分区（partition），有些称之为分片（sharding），还有一些称之为区域（Region），但是其含义都是基本相同的。分区可以采用不同的策略，如 Hash、Range、List 等。分区的目标是将大量数据和访问请求均匀分布在多个节点上。分区的优点有：一是提高可扩展性，一个表的不同分区可以分布在不同的机器上，使得单表的容量可以超过单机的容量。二是提高可管理性，对于数据操作的粒度可以控制在单个分区，例如按照时间分区的数据，可以通过删除一个分区来实现数据过期功能。三是提高性能，通过分

13、区裁剪，可以快速定位到用户需要查询的分区，提高查询性能。数据复制技术：数据复制是一种实现数据备份的技术，指在不同节点上保存相同的数据副本，提供冗余。当一个节点故障后，可以从其他存储该数据的节点获取数据，避免数据丢失，进而提高了系统可靠性。分布式数据库一般具有多个副本，副本间通过Paxos或Raft协议保证副本间的数据强一致。分布式数据库的分类 分布式数据库分类与传统集中式关系数据库相似，按对数据处理的方式不同一般分为两类：联机事务处理、联机分析处理。随着技术的发展，用户对于数据库的要求越来越高，事务处理类的数据库在满足功能、性能时，还需要有一定的数据分析能力，因此目前分布式数据库又产生一个新的

14、分类混合事务分析处理。联机事务处理（On-Line Transaction Processing，OLTP）是事件驱动、面向应用的，也称为面向交易的处理过程。其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作的快速响应。例如银行类、电子商务类的交易系统就是典型的 OLTP系统。其具备以下特点：直接面向应用，数据在系统中产生；基于交易的处理系统；每次交易牵涉的数据量很小；对响应时间要求非常高；用户数量非常庞大，其用户是操作人员，并发度很高；数据库的各种操作主要基于索引进行；以 SQL 作为交互载体；总体数据量相对较小。联机分析处理（On-Li

15、ne Analytical Processing，OLAP）是面向数据分析的，也称为面向信息分析处理过程。它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。其特征是应对海量数据，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。例如数据仓库是典型的 OLAP 系统。其具备以下特点：本身不产生数据，其基础数据来源于生产系统中的操作数据；基于查询的分析系统；复杂查询经常使用多表联结、全表扫描等，牵涉的数量往往十分庞大；每次查询设计的数据量很大，响应时间与具体查询有很大关系；用户数量相对较少，其用户主要是业务人员与管理人员；由于业务问题不固定，数据库的各种操

16、作不能完全基于索引进行；以 SQL 为主要载体，也支持语言类交互；总体数据量相对较大。混合事务分析处理（Hybrid Transaction/Analytical Process，HTAP）由 Gartner 于 2014 年提出。目前 HTAP 方案主流大体有两个方向，根据 OLTP和 OLAP 负载是否使用相同的节点或者引擎，分为统一架构和分离架构。统一架构的特点是一个节点同时提供 OLTP 和 OLAP 能力，存储结构上通常使用行列混合的架构。分离架构采用不同的子系统实现 OLTP 和 OLAP 功能，中间使用高效的同步协议把 OLTP 子系统的数据更新实时同步到 OLAP 子系统，而用

17、户层（SQL）可以自动选择最优的数据源。HTAP 避免了繁琐且昂贵的 ETL 抽取、转换、加载）操作，而且可以更快地对最新数据进行分析。这种快速分析数据的能力将成为未来企业的核心竞争力。其主要特点如下：底层数据要么只有一份，要么可快速复制，并且同时满足高并发的实时更新；满足海量数据的容量问题，在存储、计算都具有很好的线性扩展能力；具有很好的优化器，可满足事务类、分析类的语句需求；具备标准的 SQL，并支持诸如二级索引、分区、列式存储等技术。分布式数据库发展的现状及问题 分布式数据库的发展现状 技术现状 相比于集中式数据，分布式数据库具有平滑扩展、高可靠、高可用、低成本等关键特性和显著优点。目前

18、部分分布式数据库实现了分布式事务的强一致性，保证分布式事务的 ACID 要求，为分布式数据库在关键领域奠定了基础，而且成熟的分布式数据库透明性较好，上层应用系统可以像使用集中式数据库一样使用分布式数据库事务，无需关注分布式数据库的内部细节。平滑扩展与高性能：分布式数据库的最大优势就是可以平滑地进行节点扩展，这样使得在系统运行初期，分布式数据库暂时不需要规划部署大量机器，随着业务增长，可动态增加节点，提升整体存储容量和处理性能，同时实现了业务无感知的平滑扩容，以满足业务连续性要求。正是通过这种扩展能力，使得分布式数据库通过机器横向堆叠实现存储容量和处理性能的提升，突破了集中式数据库由于硬件配置带

19、来的存储和性能限制，以满足海量数据存储和高并发处理要求，可以达到几十万级 TPS、百万级 QPS 以上的处理性能。容灾备份与高可靠：分布式数据库通常都会采用多副本机制，比如三副本或五副本，一份数据在多个节点上保存，副本间通过 Raft、Paxos 等一致性协议保证数据一致性。当某个节点或者部分节点故障时，数据不会丢失，上层业务不受影响。在多地多活的分布式方案中，分布式数据库亦可以实现分布式单元化架构，在保证数据一致性的前提下，能够向外提供稳定可靠高效的服务能力。分布式数据库的多副本机制实现了系统的容灾能力，提升了系统可靠性。高可用：可用性一般是指在要求的外部资源得到保证的前提下，系统在规定的条

20、件下和规定的时间内（不包括计划内服务中断时间）处于可执行规定功能状态的能力，一般按允许计划外年服务中断时间、可用程度至少达到“n个9”来衡量。比如一个服务如果有5个9的可用性，指的就是一年里99.999%时间里服务都是可用的。由于分布式数据库采用了多副本及分布式事务处理等机制，使得其可以保证较高的可用性，以适应金融等一些关键领域的技术要求。需要说明的是，根据 Brewer 等人的分布式系统 CAP 理论，不存在一个分布式系统，既能保证数据一致性（C），也能保证可用性（A），还能保证分区容错性（P）。所以通常情况下，一般的分布式数据库会选择 CA 或者 CP，或者牺牲一部分 C 来换取 A 的提

21、升。低成本：分布式数据库一般基于通用的 PC 服务器和操作系统，数据也存储在本地磁盘中，使得在硬件成本上，比传统小型机和高端磁阵有明显优势。特别是在节点扩展到一定规模后，不仅实现了集中式数据库无法实现的高并发，而且单个事务处理消耗的成本也会比集中式数据库显著降低。重点领域应用 互联网领域：互联网是分布式数据库被重点应用的领域。从成本考虑，随着数据量和系统访问量增加，依赖纵向扩展的传统数据库架构，采用小型机、磁阵和商用数据库软件的购买和维护成本会越来越高。而采用廉价 PC 服务器、使用本地存储的分布式数据库，成本显著下降，同时还带来良好的系统成长性。另外，互联网应用，包括各种大促、春节抢票、秒杀

22、等场景，都有短时间内并发量激增的情形。如果按照业务峰值提前采购计算资源，必然会导致资源浪费。借助分布式数据库的弹性扩缩容的能力，能更好地满足业务场景的需求，并避免资源浪费。以淘宝为例，成立至今，淘宝已积攒了万亿级海量订单数据，百亿级图片数据。从 2009 年第一个双 11 到 2020 年双 11，订单峰值从 400 笔/秒提升到 58.3 万笔/秒，增长 1500 倍。如此海量的数据和高并发的数据库访问请求，远远突破了单点设备所能提供的存储容量和计算能力上限，纵使再优秀的传统集中式数据库也无法支撑。2014 年开始，淘宝逐渐用其 OceanBase 分布 式 数 据 库 替 换 Oracle

23、 数 据 库，并 最 终 支 持 支 付 宝 内 部 全 部 业务。OceanBase 的实践证明，分布式数据库适用于互联网应用场景，现在越来越多的互联网应用运行在分布式数据库之上。金融领域：金融领域是使用分布式数据库的另一个重要场景，但和互联网在应用场景、技术条件和关键诉求上存在显著差异。以分布式事务一致性方案为例，互联网普遍采用最终一致性方案以获得更高的性能，同时对该方案存在的同步阻塞、数据脏读等问题，需要应用代码参与控制一致性，互联网企业因为应用和数据库都是自己开发，所以不存在相互配合等问题。但金融核心业务要求数据库必须支持强一致性方案，这是金融行业对数据正确性的基本要求，同时也是减少现

24、有第三方开发的数百个应用迁移和改造成本的必然要求。目前金融核心业务架构普遍采用“大、小机+Oracle/DB2”集中式数据库系统。一方面随着经济和科技，尤其是移动支付的发展，现有系统已无法满足金融类企业高安全、高性能、低成本及高质量等要求；另一方面随着国际形势的变化，现有系统可能会面临服务下降甚至断供的风险。所以逐步以自主可控的分布式数据库替换现有集中式数据库成为金融行业的必然选择之一。据了解，中信银行是最早完成核心业务基于国产分布式数据库 GoldenDB上线的大型银行，其数据库按照两地三中心（北京生产机房、同城机房、合肥异地容灾机房）建设，实现同城 RPO=0，异地 RPO5s 的关键指标

25、，满足金融行业 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 平台建设，实现了应用微服务

26、化，能够按客户维度进行分片，行方所有的客户的业务均可以在单个分片完成，包括交易授权、用卡业务，也包括行方的批量业务，通过shard-nothing 分布式架构，可以实现透明水平扩容。系统采用两地三中心的部署架构，主机房在深圳观澜区（1 主 1 备），备机房分别在深圳的福田区（2 备）和上海（2 备）。福田作为同城灾备中心，在观澜本地的主机和备机都出现问题时，会自动切换到福田的机房，上海作为异地灾备中心。达梦透明分布式数据库是于 2019 年上线某国有大行的员工一体化系统，为该行国内 30 多万员工的人力资源业务服务。在业务复杂度和系统并发度方面，这一案例对分布式数据库形成较高挑战。同时该项目还

27、是首个基于国产 CPU 的分布式数据库的成功上线案例，从软件层面较好的解决了国产 CPU 系统性能问题，并能支撑 30 万用户的压力，通过 1 主 2 副的数据 3 副本方案，提供数据冗余保护。易鲸捷公司的分布式数据库产品“钱库”与长亮公司的“V7”应用于 2020 年 4 月 5 日正式在贵阳银行核心沙箱项目上线。该项目引入了全国产化解决方案，并涵盖了贵阳银行的各类业务，包括客户、存款、贷款、借记卡、结算、中间业务、核算、机构、柜员、现金、权限以及互联网业务等。该项目首次提出“双库并行”的技术架构，通过新建一套核心应用系统集群 B 基于钱库数据库运行，并与原核心业务系统并行，实现了两个系统间

28、的秒级切换，在系统平滑过渡的同时也实现了业务层面的“灾备”。这些项目的成功投产和稳定运行，证明分布式数据库可以满足金融核心领域高安全、高性能、低成本及高质量等要求。分布式数据库发展面临的问题 分布式数据库虽然具备独特技术应用优势，但其发展也面临一系列问题。应用系统面对分布式数据库的合理选择问题：按照 CAP 理论，分布式系统不可能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)，而最多只能同时满足其中两个。在分布式系统中，由于网络可能会出现延迟、丢包甚至中断等问题，导致分区容错性是必须实现的，因此企业一般在一致性

29、和可用性之间进行权衡，而不同的应用系统对一致性、可用性和性能的要求各不相同。例如,很多互联网应用对一致性要求相对较低，但希望可用性较高；而金融核心应用常常需要优先保证较高的一致性又要保证 5 个 9 及以上的高可用。因此，在 CAP 理论约束下，如何根据应用的特点从种类繁多的分布式数据库系统中做出合理选择，是大多数软件开发人员面临的一大难题。遗留系统面对分布式数据库的迁移改造问题：分布式数据库的本质是在全局范围内，通过各种调度设计，保证多个具备集中式数据库功能的单节点数据库协同工作。在集中式数据库中应用比较成熟的存储过程、触发器、视图、DBLink、外键约束等功能需要迁移到全局层面实现，实现难

30、度较大。即使部分分布式数据库已经实现上述功能，也可能是受限使用，并且执行效率低于集中式数据库。上层业务在实现或者改造时，需要额外关心数据模型，数据模型的主要工作是设计数据和数据之间的关系，后续的业务实现是围绕数据关系实现相应的逻辑。考虑到硬件开销和充分发挥性能优势，数据模型要考虑本数据及其相关的一组数据的数据分布规则，后续的应用实现也需要考虑这点，例如要尽力避免分布式事务。如果分区设计良好，分布式数据库将表现出非常高的并发能力和水平扩展特性，从而使迁移至分布式数据库的应用受益，反之可能影响整体系统的性能。值得注意的是，目前大量的外围业务由于功能杂、关联数据多、复杂语句比例高，使用了较多集中式数

31、据库的特定语法或者功能，迁移到新的分布式数据库上必须充分评估改造和迁移工作量、投入收益比。相反，不少核心业务一方面因为性能要求高、业务相对简单等原因，使用集中式数据库的特定语法和功能要比外围应用少得多，另一方面，核心业务改造迁移后可以获得原来不具备的高可用、高性能收益。分布式数据库运维管理较为复杂 分布式数据通常由几十台至数千台服务器组成，相对于传统集中式数据库，分布式数据库的硬件、软件维护都是非常大的挑战，对运维人员要求很高。这也是为什么分布式数据库在互联网和金融领域率先应用的原因之一，因为互联网企业和金融机构的运维队伍水平较高。这就需要数据库厂商提供简单、方便的统一图形化运维管理控制平台，

32、实现一些常用的运维操作，比如：服务器资源管理、创建和删除数据库集群、查看集群状态信息、监控各个节点和核心组件的运行情况、备份、恢复等，以降低分布式数据库的日常运维难度，方便分布式数据库使用。未来还要考虑借助人工智能等技术进一步降低运维工作量和难度。分布式数据库产品成熟度有待提升 相比于集中式数据库，分布式数据库还处于发展的初期，自身的技术体系、标准规范、测评机制、产品推广等方面尚不健全，甚至很多用户单位对分布式数据的理解也不尽相同。分布式数据库的优化器、数据类型、复杂查询、自定义函数、存储过程等高级特性参差不齐，有待进一步提升，而传统集中式数据库已经过数十年的发展，语法丰富、功能完善，部分主流

33、集中式数据库在标准的 SQL 基础上衍生出很多该数据库的特殊用法，应用系统如果过多的使用了这些特殊用法，在迁移到分布式数据库时，语法适配改造通常会异常困难，是推广分布式数据库使用的一大门槛。分布式数据库发展趋势 分布式数据库的产品化日趋成熟 随着国产分布式数据库在金融、互联网等重点行业中的应用，促使产品技术不断迭代，兼容性、易用性、可扩展性等问题将一一克服。未来随着分布式数据库等的标准体系及评价体系的健全，分布式数据库产品的生态体系也将逐渐完善，在运维保障、数据迁移、运行监测等方面的配套工具也将逐步成熟。与人工智能等新技术融合实现高效运维 在数字经济的推动下，数据的全生命周期管理尤为重要，而分

34、布式数据库数据通常由几十台至数千台服务器组成，数据库的运维显得尤为重要。随着人工智能技术的发展，将人工智能技术融入分布式数据库的全生命周期，实现自运维、自管理、自调优、故障自诊断和自愈，是未来发展的必然趋势。另外，在交易、分析和混合负载场景下，可以通过人工智能的学习算法，实现数据库的自动调优。分布式数据库的服务方式将向云化发展 云计算技术已在我国各行业信息化建设中大规模应用，为适应未来信创领域信息化建设技术方向，降低数据库运维成本，灵活调度资源，国内数据库厂商积极布局云数据库产品及服务。阿里云、腾讯云、华为等已经发布了基于自有云平台的云数据库产品，传统数据库厂商达梦也推出云数据库产品。总体上，

35、国内云数据库与国际先进水平基本持平，为未来信创云数据库发展提供良好基础。分布式数据库发展路径建议 目前，国内绝大部分数据库企业均推出了分布式数据库产品，我国分布式数据库发展水平基本与国际同步，在一些技术指标和应用层面处于领先水平，而且互联网、金融等领域的应用场景对分布式数据库具有切实需求。当前，应大力发展分布式数据库的技术产品，加快行业应用，促进数据库产业高质量发展。政策引导，形成分布式数据库的典型案例 客观的说，分布式数据库不是传统集中式数据库的更新换代，而是充分结合分布式计算技术，使得在一定规模的节点和付出一定规模的成本后，实现了较高的性能水平，并不是所有的应用场景都适合使用分布式数据库，

36、既没有必要神话分布式数据库的作用，也不应该去贬低其作用。因此我们希望在政产学研用等多方努力下，共同打造分布式数据库的最佳实践，树立一批典型的行业解决方案，并加以宣传推广。产用协同，提升分布式数据库产品成熟度 分布式数据库作为数据库领域的创新，目前其产品化程度不高，甚至目前的一些所谓分布式数据库产品，其实更像是产品与应用融合后的解决方案，并不利于市场推广。因此我们建议充分利用好数据库以及基础软件领域的创新中心、适配基地及重点实验室等机构，加强供需双方的产用协同，形成良性的问题反馈机制，共同解决一些共性的技术和产品问题，逐步打磨优秀的分布式数据库产品。营造环境，打造分布式数据库的生态 从产业发展角度来看，相比于集中式数据库，分布式数据库还处于发展的初期，技术体系、标准规范、测评机制、产品推广等方面尚不健全。建议第三方研究和服务机构牵头，联合推进技术标准、测评认证、迁移验证、示范试点等工作，共同营造良性的分布式数据库生态体系。目前华为、PingCAP等企业发起了分布式数据库的开源社区，并形成了部分商业发行版产品，这可能也是建设分布式数据库生态体系的新思路。