企业传统集中架构数据库信创战略究竟是应该直接平移还是实现分布式的改造？
2023.09.04信创本身是一次能够将存量的企业应用进行重构、优化和转型的契机，针对数据库更应该根据企业应用的计算场景，实时性，数据量慎重地进行评估。
一、引言
集中式关系型数据库经历多年的发展与运用，在企业传统应用架构中处于数据层的关键组成部分。而近年来在国家信创战略的大背景下，国内数据库产业处于百花齐放的状态，各厂商纷纷推出关系型数据库的集中式与分布式的部署形态，为企业信创数据库选型提供了更多选择。
二、分布式数据库的目标场景
分布式数据库的设计之初是为了应对常见于互联网应用场景下海量数据增长和高并发访问挑战，以国外厂商为代表传统集中式数据库面临着性能和容量瓶颈。当时在互联网大厂的实践中，主要通过使用性价比相对较高的x86服务器和数据分库分表的方式，在降低软硬件费用的同时，提高整体数据层的承载能力。
在这样的背景下，分布式数据库作为解决方案应运而生，在应对大IO吞吐、大容量、高并发的应用场景相对集中式有明显优势。
三、信创分布式数据库的常见逻辑架构
大多数信创分布式关系型数据库与IBM DB2DPF、Teradata和Greenplam等MPP数据库类似，采用了share-nothing的设计理念，技术实现上分为两个主要流派：
1. 原生分布式数据库
在Google F1/Spanner和Postgres-XC/XL的启发下，此类实现通常有以下特征：
1) 拥有多个对等数据节点和协调节点以提高并发接入能力。
2) 使用Paxos/Raft分布式共识协议进行数据复制和仲裁以保证数据高可用。
3) 通过添加数据节点的方式实现容量的水平伸缩。
4) 利用hash分片对数据进行水平切分以提高IO吞吐。
5) 另外调用组件实现元数据的统一管理和事务的全局一致性。
在此借用Postgres-XC/XL分布式数据库解决方案部署架构用以示意，见下图1。
图1：Postgresql-XL架构图
2. 分布式数据库生态解决方案
此类方案秉承了Database Plus理念，在碎片化的异构数据库上层构建统一接口标准并进行增强，通过数据分库分表中间件/数据查询引擎/数据库代理，将各个独立的甚至是异构的数据库实例整合成为一个大型的数据池。此种方案具有以下的特点：
1) 无需对原有数据库进行数据迁移和架构变更。
2) 支持多种数据源实现异构数据池。
3) 无需关注底层数据节点容灾架构，水平扩展更为灵活。
此种解决方案的代表有Facebook开源的Presto和Apache基金会开源项目ShardingSphere，大体架构见图2。
图2：ShardingSphere的混合部署架构图
可以确认的是，不管采用何种流派，分布式数据库由于需要进行跨节点数据通讯，其架构复杂度和延迟情况都将大大增加，针对高频率、低延时、小IO的密集计算场景，分布式关系型数据库解决方案在现阶段硬件水平和生态下存在明显的短板。在此引用以下叙述进行说明：
“首先，分布式数据库因其内在局限性，会牺牲许多功能，只能提供较为简单有限的CRUD查询支持。其次，分布式数据库因为需要通过多次网络RPC完成请求，所以性能相比集中式数据库通常有70%以上的折损。再者，分布式数据库通常由DN/CN以及TSO等多个组件构成，运维管理复杂，引入大量非本质复杂度。最后，分布式数据库在高可用容灾方面相较于经典集中式主从并没有质变，反而因为复数组件引入大量额外失效点。”
“在现代硬件的加持下，真实世界中99%+的场景超不出单机集中式数据库的支持范围，剩下1%也大概率可以通过经典的水平/垂直拆分等工程手段解决。这一点对于互联网公司也能成立：即使是全球头部大厂，不可拆分的TP单表超过几十TB的场景依然罕见。
NewSQL的祖师爷 Google Spanner 是为了解决海量数据伸缩性的问题，但又有多少企业能有Google的业务数据量？从数据量上来讲，绝大多数企业终其生命周期的TP数据量，都超不过集中式数据库的单机瓶颈，而且这个瓶颈仍然在以摩尔定律的速度指数增长中。从请求吞吐量上来讲，很多企业的数据库性能余量足够让他们把业务逻辑全部用存储过程实现并丝滑地跑在数据库中。”
——非法加冯，《分布式数据库是伪需求吗？》
四、现阶段企业集中式数据库信创思路
信创本身是一次能够将存量的企业应用进行重构、优化和转型的契机，针对数据库更应该根据企业应用的计算场景，实时性，数据量慎重地进行评估。
我个人的总体观点是：现阶段的数据库信创选型应从应用场景和数据量着眼，仅在必要的情况下选择数据库分布式改造。以下是几条粗浅的建议内容：
1) 建议要求低时延，高频率的交易类，支付类应用采取平移策略，主要重心放在优化数据类型和存储方式上，比如结合集中式存储高性能的能力。
2) 而要求高IO吞吐，允许异步的管理类、风控类，查询类和报表类应用，可以根据数据量酌情选择平移后水平拆分或者采用信创分布式数据库。
3) 特定的场景，应该选择更合适的数据工具，比如监控指标数据，物联网传感器数据和地理坐标数据，选择对应的时序数据库和空间数据库更为合适，而不是以BLOB和CLOB存储在关系型数据库之中。
4) 最后在满足业务诉求的同时，还需考虑使用体验，如操作配置的易用性、数据备份的能力、集群实例管理，监控等方面是否对运维人员足够友好。比如快照备份恢复、高可用能力等集中式架构方案是现阶段大多数分布式数据库解决方案所欠缺的。
