数据库管理465期 2026-08-28胖头鱼的技术专栏-465 数据库能力上移还是下沉库变弱了应用就变重了20260828一、一张越来越乱的架构图二、背景与现象分析能力缺口怎么把逻辑逼上来能力下降从功能和性能两头塌架构变天有一部分从集中式转向分布式代价是单库能力后果链缺口逼上移上移又引出一堆组件三、互联网思维溯源这股上移风不是国产化的发明源头去 IOE 与轻量用库为什么在互联网它是对的边界它是特定环境的产物四、传统企业为什么不能照搬IT 是成本部门根因IT 是成本部门不是收入部门业务分两面稳态和敏态没人养得起那团毛线风险账一致性保证面被放大了五、核心观点让数据库把该扛的扛住主张业务实现尽量下沉到数据库三点价值简化、降本、稳定选型启示看能力厚度辩证不是所有能力都该下沉六、结论胖头鱼的技术专栏-465 数据库能力上移还是下沉库变弱了应用就变重了20260828作者胖头鱼的鱼缸尹海文 Oracle ACE Pro: Database PostgreSQL ACE 10年数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVPITPUB认证专家 圈内拥有“总监”称号非著名社恐社交恐怖分子 全网同名胖头鱼的鱼缸 ITPUByhw1809 除授权转载并标明出处外均为“非法”抄袭一、一张越来越乱的架构图做数据库这行最怕的不是开会是开会时对方把架构图投到大屏上那一刻。前阵子在技术群里划水看到有人讲了件真事。那位群友说他们做方案评审时对方架构师很自信地甩过来一张新图左边是应用右边是数据库——这本该是清爽的两层结构。结果他越看越不对应用和库之间横着一排方块缓存、消息队列、搜索引擎、一套分析库还有个标着自研调度的小框。线绕来绕去活像谁家网线缠成了毛线团。底下立刻有群友接话追问“这个是业务本来就需要的还是为了补数据库的窟窿”讲故事的群友隔了好一会儿才回“……补窟窿。”那句补窟窿比前面一整串架构分析都诚实。这篇想聊的就是那个窟窿。这些年数据库能力相对原国外商业库有落差又有一部分系统为了扩展从集中式转成了分布式两件事叠在一起把一部分本该数据库干的事逼到了应用层为了补这些事又得引入一堆组件。架构没见着简化反而更厚了。不过先说一句逻辑上移这股风并不全是数据库替换带出来的——它的来路更早后面会专门聊。做数据库这行久了都懂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 是成本部门。能沉库就别上浮把复杂交给最擅长扛复杂的东西。这不是保守是算清楚了账。老规矩知道写了些啥。