十问分布式数据库：技术趋势、选型及标准思考

随着信息技术的迅猛发展，各行各业产生的数据量呈爆炸式增长，传统集中式数据库的局限性在面对大规模数据处理中逐渐显露，从而分布式数据库应运而生。分布式数据库是在集中式数据库的基础上发展起来的，是分布式系统与传统数据库技术结合的产物，具有透明性、数据冗余性、易于扩展性等特点，还具 备高可靠、高可用、低成本 等方面的优势，能够突破传统数据库的瓶颈。

分布式数据库目前已应用到金融、电信等大数据行业，未来将走向更广阔的领域。本期“数据库 Talk Show”圆桌直播邀请到了国家工业安全发展研究中心软件所副所长李卫，OceanBase 产品和解决方案部高级总监王南，dbaplus 社群联合发起人、OracleACE、竞技世界资深 DBA 杨建荣，携程数据库总监刘博。几位专家围绕分布式数据库技术路线和产业现状，分析分布式数据库的技术特点以及面临的问题与挑战，对企业如何进行数据库选型互动讨论。

李卫：最近几年，分布式数据库在国内发展较快。一方面，丰富的数据库应用场景，新一代信息技术与实体经济的深度融合，各行各业的数字化转型，社会全面进入数字经济时代，这些变化都给数据处理和存储的主要核心技术带来了非常好的发展机遇，尤其是随着数据规模的增加，数据使用复杂程度的提升，原有的集中式数据库已经渐渐不能满足现在很多场景的需要，分布式数据库成为很多企业必然的选择。另一方面，分布式数据库因为发展时间不是很长，落地实践层面还存在不足。

目前来说，国内主要有三种技术路线可供选择：一是分布式中间件 + 单机数据库，通过在单机数据库系统上进行改造，主要解决了扩展性的问题；二是构建分布式共享存储实现扩展，采用非对称计算节点，大部分公有云数据库是这条路线；三是原生分布式数据库，从底层设计就采用分布式架构，是未来很重要的趋势。

当下，国内从事分布式数据库的厂商非常多，这三种技术路线各自存在应用场景，未来随着应用更广泛的深入和推广，路线还会进一步收敛，肯定会向着第三种路线推进。整体来说，国内的环境和技术需求还是给分布式数据库带来了非常好的机会，甚至未来在分布式数据库领域，国内在世界上处于引领地位。

杨建荣：早期，分布式数据库对业务的侵入性比较高，可能需要将一个业务拆分成多个业务模式，而后逐步演进到相对一体化的模式，出现了分布式中间件这种架构模式，如今又出现了越来越多的原生分布式数据库，技术体系上发生了很大变化，也面临着更多技术挑战，包括技术生态构建以及技术体系迭代层面。

王南：如果从数据库厂商和用户，也就是供给端和消费端的角度来讲，分布式数据库的发展两端并不同步。从数据库厂商的角度来说，分布式数据库已经走了很长时间，但用户对分布式数据库的认知、接受、使用及运维是有滞后的，当然这是一项技术或者产品发展的正常过程。随着数字经济的飞速发展，用户对分布式的诉求将越来越强烈，数据库厂商还需要在产品成熟化、产品能力、技术体系的完整易用以及生态建设层面花费更多时间。

刘博：技术的发展最终还是业务驱动的。以携程为例，如今的数据量与 2003 年刚上市时相比增长了上百倍甚至上千倍。携程 2018 年就开始尝试分布式数据库，发展路线也从最初的非核心业务逐渐过渡到核心业务。在过渡到核心业务时，我们也做了一些备份手段，比如数据双写等。根据 2019 年的数据统计，国内创业的数据库厂商有 160 多家，数据库产品可能有两百多个，其中分布式产品大概占 40%，处于野蛮生长的阶段。但根据 IDC 的调查，目前真正在核心系统中部署分布式数据库的比例不是太高。

李卫：第一，分布式数据库解决了传统集中式单机数据库时期的问题，单机数据库面对海量数据在处理能力、存储能力、性能等方面都存在瓶颈；第二，分布式数据库需要解决数据一致性的问题，数据跨的节点越多，风险就越高；第三，分布式数据库的高可用能力保证不会因为单点故障而影响整体的可用性，这保障了金融、电信等对高可用需求较高业务的连续性；第四，应用存在波峰波谷，分布式数据库通过灵活扩展的设计做到了成本优化。

杨建荣：随着互联网场景快速增长的数据量，我们需要数据库系统支持水平扩展，这种支持可能是两个方面：数据存储和数据计算。在这个层面上来说，更多的是让数据存储实现水平扩展。实现此的前提则是保证整个分布式数据库的性能、可靠性等有更好的表现。从我实际接触的场景来看，更侧重于解决水平扩展的问题，让扩展方式更优雅。

王南：首先，分布式数据库的本质还是数据库，所以也会具备传统数据库的关键特征；其次，分布式数据库需要解决的核心问题之一是扩展，解决研发团队按需扩容、不需要按照业务波峰额外准备硬件资源的问题；然后是高可用问题，集中式数据库的系统可用性很大程度构建在可靠硬件的基础上，分布式架构将高可用问题转变为软件解决；最后在上述问题基础上，如何低成本地将现有应用平滑迁移至分布式数据库，整个过程需要一些方法论。

相较于其他原生分布式数据库，OceanBase 立足于 TP 领域，不断强化 AP 能力，去走向更全面的场景，这是一个关键的立足点，也是我们坚持的设计理念，尽量把复杂性从用户侧向数据库侧转移，对外呈现的是 OceanBase 对用户的应用兼容，包括语法、语义以及存储过程等高级能力的兼容，让用户快速、透明迁移到 OceanBase 。

刘博：从定义来看，分布式数据库首要解决区域间数据的一致性，映射到互联网行业主要是如下两点：一是分布式数据库内置 HA 功能，以携程为例，过去主要采用商业数据库结合存储的模式，靠高端硬件解决 HA 问题，后来这套架构逐渐在主流互联网公司中消失，取而代之的是一些 MySQL 的高可用方案，但这与分布式原生数据库提供的能力差别很大，切换时的中断是业务可以感知到的，分布式数据库本身就可以提供多机房或者异地机房等部署方式，提升了高可用性及数据安全性，切换过程可以做到业务无感知，携程已经将 OceanBase 部署在了生产环境，采用了同城三机房的部署方式，可以抵御同城单机房的故障，且三个机房对等，业务可就近访问，故障时的切换不再需要人工参与，免去了复杂的切换逻辑和人工操作流程。

二是横向扩展问题，虽然携程的业务峰值可能不如几大主流电商平台大促期间那么高，但也是存在明显的波峰波谷，例如暑假和春运火车票抢票。类似 K8s 这样的技术已经很好地弥补了应用的弹性诉求，但数据库层面的弹性一直是欠缺的，分布式数据库提供的动态伸缩功能，解决了数据库层的弹性问题。

李卫：当前这个阶段，我觉得三种路线都存在现实需求，现实需求导致每个应用方要根据自己的业务特点和现实的资源环境决定采用哪种路线，每一种路线都有优势和劣势。分布式中间件路线最大的劣势是代码层级的改造量很大，因为中间加了一层分布式中间件；分布式存储依赖于存储的扩展，在扩展能力上存在局限，尤其是跨地域等较长距离的扩展难度比较大，优势是代码几乎不需要改造；原生分布式的未来趋势非常明显，但因为发展时间相对较短，相较于前两者在稳定性、生态等层面还存在短板，企业需要结合自己的业务进行抉择。

杨建荣：我提炼了六个维度对技术栈进行对比：

1. 事务管理，相对传统模式，原生数据库的事务管理有天然的优越性，因为业务都在一起。中间件的模式可能会放大事务风险或者隐患，原生模式因为是全新的体系，在事务管理层面有较大差异。

1. 发展周期，原生分布式数据库的周期相对来说更短一些，也是这些年非常流行的。中间件的模式，尤其银行等企业，早期在方向上的沉淀，包括这样的落地场景也会更多一点。

1. 迁移升级，原生模式的迁移相对平滑，其他模式还需要配合做一些架构设计和拓扑扩展。

1. 高可用。原生模式依赖云平台的能力在高可用层面具备天然优势，但其他模式依赖底层的标准化模式会有一些短板。

1. 扩缩容，中间件的模式是一个域定义的模式，在做 N+1 的扩展上存在诸多限制，云原生分布式数据库相对来说更加弹性和灵活。

1. 性能。云原生分布式数据库推出早期也经历了大量验证，与其他模式相比，可能会有更多的成本消耗，但性能也有比较大的提升。

王南：我从场景的角度来聊，首先是中间件方案，当集中式数据库无法满足诉求，大家很自然地选择用分库分表的方式解决问题，将流量负载均衡到每个节点，该方案适用一些特定场景，比如对跨节点的分布式事务和一致性没有强诉求，但也有很多问题无法解决，比如支付类场景或者其他需要跨节点事务的场景。

其次是分布式共享存储，不同场景的存储和计算负载要求不同，很可能存在扩展出来的计算和存储资源有一个被浪费掉，该方案的存在很好地解决了这一问题，并且可以充分协同和发挥云存储的优势，这也是公有云厂商积极推动该方案的原因，厂商在公有云存储基础上做了一层封装，可以提供不同类型、不同成本和价格的云存储方案，这种方案需要用户考虑的因素较多，比如数据库架构设计层面如何与这种模式更好地融合。

最后是云原生分布式数据库方案，这对用户来讲是最简单的，因为对用户而言，其与集中式数据库的使用体验没有差异，数据分布、负载均衡以及故障自动恢复等数据库都可以搞定，还免去了集中式场景下理解、学习及对应用改造的成本，但是产品成熟度以及当前积累的场景实践案例是否可以很好地解决问题是企业比较担心的，用户可以场景的不同来选择更合适的方案。

刘博：三种路线与时代发展有很强的关系。第一种中间件的方式对代码侵入性比较强，需要在单机版数据库的基础上增加分片规则，以携程为例，可以从用户的维度进行分片，但有些数据无法找到合适的分片规则，例如：酒店信息很难找到合适的维度，如果以城市为维度划分，一线城市的酒店资源和三四线城市的酒店资源无法对等分片，这是该种方式的局限性。该方式的好处是运维相对简单，没有引入新技术给基础运维带来负担，但压力就给到了业务侧，代码需要做较大的改造。

第二种是公有云厂商提供的方式，好处是存储资源基本做到无限扩充，用户按量付费即可，缺点是计算资源有限，如果业务没有明显的读写分离场景，写的计算节点资源受限于公有云的计算规格，这种路径更适合读的场景偏多的业务。

第三种，从技术、架构层面来说是目前最好的选择，且对业务没有侵入性，扩缩容都比较弹性，但目前观察到的落地案例还不是特别多，我们比较期待这种方式更加成熟，因为对业务比较友好。

李卫：一是上文提到的用户需求的改变催生了分布式数据库的发展；二是数字经济时代，数据成为了最核心的生产要素，要想发挥数据价值，底层的核心技术运用也非常关键。如今的很多企业都在做数字化转型，技术架构从集中式向分布式转化，分布式数据库的支持效果显然更好。

杨建荣：我主要从四个方面回答该问题：

1. 分布式数据库相较商业数据库发展更快主要得益于其他解决方案更耗成本，通过更高配的硬件或者高端存储解决问题长期来看，成本是不容忽视的一个因素。

1. 从使用体验来看，分布式数据库可以让整个过程更加平滑。从研发模式来看，历史债务较多的企业迁移到分布式是一个很大瓶颈。传统的研发模式与当前越来越轻量化的方式是不相符的，分布式数据库在这个方向上是可以做到相辅相成的。

1. 性能，并不是说这种模式的性能一定比单机要好，但具有更强的扩展性，可以通过分布式平滑实现倍数的性能提升。

1. 技术生态，国内的分布式数据库厂商提供了完善的工具、文档包括配套的迁移工具，可以帮助企业实现无感迁移。

王南：这个话题的争议度在几年前还是比较大的，包括分布式是否是正确的方向都有比较大的争议，当然这几年好很多了。大家对分布式的接受度和诉求越来越强，但不代表已经成为主流，国内外也是有差异的，因此我不会轻易对这件事情下结论，但任何技术的发展都是需求驱动的，没有普遍需求，这个观点肯定是不成立的。

不论是市场占有率还是用户接受度来说，分布式数据库目前距离主流肯定还有差距，但越来越多的场景对分布式是有强烈诉求的。在云化的大趋势下，我们相信这会是未来的主流方向之一。

刘博：目前业内很多创业公司和新型的数据库产品都是以分布式的形态出现，这可以理解为时代的产物。从市场需求来看，业务的增长速度更快，对计算和存储资源的要求更高。携程的发展过程经历了单机数据库、单机数据库加高端硬件、分库分表（前文提到的第一种中间件的方式）时代，虽然分库分表模式表面看起来没有增加新的技术，但运维复杂度升高很多，因为分库分表后，DB 规模和表规模越来越大。

分布式的引入对业务更加友好，以维护窗口为例，原来凌晨三四点的时候，业务量很低，可以在这个窗口进行维护升级，如今的携程业务逐步国际化，很难找到维护窗口，需要在不需要宕机的情况下进行维护升级，这也是携程自 2018 年开始使用分布式数据库解决的问题之一。原来需要熬到凌晨三四点才可以做的维护，现在可以选择白天任何一个业务低峰时段进行，这也算是分布式的红利之一。

王南：从安全角度来看，我想到了几个方面：一是分布式数据库与集中式数据库场景下的安全体系基本能力，如用户决策权限是一样的，这些依然存在很强的诉求；二是分布式可能会带来更多挑战，毕竟涉及多节点及更复杂的底层基础设施，OceanBase 目前可以同时物理机、虚拟化、私有云和公有云四种部署方式，未来也会支持多云。除传统的安全手段之外，分布式数据库可能会需要解决数据全链路的安全、数据存储加密等问题，目前也会通过云平台提供一些加解密的方式，安全不是一蹴而就的，未来会逐渐将这些产品能力补齐。

刘博：作为一款商业产品来说，OceanBase 也会遵循国际通用的安全标准，用户可以从三个维度来看待安全问题：存储、审计和传输。比如 OceanBase 可以开启 SSL 功能，实现客户端和服务器之间数据的安全传输。也可以开启透明加密，实现存储的加密。OceanBase 提供的审计表，记录了所有的 SQL 访问。这里提一下，携程根据审计表做了一些功能开发，我们将审计表中的数据全部抽取出来，做了 SQL 的实时分析，用于访问异常检测和性能分析。

李卫：HTAP 这两年的讨论热度较高，当企业内部对 TP 和 AP 同时有需求的时候，结合肯定是性价比最高的方式，否则面临着人力、资源等各方面的浪费，至少目前来看这种方式是存在实际需求的，但需要与场景相结合。

杨建荣：从存储角度来看，AP 本身的存储会占用一部分成本，这需要从成本层面做出取舍，无论是底层压缩还是针对性的热点数据，尽量在不影响原有 TP 业务的情况下让业务更加平滑。

从计算层面来说，可以做扩展或者说插件模式，整个的 AP 计算不是放在一个大池子里，还是需要做出一些取舍。长远来看，HTAP 的方式可以解决大部分诉求，但肯定有一些更专业的方向或者更长历史周期的数据需要专门的 OLAP 实现。

王南：HTAP 严格来说并没有特别明确的定义，这是 Gartner 首次提出的概念，大家的理解或许有所差异。目前有一类实现方式是同一个产品部署 AP 和 TP 系统，虽然是两个系统，但是同一个产品解决了两类场景问题。这就进一步分化为两套引擎（一套处理 TP，一套处理 AP）和一套引擎（既可以处理 AP，又可以处理 TP）两种方式。

如果回到用户的原始诉求上来，HTAP 对用户来讲就是既要解决业务交易负载，也要解决复杂查询、报批、报表这样分析类负载问题，无非是用一个系统还是建两个系统来跑的问题。数据量较小的情况下，Oracle 或许就可以；数据量较大的情况下，目前普遍选择通过两套系统来解决问题。随着分布式的发展，这个问题又出现了新的解决方案，OceanBase 目前的路线是一个系统、一套引擎可以同时解决 TP 和 AP 两类问题，包括数据存储层面的优化，我们正在尝试运行几十 TB 量级 TPC-DS 的负载，希望通过技术手段解决这个问题。

刘博：在实际的场景中，TP 和 AP 的边界可能没有那么清晰，很多业务的响应可能是 TP 级的，资源消耗又是 AP 级的，这个边界越来越模糊，我们很难定义。而且国内的生态基本还是基于 Hadoop 的生态来构建的 AP 系统，这就有可能出现数据延迟、数据重复存储、运维成本上升（需要两个团队各自运维两个系统）等问题，HTAP 可以很好地解决这些问题。

王南：这可能还不太一样。OceanBase 将问题拆分为不同的维度：分布式的问题、计算模型的问题和存储的问题。OceanBase 之所以选择用一个存储引擎来解决问题，主要是充分利用了闪存等硬件 + 新架构来解决海量数据的并发更新问题。虽然从概念上来看，分布式和存储是两层，但实际是放在一起解决的，通过分布式的协议解决节点间的数据复制和存储问题，同时保证数据强一致性和多核高可用。只要做好优化器和语法层，计算引擎和模型是可以比较快速地满足业务诉求的。在不同的层次解决不同的问题，存储层解决效率问题，分布式解决高可用和扩展问题，计算层解决并行、兼容性和生态问题。

刘博：学习成本可能分两个层面：语法层面常用的 SQL 语句都是兼容的，在 OceanBase 的测试中，携程仅发现了极个别无法支持的语句，也是使用频度较低的；运维层面复杂度确实高出几个数量级，因为数据访问涉及的路径变多了。当然，学习途径也变多了，社区有文档、视频等很多资料都可以翻阅。数据库学习最重要的是需要实操，先把 OceanBase 的开源版本运行起来看看，自行编译看看。

李卫：分布式数据库选型需要与业务场景相结合。在国内，金融、电信等领域已经在分布式数据库层面有了大量实践。我们从上述两大行业抽离出了一些与数据库高度相关的系统，比如计费系统、客户系统等，经过试验证明分布式数据库确实已经能够很好地支撑起相关业务的运行，但与老牌商用数据库的能力相比还存在差距，此外还需要关注未来的持续稳定运行能力。

杨建荣：数据库选型的这个问题可以通过 BATD 模型来看。其中，B 指的是业务驱动；A 指的是架构演进的视角看待技术选型，比如中间件就是这样一种技术；T 指的是技术生态，是否在某些场景中有足够的沉淀；D 指的是多元化，数据库选型不要做大一统，而是更多考虑多元化，从技术栈演进的层面做出取舍。

王南：用户对数据库选型是最有发言权，从我们这些年来和众多已经上线核心业务的客户在选型关心维度的反馈上，用户期望在满足以下基本要求再去谈产品的各种特性：

首先，数据是企业的核心命脉，不管选择什么样的数据库，保障数据不丢、不错、不乱是最基本的要求。

其次，如果选择分布式架构的数据库，如何确保永远可信任的数据一致性，包括集群和集群之间、副本和副本之间，分区和分区之间，索引和索引之间甚至是宏块和宏块之间的数据一致性链式校验，从而防止因磁盘静默错误或者因为硬件故障导致的数据不一致。

再次，是否能够对于异构芯片、操作系统等可以实现混合部署、灰度部署，形成逃生机制，确保在数据库改造升级时实现业务逃生。

然后，是否支持 DB-Mesh 的数据中心的部署和建设以满足业务的弹性，可以实现单元化、云原生、全密态的部署。

最后，有专业的团队和支撑可以兜底。

基于上述的基本要求，从功能上可以归纳为四大方向：

第一个也是最主要的，刚性能力和指标满足度，这可能涉及到很多问题，包括性能、功能、安全、可靠，兼容、资质等，这是最基础的。

第二个是产品成熟度，是否已经在足够多的不同行业进行了落地实践，在不同的用户量、不同的业务负载下进行了验证，产品是否只有一个内核，还是上下游产品生态兼具。

第三个是数据库的厂商，也就是背后团队的技术能力，以及这家公司对数据库战略的定力和稳定性，也是影响巨大的，特别是对于中大型企业而言，这关系到系统后续是否可以稳定持续运行。

第四个是成本和性价比，这不仅仅是表面的价格，还包括稳定性的成本、迁移成本、服务成本、运维成本等各方面，甚至有些用户考虑一旦出现问题，兜底方案的成本有多大。

从市场来看，如今的数据库市场确实是百花齐放，好处是提供了更多样化的能力，避免被单一供应商绑定；坏处是选择的成本很高，也可能出现重复造轮子的现象。这就需要行业监管和标准化组织的引导，让行业健康发展。

刘博：我也同意三位老师关于选型肯定需要与场景结合的看法。携程在选择分布式数据库时主要考虑了功能完备度、与现有数据库的兼容性以及性能和支持等方面。OceanBase 目前也有社区版本，我们可能也会考虑社区的 star 数量、PR 数量、issue 数量等。

刘博：迁移可能需要考虑是否平滑、兼容性和性能等。我们之前针对 OceanBase 做过一些测试，比如同样的语句在 MySQL 和 OceanBase 上等比例放上，看两边的响应程度等，也包括一些兼容性测试。

此外，企业还需要考虑迁移过程的稳定性，对新的数据库是否具备足够的掌控力，一旦发生问题，是否有回退方案。以 OceanBase 为例，我们通过 OceanBase 自身提供的 OMS 功能，搭了一条反向链路到 MySQL，一旦遇到紧急情况，可以平滑再切到 MySQL。

王南：从横向来看，可以分为迁移前、迁移中和迁移后三个阶段。事前，我们提供了 OMA 这样的工具，可以对业务负载进行分析，包括可视化的报表告知用户兼容程度、建议使用的迁移方案和可能存在的风险。

事中，提供一个工具完成整个自动化迁移过程，这个后面详细展开。

事后，需要检验迁移是否真的完成以及数据是否一致，这也不意味着万事大吉了，还需要准备一些预案以应对运行后可能的突发情况。

从纵向的角度来看也就是上述提到的事中阶段，这里面有几个核心问题需要考虑：一是原数据如何迁移，假设兼容度极高，各种高级能力都可以直接运用，这是比较省心的。假设兼容度不高，这可能需要大量的手工 SQL 转换，甚至需要进行应用层的改写，成本极高，OceanBase 本身的 OMS 中提供了大量工具可供选择，比如静态的全量数据迁移、增量的数据迁移，自定义过滤条件，甚至一些算子转换等。

此外，对于丰富的数据源和目标端的支持，因为数据迁移不仅仅是从原来的集中式数据库迁移到分布式数据库，不同的用户可能会有不同的诉求，比如对一些流、缓存进行迁移等，这需要云端支持的目标类型足够丰富。

杨建荣：我在上述两位的回答上补充一些细节，迁移过程中常用的一种方式是双写，通过这种模式验证，相对来说整个迁移过程更平滑可控。另外，我们可能会在一些场景做数据同步，比如 A 到 B 的切换过程持续做数据同步，需要不断地考虑数据的一些基础训练，包括 SQL 回放、性能验证等。当然，从整个切换模式来说，业务方几乎是无感知或者闪断。