数据库管理465期 2026-08-28
- 胖头鱼的技术专栏-465 数据库能力上移还是下沉：库变弱了，应用就变重了（20260828）
胖头鱼的技术专栏-465 数据库能力上移还是下沉：库变弱了，应用就变重了（20260828）
作者：胖头鱼的鱼缸（尹海文） Oracle ACE Pro: Database PostgreSQL ACE 10年+数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVP，ITPUB认证专家 圈内拥有“总监”称号，非著名社恐（社交恐怖分子） 全网同名：胖头鱼的鱼缸 ITPUB：yhw1809 除授权转载并标明出处外，均为“非法”抄袭
一、一张越来越乱的架构图
做数据库这行，最怕的不是开会，是开会时对方把架构图投到大屏上那一刻。
前阵子在技术群里划水，看到有人讲了件真事。那位群友说他们做方案评审时，对方架构师很自信地甩过来一张新图：左边是应用，右边是数据库——这本该是清爽的两层结构。结果他越看越不对，应用和库之间横着一排方块：缓存、消息队列、搜索引擎、一套分析库，还有个标着"自研调度"的小框。线绕来绕去，活像谁家网线缠成了毛线团。
底下立刻有群友接话追问：“这个，是业务本来就需要的，还是为了补数据库的窟窿？”
讲故事的群友隔了好一会儿才回：“……补窟窿。”
那句"补窟窿"，比前面一整串架构分析都诚实。
这篇想聊的，就是那个窟窿。这些年数据库能力相对原国外商业库有落差，又有一部分系统为了扩展从集中式转成了分布式，两件事叠在一起，把一部分本该数据库干的事逼到了应用层；为了补这些事，又得引入一堆组件。架构没见着简化，反而更厚了。不过先说一句：逻辑上移这股风，并不全是数据库替换带出来的——它的来路更早，后面会专门聊。
做数据库这行久了都懂，Oracle、DB2 都见过，国产化的坑也踩过——不过本文主角不是一个具体的项目，而是群里同行聊出的一件真事。下面说的都是我的观点，不替谁背书。
二、背景与现象分析：能力缺口怎么把逻辑逼上来
先把现象掰开。逻辑为什么会被逼上来，根子是两个：数据库能力往下掉了，架构往上变了。
能力下降：从"功能"和"性能"两头塌
功能这头。原国外商业库（以 Oracle 为典型参照）能扛业务的，不只是存数，还有一整套"在库里把事办了"的能力：存储过程、函数、包、触发器、物化视图，还有窗口函数、递归查询、MERGE、各种分析函数这类高级 SQL，再加上强约束和引用完整性。这些不是花活，是大量业务逻辑原本就长在里面的地方。
性能这头。单机吞吐、并发连接、复杂查询的优化器成熟度、大事务长事务的处理、锁机制和并发控制——这些决定了"同样的 SQL，原来毫秒，现在秒级"，这些事情会平等的发生在每个客户现场。
国产库这边要分两路看：集中式一路（兼容 Oracle、MySQL 或 PostgreSQL 生态的）能力普遍不弱；分布式一路为了水平扩展，往往要在单库能力上做取舍。下面这张对照表是我按主流版本公开能力整理的，哪家的哪一版具体什么样，得您自己拉套环境压一压才算数：
| 能力 | 原国外商业库（Oracle 参照） | 国产集中式 | 国产分布式 |
|---|---|---|---|
| 存储过程 / 包 | 强 | 中~强 | 弱~中 |
| 复杂 SQL（窗口/递归/MERGE） | 强 | 强 | 中 |
| 跨节点 / 分布式事务 | 强（单机内） | 强 | 中（常见最终一致） |
| 物化视图 / 高级分析 | 强 | 中 | 弱 |
| 强约束与引用完整性 | 强 | 强 | 中（跨分片受限） |
架构变天：有一部分从集中式转向分布式，代价是单库能力
另一头是架构。为了解开单机的扩展天花板，一部分系统用分库分表或者 MPP 替代了集中式——但集中式这条路并没有消失，不少国产集中式库照样能顶住。这一步本身没毛病，毛病在于：那些上了分布式的系统，水平扩展常常是用"单库能力"换的。
跨节点事务、全局一致性、跨分片 JOIN、存储过程支持，这些在分布式下要么弱化、要么直接放弃。你去问厂商，对方会说"我们用最终一致"、“业务自己处理”。“能水平扩"和"能力不塌”，在很多分布式方案里是此消彼长的关系，很难两头都占。
同一笔业务，放在两种架构下，实现位置差很远：
| 业务实现 | 集中式（库内单引擎完成） | 分布式（库内多组件协同，少数上移） |
|---|---|---|
| 跨表事务 | 数据库一个事务保证 | 库内全局事务协调器（2PC / 时间戳序）兜底，业务无感；仅弱一致方案需应用参与 |
| 汇总统计 | 一条 SQL 聚合 | 库内跨分片并行计算引擎执行；超大查询可再下沉一套 OLAP 组件 |
| 去重 / 幂等 | 唯一约束搞定 | 库内全局索引 / 全局唯一约束；极端吞吐场景可引缓存分层 |
| 分页与复杂查询 | 优化器兜底 | 库内分布式优化器下推分片、再汇聚；跨引擎复杂查询才外挂搜索引擎 |
后果链：缺口逼上移，上移又引出一堆组件
把两头合起来，因果就清楚了：数据库顶不住 → 业务逻辑上移到应用层（自己写分布式事务、自己写聚合、自己实现一致性）→ 为补这些缺口，再叠上缓存、队列、搜索引擎、另一套分析库，缓存传统架构也用，区别是原来轻量可选、现在被强化成一整层、缺了不行，而且因为大量本该数据库兜的事，比如热点数据、会话态、计数、去重键这些都压了上来，缓存在容量、命中率、高可用、跨节点一致这几项上的要求，比过去轻量用时高出一个量级；它从"边上帮一把"的边缘组件，变成了"抖一下业务就挂"的命门 → 组件数涨、链路涨、开发和维护成本涨。
最讽刺的地方在这：本想"换掉一个贵库省点钱"（数据库国产化不一定都是这个原因哈），结果多出了好几套系统，人力和故障面都上去了。省下来的 license 费，悄悄挪到了应用开发和运维的账单里。
三、互联网思维溯源：这股"上移风"不是国产化的发明
得说句公道话：把逻辑从数据库挪到应用层，不是国产化才有的发明。它来路更早，也更成体系——互联网行业。
源头：去 IOE 与"轻量用库"
早年的去 IOE 运动，核心思路就是把数据库从"平台"降格成"存储"：能写代码解决的，就不依赖库的专有特性。再往后，"轻量用库"成了信条：少碰存储过程，少绑定某家的扩展，逻辑尽量留在应用代码里；微服务起来了，每个服务自己管自己的存储，存储去重、逻辑上浮。再配上 CQRS、最终一致性这一套哲学，干脆接受"不实时一致"来换弹性。
这套方法论的潜台词其实一句就够：数据库能力不够，就用工程能力补。而且他们，补得起。
为什么在互联网它是对的
因为在互联网场景里，IT 是收入部门。高并发、海量增长是生死线，系统弹性直接换成真金白银的营收。为了弹性去解耦、去上移，投入的工程成本能从业务增长里赚回来。再加上人家人才密度高、有专门的基础设施团队，复杂度用工程能力硬扛，技术债也有机制慢慢消化。容错文化也放得开：快速迭代、允许试错。
所以互联网那套"上移"能立住：动机是赚钱，能力也跟得上。
边界：它是特定环境的产物
但能立住，不等于放哪儿都行。把"IT 是收入部门 + 工程能力强 + 容错文化"这三个前提抽掉，结论就不一定成立了。这张表把两边摆一起看最清楚：
| 维度 | 互联网 | 传统企业 |
|---|---|---|
| IT 定位 | 收入部门 | 成本部门 |
| 增长模式 | 指数级、难预测 | 稳态、可预测 |
| 容错 | 高（快速迭代） | 低（出错即资损/事故） |
| 工程人力 | 充裕 | 紧张 |
| 上移动机 | 换弹性、换增长 | ——（往往只是补窟窿） |
互联网那套打法成立的前提，就是上表这几条。前提一换，账就得重新算，下一章就专门聊，传统企业这边账怎么算。
四、传统企业为什么不能照搬：IT 是成本部门
轮到传统企业这边，逻辑得反过来讲。
根因：IT 是成本部门，不是收入部门
传统企业的 IT，本质是成本中心。它的 KPI 不是"带来多少新增营收"，是"少投入、少变动、求稳、求可维护"。每一多出来的组件，都要算一笔账：采购、授权、部署、监控、排障、升级，这些全是净支出，且都要问 ROI。
互联网上移是为了多赚钱，传统企业上移只是多花钱。把前者的方法论原封不动搬过来，等于用"收入部门"的打法，去打"成本部门"的仗。仗怎么打都是亏的。
业务分两面：稳态和敏态
传统企业里，业务得拆开看。核心交易、账务、台账这类，是稳态——要的是"别动、别错、好查、可追溯"，不是"快迭代、高弹性"。营销、渠道、报表这类，是敏态——可以借鉴互联网的玩法。
关键判断就一句：能力上移要按业务性质分层，不能一刀切。稳态该沉到库里，敏态才谈得上往上移。
没人养得起那团毛线
传统企业普遍没有互联网那种基础设施团队。运维、DBA（甚至没有 DBA）和开发的编制就那么些人，平时救火都忙不过来。组件越多，没人维护的风险越高；一旦出事，故障定位从"查一个库"变成"顺着 N 个系统串联着查"，平均恢复时间反而更长。
我见过最离谱的一家，为了补国产库的能力缺口，在原本的缓存之外，又引入了队列、搜索引擎加一套分析库，结果日常排障要同时盯五个系统的监控大屏。DBA 跟我说：“以前我就守一个库，现在守一个动物园。”
风险账：一致性保证面被放大了
原本数据库一个事务就能保证的事，上移之后变成应用自己保证。出错的面，从 1 个变成 N 个，而且更难定位、更难回放。对稳态业务，这种"把一致性交出去"的代价，远比省下的 license 费贵。
把这些隐性成本摊开，是这样一张清单：
| 成本项 | 表现 |
|---|---|
| 开发成本 | 自写事务 / 聚合 / 一致性等胶水代码 |
| 运维成本 | 多组件监控、排障、升级、联动发布 |
| 风险成本 | 一致性漏洞难定位，出错即资损 |
| 人力成本 | 养多层技术栈的工程师 |
| 选型隐性 | 能力缺口转嫁到应用层，账算在别处 |
五、核心观点：让数据库把该扛的扛住
前面把现象和来路都铺开了，该说我的看法了。
主张：业务实现尽量下沉到数据库
我的主张很直接：数据库应当具备足够的能力去支撑业务，让业务实现尽量沉在数据库层——存储过程、函数、约束、触发器、物化视图、事务，这些本就是干这个用的，而不是上移到应用层。
这话不是怀旧。数据库做它擅长的一致性、事务、约束，远比应用层自己造轮子可靠，而且开发只写一次，后面少改。把复杂留在数据库里，交给最擅长扛复杂的东西去办。
三点价值：简化、降本、稳定
往下拆，就是三件事：
- 简化 IT 架构：少一个组件，就少一条链路、少一个故障点。底座厚，上层就薄；底座薄，上层就毛线团。
- 降低开发维护成本：一致性由库保证，开发不用写一堆胶水代码去补窟窿，后期也不用反复改。
- 提供稳定底层环境：事务、约束、引用完整性由数据库原生保证，稳态业务最吃这一套——它要的就是"别动、别错"。
选型启示：看"能力厚度"
落到选型本身，有个常被忽略的维度。太多项目看"能不能跑起来"、“价格低不低”、“兼容度高不高”，却没看能力是否够把业务沉下去。
一句话点透：能力缺口大的库，不是便宜了，是把成本转嫁到了应用层和运维层，这只是将这笔账算在别的地方，初看不明显。所以选型评估，至少该看这几项：
| 维度 | 看什么 |
|---|---|
| 能力厚度 | 存储过程 / 函数 / 高级 SQL / 事务支持度 |
| 真实性能 | 自家业务负载下的吞吐与延迟，非跑分 |
| 架构代价 | 集中式够不够？非得分布式吗？ |
| 上移成本 | 业务要改写多少、被迫引多少组件 |
| 总拥有成本 | 不只 license，算上开发与运维 |
辩证：不是所有能力都该下沉
最后说句不偏的。回到第三章，敏态业务、高并发、需要弹性的场景，互联网那套仍然成立，该上移就上移。我反对的，是"不问场景、一律上移"的盲从——仿佛把逻辑搬出数据库就先进了。
说到底还是得按业务性质分层：稳态沉库，敏态可移。该沉的沉下去，该浮的浮上来，别用一个教条盖过所有业务。
六、结论
回到开头那张毛线团架构图。
那团乱的根子，不在"国产"两个字，在于我们容忍了"底座变薄、上层变厚"。做系统替换或架构升级，目标不该是"换个能跑的库"，而是"换个能撑住业务的底座"。数据库能力够厚，上层才简单；底座薄，上层就缠成毛线团，而最后养那团毛线团的，是您的人和您的预算。
对大多数传统企业来说，IT 是成本部门。能沉库就别上浮，把复杂交给最擅长扛复杂的东西。这不是保守，是算清楚了账。
老规矩，知道写了些啥。
