1、数据孤岛时代：单体数据库架构的困境与挑战

大家好，我是老赵。做数据架构这行十几年了，今天咱们聊聊一个老生常谈、但又绕不开的话题——单体数据库。

你想想看，十年前，甚至五年前，大部分公司的数据架构长什么样？

一个中心化的 Oracle 或者 MySQL 集群，扛着所有业务线的读写。CRM 的数据在这里，ERP 的数据也在这里，甚至连用户行为日志，都想办法往里塞。那时候大家觉得，这很正常啊，数据集中管理，多好。

但真的是这样吗？

1.1 性能瓶颈：谁也跑不快

我记得在 2016 年，我参与过一个电商平台的重构项目。当时他们的核心订单库，单表已经超过 5 亿行。每天晚高峰，DBA 团队就盯着监控屏，CPU 使用率飙到 95% 以上。

为什么会这样？

因为所有查询都挤在同一个池子里。一个慢查询，能把整个库拖死。运营同学跑个报表，前台用户就转圈圈。你想想看，用户体验能好吗？

单体架构下，资源隔离基本是奢望。存储、计算、网络，所有业务共享。一个业务线的突发流量，就是全公司的灾难。

问题维度	具体表现	我的亲身经历
计算争抢	复杂分析查询占用大量 CPU，导致简单查询超时	有一次运营跑月度报表，直接把订单写入接口拖挂了，损失了半小时的订单
存储膨胀	单库磁盘 IO 成为瓶颈，备份时间超过 8 小时	我们当时的全量备份要跑 12 小时，差点影响第二天的业务
连接数耗尽	应用实例增多，数据库连接池被打满	嗯，这里要注意，连接数不是无限加的，MySQL 默认 151，改大了内存也扛不住

1.2 扩展性困境：加机器也解决不了

很多人会说，性能不够，加机器啊！

但单体数据库的扩展，是垂直扩展——换更强的 CPU、更大的内存、更快的 SSD。说白了，就是在一台机器上死磕。

垂直扩展是有天花板的。你买再贵的机器，也扛不住 PB 级的数据。而且，成本是指数级上升的。

水平扩展呢？分库分表？

嗯，分库分表确实能缓解一部分压力。但带来的问题更多：跨库查询怎么办？分布式事务怎么保证？全局唯一 ID 怎么生成？

我曾经在一个金融项目里，被分库分表后的“跨库聚合查询”折磨得够呛。为了算一个客户的总资产，得写一堆中间件代码，把各个分片的数据捞出来再合并。性能差，代码还巨复杂。

1.3 组织协同灾难：一个数据库，N 个团队打架

技术问题其实还好，更头疼的是组织问题。

一个单体数据库，对应的是一个中心化的 DBA 团队。所有业务线的数据需求，都得找 DBA。

“我要加个字段。”

“我要跑个数据。”

“我的查询太慢了，帮我优化一下。”

DBA 团队成了全公司的瓶颈。业务团队等不及，就开始自己搞“小动作”——在业务库里建临时表、写存储过程、甚至直接连生产库跑脚本。

数据质量？数据安全？统统靠边站。

我个人习惯把这种模式叫做“数据封建制”。DBA 是皇帝，业务团队是诸侯。诸侯想要数据，得向皇帝请示。效率极低，矛盾重重。

1.4 数据所有权模糊：谁生产，谁负责？

在单体架构下，数据的所有权是模糊的。

订单数据是谁的？订单团队说是他们的。财务团队说，订单涉及资金，应该是财务的。市场团队说，订单数据能分析用户行为，应该是市场的。

一个数据，N 个团队声称拥有所有权。结果就是，没人真正为数据质量负责。

数据脏了，没人洗。数据缺了，没人补。数据标准不统一，各说各话。

说白了，责任边界不清晰，是单体数据库时代最大的管理难题。

1.5 为什么我们需要新架构？一张图看懂

说了这么多问题，咱们用一张图来总结一下。单体数据库架构的困境，本质上是“技术集中”与“业务分散”之间的矛盾。

1.6 从困境中寻找出路

所以，我们为什么需要新的数据架构？

答案其实很简单：旧的架构，已经撑不起新的业务了。

我们需要一种架构，能让每个业务团队拥有自己的数据域，能独立决策、独立扩展。就像微服务拆分了应用一样，我们也需要拆分数据。

这种思路，就是后来数据网格（Data Mesh）的雏形。

它不只是一个技术方案，更是一种组织变革。它把数据的所有权，从中心化的 DBA 团队，下放到各个业务团队。谁生产数据，谁就负责治理、提供数据服务。

当然，去中心化不是无政府主义。它需要一套新的治理规则、新的技术基础设施。这就是我们后面 29 章要讲的内容。

今天这一章，咱们先把问题看清楚。只有深刻理解了单体数据库的痛，你才能真正体会到数据网格的好。