数据库管理-第140期 为什么有人无脑吹分布式（20240126）

第140期 为什么有人无脑吹分布式（20240126）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Associate: Database（Oracle与MySQL）
网思科技 DBA总监
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家，ITPUB认证专家，OCM讲师
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭。

先来保个命，其实最早这篇文章起的名是《为什么有些场景的数据天生不适合分布式》，但是本着拉流量需要做一个标题党的原则，万能的群友贡献了本文的名称，文章下面的内容与原始标题更加贴切。

1 环境

记得以前看到过一句话，在数据量突破PB后，只有分布式数据库能解决生产系统的问题；但是我也说过，那是没见过Exadata上开启EHCC跑PB级HTAP的。其实我想说的是，集中式数据库与分布式数据库在架构上没有优劣之分，得从数据库软件实力、硬件水平、业务开发水平、架构、业务场景等各方面来考量。
Oracle有一句话“数据是以存储为中心，而不是以使用为中心”，其实最终该选择何种架构的数据库，是以业务场景特性来的。

2 场景

从很多地方我们可以看到，使用分布式数据库需要更高的开发水平，需要简化业务SQL，拆分业务逻辑，而且需要明确的分片键。
那么从我最擅长服务的领域来举个例子看一下，那种应用场景的数据不适合分布式数据库：

• 数据存在时序数据且种类多、并发高、实时性要求较高
• 数据存在非时序数据，数据量大，数据条目类型复杂，单行数据量大
• 非时序数据虽然可以以某种方式分片（比如地域），但是业务场景存在大量的分片内查询、跨多分片线性关联查询、跨多分片网状查询等需求
• 时序数据无法按照非时序数据方式进行分片（比如时序按时间VS非时序按地域）
• 多类型时序数据存在线性扩展关系
• 时序数据需要通过非时序数据组合生成，几乎无点查场景

记住一点，上面几点不是单独存在业务场景中，而是组合起来的。当然，这种场景也能通过对数据层的大规模拆分业务逻辑，比如通过一个中间表（甚至是中间库）来关联各类型数据，但带来的问题就是，这个中间表（中间库）绝对是以集中式方式运转的（而且这个表绝对不会很小），而且原来整体集中式一条语句能实现的场景现在往往得分几步。

3 首席补刀

在写这篇文章的时候，与首席沟通了一下文章内容，首席随即甩来了补刀内容：

不仅仅是需要开发水平高。
其实还需要设计水平高。很多多表关联这是设计出来的，这个设计人员可能是DBA也可能是开发人员。如果表、视图、索引设置不当，那么SQL必然会复杂。
还有需要业务水平高。需求描述清晰准确，如果按照需求描述写出的SQL是没有谓词或者无法用到任何可能的索引，甚至是需求不合理的。那么必然会导致严重的问题。

总结

并不是所有的应用场景都适合分布式数据库，确切来说是表分片，在很多使用分布式数据库的地方，你会发现，用的最多的还是副本（单分片），或者说叫单表。
老规矩，知道写了些啥。这里还要感谢一下圈内兄弟姐妹们的支持，当我在“墨天轮2023年度优秀原创作者评选”（https://www.modb.pro/db/1749686728055148544）活动中获得了综合排名第二的好成绩，并获得“墨天轮2023年度墨力之星”的称号。
最后既然首席补刀了，再次推广一下薛首席的微信群，里面数据库圈大佬众多，日常进行技术、非技术讨论，由于群人数已超过300（上次宣传还是200），只能把首席微信二维码贴出来，想入速加：