好文推荐 | 有理有据：数据库选择集中式还是分布式

外向笑小鸭子 2024-01-02 10:39:06  52614

分类专栏：资讯

OLTP类型的业务系统采用集中式数据库还是分布式数据库是在做国产数据库改造中经常被问到的问题，无论是对技术架构发展演变，还是对现有业务长期发展提供必要的支撑，这个问题都具有讨论意义。在分布式大行其道的背景下，似乎任何架构都需要分布式赋能。现实真的是这样吗？下面将全面地进行分析与阐述。

使用现状分析

国产数据库厂商2022年就已经达到了200多家，传统集中式数据库以人大金仓、达梦为主，也有像polarDB这样的新兴数据库，分布式数据库有GaussDB、Kingwow、TDSQL、GoldenDB和OceanBase等，其实大部分这类的数据库都具备集中式和分布式两种部署模式，也就是你买分布式数据库的钱也可以用于集中式部署，可以满足你不同的业务需求。

这里有一点要注意，有的分布式数据库的厂商采用集中式部署，应用依然需要连接计算节点。通过计算节点（CN），去连接下面的数据节点，这可能是出于统一架构的考虑，也是出于计算节点在数据库发生主备切换时可以感知自动切换、对应用透明的考虑。但这样无意中增加了一层解析，会对性能产生一定的损耗。有的数据库厂商是通过自身提供的JDBC/ODBC驱动或VIP等方式直连数据库，从而避免了类似问题的出现。

从技术架构看，金融行业使用的数据库仍以集中式为主，分布式数据库在中大型金融机构形成了有力补充。《金融业数据库供应链安全发展报告(2022)》调研数据显示，集中式数据库在金融业总体占比仍高达 89%，其中银行80%，证券和保险业占比均超过 90%，集中式数据库在金融科技数字化进程中扮演重要角色。金融行业分布式数据库总体占比达到7%，银行业超过了17%，证券业和保险业相对较低。也就是说我们大部分业务采用集中式数据库是完全能够满足的。

真的需要分布式吗

集中式数据库由于只有一个主数据节点，天然具备架构简单、运维方便、兼容性好和性价比高等优势。

但也存在无法突破单机硬件限制、无法横向扩容、存在性能和容量瓶颈的问题。

所以当集中式数据库无法满足我们的性能和容量要求时，分布式就给我们提供了一个很好的技术手段。当我们打算选择分布式来解决集中式的问题的时候，建议大家先做如下的提问再做考虑：

1. 是否可以通过优化集中式数据库自身来解决问题，而不做大的架构改动，如优化参数、优化SQL语句，优化业务逻辑等方式。‍‍‍‍‍‍‍‍‍

2. 是否可以通过增加主机资源配置解决问题，如采用增加CPU和内存大小，或原来采用虚拟机而改用物理机等纵向扩展的方式解决。

3. 是否可以通过存算分离的方式解决问题，如果只是单机的容量无法满足要求，可以考虑外挂存储或采用存算分离架构，解决单机磁盘容量受限的问题。

4. 是否可以通过应用层解决，如改变业务架构，采用微服务或单元化架构，也就是在应用层实现数据拆分、分布式事务和水平扩展等能力，而数据库依然采用集中式。这种方式对开发人员的要求高，业务改造成本大，需要综合考虑。

5. 是否充分了解分布式架构的优缺点，是否做好分布式数据库的运维与备份等相关准备工作，是否充分考虑自己的业务必须要通过分布式数据库来解决。

何时使用分布式

早期有2000w行的表需要拆分的说法，这个主要是针对MySQL数据库。当OLTP类型的表超过2000W行，通过公式计算B+tree叶子层数会增加到4层，从而增加IO的读取次数。但随着硬件的升级或缓存技术的实现，可以基本忽略IO的影响。因此目前比较常见地通过TPS或QPS指标来决定是否需要做分布式改造，如单点TPS瓶颈达到4000，或QPS达到8W，或数据容量达到2TB后。一般情况下需要做横向扩容解决性能或容量瓶颈，相对来说比较合理，但这里没有一个固定公式，主要还是要结合自己的业务场景来做判断。也要考虑未来业务增长的需求，如是否满足业务3-5年的增长需求，做好峰值预测，提前做好规划，避免做二次改造。同时参考上面提到的几个问题，是否必须通过分布式数据库来解决。

实验数据一（找拐点）

硬件资源为基于ARM架构的鲲鹏虚拟机环境，具体配置为16C64G，中标麒麟v10操作系统，普通ssd磁盘。

下图为某国产分布式数据库测试结果，分布式为4分片，单位:秒。

如何用好分布式

顾名思义，分布式，多个人干活，具备高可用、高扩展、高性能和弹性扩缩容能力等优势。

由于数据节点数量和数据库组件的增加，必然会出现架构复杂、运维复杂和成本高等问题，同时大部分分布式数据库不支持存储过程、自定义函数等特殊对象。

分布式是一把双刃剑，我们如何用好且不受伤很重要。

1. 分片键的选择

分片键的选择非常重要，选作分片键的字段取值应该比较离散，以便数据能在各个数据节点上均匀分布。当单个字段无法满足离散条件时，可以考虑使用多个字段一起作为分片键。一般情况下，可以考虑选择表的主键作为分片键。例如，在人员信息表中选择证件号码作为分布键。且大部分分布式数据库都不支持或不建议对分片键的修改。

2. 分布方式的选择

常见的选择是hash分布，相对来说分布更加均匀，另外还有range和list等分区，当然我们最终需要结合具体业务场景进行选择。另外需要将一些经常用的配置信息表或关联查询的小表定义成全局表，确保在一个数据节点可以获取到，避免跨节点数据交互。

3. 规范SQL语句的编写

应选择分片键作为查询条件，并采用分片键作为多表关联查询条件。如果不采用分片键会出现跨节点数据传输，有的分布式数据库会出现将所有数据汇聚计算节点做汇总关联排序，当数据很大时会瞬间将计算节点资源打满，导致数据库无法对外提供服务。

4. 规避跨节点数据传输

如上所说的将查询条件作为分片键就是最大限度地避免跨节点传输，因为跨节点数据传输是基于网络进行的，网络相比较磁盘的传输读写性能存在很大的差距，所以性能会明显下降，甚至会出现结果一直跑不出来的情况。

5. 规避分布式事务

分布式事务处理路径长，这个是他的性质决定的，大部分数据库就基于2PC原理实现，因此我们要最大限度地规避分布式事务，一般情况下控制在所有事务的10%以内，过多的分布式事务一定会给我们带来性能影响，也对业务数据的一致性问题带来了挑战。

深入分析：分布式是数据库解决还是应用解决

分布式的实现可以通过数据库解决（分布式数据库）也可以通过应用解决，大部分开发人员，尤其是传统行业或城商行等金融机构，开发能力比不上大行，人员规模有限，他们更希望数据库做的事情更多一些，比如分布式事务的实现、数据拆分的实现，尽量对开发人员透明。所以他们会直接采用分布式数据库，以单元化架构为例如下图：

小结

在一次数据库创新的圆桌论坛上，一位同行的老师说集中式数据库就像绵羊，温顺而便于管理，而分布式数据库是一匹野马，放荡不羁难于控制，这让我想起了宋冬野在《董小姐》的歌里唱到的，“爱上一匹野马，可我的家里没有草原，这让我感到绝望...”。分布式数据库这匹野马能够驯服，会让你在大草原上飞奔驰骋，否则就会让你受尽苦难、步履维艰。其实大部分开发人员还是希望数据库做的多一些，开发人员改造少一些，数据库更透明一些，更简单一些，甚至是更智能一些。

最后我想说一句，我们国产数据库任重而道远，其实相比较新功能的增加，客户更关心基础功能的改进。如果我们能把数据库核心存储引擎做好，生态做好的话，那么OLTP的数据库我们也不会去深入讨论这个话题。

文章如有表达不准确、或不专业的地方还请大家指正，谢谢。

网站声明：如果转载，请联系本站管理员。否则一切后果自行承担。

本文链接：https://www.xckfsq.com/news/show.html?id=34096

赞同 0

评论 0 条

好文推荐 | 有理有据：数据库选择集中式还是分布式

相关文章

关注我们