首页 > 行业资讯 > 从产研和技术两方面浅析国内分布式数据库发展

从产研和技术两方面浅析国内分布式数据库发展

时间：2023-06-22 来源：浏览：

从产研和技术两方面浅析国内分布式数据库发展

原创 twt社区 twt企业IT社区

twt企业IT社区

微信号 talkwithtrend

功能介绍 talkwithtrend.com社区（即twt社区）官方公众号，持续发布优秀社区原创内容。内容深度服务企业内各方向的架构师、运维主管、开发和运维工程师等IT专业岗位人群，让您时刻和国内企业IT同行保持信息同步。

收录于合集

【导读】 单一数据库已难以满足日益增长的企业需求，分布式数据库应运而生，近年来国内数据库市场群雄逐鹿，据统计有数百家参与这个赛道的竞争。本文将结合笔者十多年的银行从业经验，从产研和技术方面，阐述对国内分布式数据库发展的分析，并分享其在金融行业应用规划的观点，希望能为大家提供参考。

【作者】bryan， 任职于某银行

当前百年未有之大变局使得国际秩序正处于重塑过程中，我国正面临前所未有的挑战，IT领域尤其显著。作为IT基础设施领域重要组成部分的数据库正是我国技术创新转型的压舱石，具有举足轻重的作用，从产业侧到应用侧、从产品设计到应用转型，影响企业之广、人员之重，前所未有。本文将结合笔者十多年的银行从业经验，阐述对分布式数据库技术及其金融行业应用的浅见。

一、分布式数据库技术分析

按传统分类，数据库分为OLTP和OLAP两类。虽然OLAP数据总量大、单次操作数据多，但以无需修改的事实数据为主，一般不会面临同一份记录高并发读写的复杂场景，这降低了数据库设计的复杂性。同时，种类繁多的各类大数据开源软件基本可满足企业需求。虽然OLTP数据总量较小、单次操作数据少，但数据修改频度高，对同一份记录高并发读写的场景对数据准确性、处理性能等均有很高要求，这提高了数据库设计的复杂性，也是数据库产品的核心竞争力。

随着中国互联网快速发展和数字化转型，各类企业数据急剧膨胀，单一数据库已难以满足日益增长的企业需求，分布式数据库应运而生。近年来国内数据库市场群雄逐鹿，据统计有数百家参与这个赛道的竞争。

(一) 产研方面

数据库产品研发是一项极其消耗沉淀 人才、场景、时间和资金 的工程，不是基于“开源中间件+开源数据库”就可研发出一款合格的市场产品。 不具备各类数据库专业技术人才， 就难以设计一款好产品，但市场人才相对有限，不是每家公司都有招到高级人才的企业竞争力； 不经过高并发、大数据量的严格复杂业务场景验证， 就难以锤炼产品的稳定性和性能，不是每家公司具备企业给予的验证机会； 不经过时间的运行沉淀， 就难以锤炼产品的成熟度，不是每家公司都有足够的时间和资金去投资一项长期才会见效的产品，所以数据库产品研发具有很高的门槛。很多涉足该领域的公司，有的经数年实践后退出，有的转型做运管平台、技术运维外包等，但我相信未来还会有大量企业因产品洗牌而逐步退出。

(二) 技术方面

虽然市场产品繁多，但从技术维度看， 分布数据库技术特性正在日渐趋同，同质化严重，更多的竞争将体现在产品全面性和稳定性、生态工具完备性等。

在研发思路方面， 主要有基于开源和完全自研两个派系。开源数据库均基于MySQL和PostGreSQL进行研发，二者均是单体数据库，作为分布式数据库的组成部分，必须具备分布式特性（如分布式事务、算子下推等），源代码改造的技术要求高、难度大，并非每个企业都可做到。完全自研需要更加漫长的打磨周期和更加专业的人才，是一条荆棘之路，不是每家企业都有信心、有能力做得到，完全自研的市场产品屈指可数，如TiDB和OceanBase等。腾讯等互联网巨头基于开源改造，等积累一定经验后才开始逐步试水完全自研。

在系统架构方面， 产品基本分为 数据节点、计算节点和管控节点 三部分： 数据节点 采用开源或者自研内核进行数据存储，用一主多从的数据副本保证数据完整性，用分片方式保证处理能力的扩展性； 计算节点 用于SQL语句解析分发和结果汇聚； 管控节点 用于保证系统架构中各模块的高可用和故障切换、日常运维等数据库管理功能。分布式数据库核心特点是“逻辑统一、物理分散”，逻辑使用上用户将其视作单机数据库，但物理实现上却需多台机器，真正做到数据分布透明且灵活拓展的产品屈指可数。 分布式事务 是数据库设计的重点和难点，银行等金融行业对其使用相对谨慎，主要担心功能成熟度。笔者认为，判断分布式数据库产品成熟的一个重要标准就是分布式事务得以放心使用，传统的分库分表模式不是纯技术意义上的分布式数据库。

二、分布式数据库应用规划

随着金融行业基础设施转型加速，近年来分布式数据库产品正在丰富的金融场景应用中得以快速发展和完善，笔者对产品未来充满信心。

数据库在银行等金融公司的应用途径各不相同，一般分为两种应用迁移模式：一种是先外围系统后核心系统，一种是先核心系统后外围系统。由于面临外部监管、内部问责等多种压力，各家企业均面临保持业务连续性的研发运维压力。国有大型银行因客户群体等影响范围广，大多态度审慎，采用先外围系统后核心系统的模式，一方面在外围系统不断验证和打磨产品，采用联合实验室等方式迭代提升产品能力，一方面通过镜像业务流量模式将业务请求转发到自包含的验证环境，按照“帐平表对”的方式整体性验证业务系统改造后的功能和性能。中小型银行综合交易量等多种因素，部分采用先核心系统后外围系统的方式，有些银行（比如中信银行、张家港银行等）已完成核心系统迁移改造，周围系统的迁移替代也就再无难度。企业的迁移规划在某种程度上与CTO/CIO领导、公司架构等密切相关。比如，有些与PostGreSQL背景的CTO更愿意采用TDSQL - PG、GaussDB- PG等数据库；有些稳重的CTO则愿意采用跟随策略，采用同业可比的方式跟踪其他公司的目标产品和迁移方式。

不论采用哪家产品，分布式数据库只是业务系统稳定运行的重要组成部分。只有举全公司之力建立一套完整缜密的运行体系，通过长期验证才能确保核心系统真正稳定运行。可以建立丰富的技术手册（如应用编码规则、数据分库分片规则、数据库运维规范等）和完善的部门分工机制（开放平台微服务、云计算等新型技术会导致部门职责之间的边界更加模糊），同时加强研发、安全、容灾、数据、运营等诸多体系建设： 在研发体系方面， 建立DevOps研发体系，打破研发运维之间的墙，促使技术更加快速响应业务需求；在安全方面，建立主动防御策略，加强红蓝对抗演练，更好应付大量开源软件的使用带来的安全风险； 在容灾方面， 通过常规性容灾演练，有效应付各种软硬件故障对系统稳定运行造成的影响； 在数据方面， 通过各种企业标准的有效贯标和管控，保证数据在大数据分析领域的数据一致性和数据安全性； 在运营方面， 通过对日常运维管理的标准化、脚本化和自动化管理，提升系统运营效率，甚至做到智能运维。

当前金融行业的基础设施转型已进入深水区，各企业结合自身实际情况都制定了有效的应用迁移方式，不断将验证工作推向深入。笔者认为，随着产研侧的不断联合创新和更多业务系统的迁移，中国分布式数据库产品将会日渐成熟。