AI数据库资源隔离实践：CPU、内存与 IO 三招

大家好，我是数据库小学妹👋我踩过的坑，你别再踩。

前阵子有个同行拿他们的问题来问我。AI数据库的问数功能上线两周，业务部门天天在问。使用率比预期高不少，这是好事。第三周财务打来电话，说月结报表从12分钟变成了40分钟。他第一反应是慌，我说先别急。

他把那几天的监控图和配置发过来。我看了一遍，没发现哪个环节配错。问题出在位置上：跑批和问数挤在同一台机器，也挤在同一个时段。两拨负载谁也没错，只是都没给对方留位置。这类事跟换不换库无关，任何新增负载进来都要过这一关。

这篇就聊怎么过这一关。AI数据库的负载和交易负载，到底在哪几处抢资源。三个能落地的解法，配一组每周该看的数。方向先说：不加机器也能调开。

一、AI数据库的两类负载，形状不一样

先给一个能对得上的说法。AI数据库上跑着两类活。一类是点查和短事务，一类是语义解析、向量化、检索和图计算。前一类要的是稳定和低延迟，后一类要的是吞吐和内存。它们的形状不一样，抢起资源来也就各有各的狠。

交易负载的特性是好预测。QPS 有峰谷，事务有固定大小，加机器能线性摊平。AI 负载不好预测，一个问句背后可能是三次检索，也可能是一次全表向量化。这就是它跟交易负载最难对齐的地方。

给 AI数据库加机器，不一定解决。AI 负载的峰值是突发型的，加机器摊平的是平均值。你要的是峰值那一刻有资源，这就得靠隔离，不能靠总量。这个区别在预算会上很关键，因为加机器是最容易批的方案，也是最容易白花的方案。

交易侧的感受往往比监控指标慢半拍。指标看的是平均值，业务感受的是那几次超时。一次月结多跑二十分钟，监控上可能只体现为 P99 从 80ms 涨到 95ms。所以业务说的交易变慢，落到报表上常常只是一个分位数。这个差距在监控上不起眼，在财务那里就是一个电话。

还有一个差别容易被漏掉：时间点。交易的高峰在白天，AI 的批量入库高峰常在夜里。两拨高峰本来错开，一旦重叠，就是开头那个场景。所以解法里有一条是纯时间管理，和技术无关。

二、AI数据库抢资源的三个地方

具体抢在哪儿，我按资源分三类。CPU、内存、IO，每一类的冲突方式都不一样。先看表格，再逐条说怎么解。这张表也是我给那个同行画的第一版。

CPU 那一行的冲突最好认。向量化和重排都是短时高占用的活，一压上来，点查就排在后面。表现是 P99 抬头，平均值几乎不动。所以看 CPU 冲突别盯使用率，盯延迟分位数。

内存那一行最容易被低估。向量索引一旦常驻，缓冲池就被挤，交易侧的读命中率会掉。这个下降不会报警，只会体现在慢查询变多。等你去查的时候，往往已经过了两周。

要不要动，先看三个现象。问数一多，点查就变慢。内存涨上去，慢查询跟着变多。跑批和入库撞在一起，两边都慢。三个里中一个，就值得往下调。三条都中，说明 AI数据库的负载已经压到交易上了。

三、第一招：把 AI 计算挪出去

最直接的办法是物理分开。10 月 30 日金仓发布会上讲过部署形态，独立租户或独立集群节点。意思很明确，AI 那部分计算不和交易挤在一个池子里。这不是新概念，很多单位做报表库时就这么干。区别在于 AI 负载更突发，分开的必要性更大。

分开之后要解决一件事：数据怎么共享。库内方案的好处在这里，独立节点读的还是同一份数据。不用再建一套同步，也就没有同步延迟和漏字段。如果分开就得复制数据，那等于用运维换性能，不划算。

独立租户和独立节点怎么选，看两件事。看预算，租户便宜，节点彻底。看隔离要求，同机房内隔离用租户就够，要跨故障域才需要节点。多数单位的起步阶段，租户够用，留出往上走的余地就行。

也不是所有 AI 计算都值得挪。挪的原则看两件事：谁对 AI数据库的响应延迟敏感，谁就独占资源。向量化和批量嵌入对延迟不敏感，适合挪。语义解析和结果重排跟着问句走，挪出去反而多一跳。判断标准不是功能名字，是这条链路在不在问句的关键路径上。

落地动作有三步。第一，确认 AI 计算能不能独立部署，别只看文档说支持。第二，确认独立节点的权限和审计走的是同一套规则。第三，压一次真实的峰值，看交易侧 P99 有没有抬头。

四、第二招：把内存省下来

挪出去解决的是 CPU 和 IO，内存得另想办法。向量索引是内存大户，1 亿条 768 维，float32 算下来本体就三百 GB 出头，还不算索引本身。这笔内存如果全压在交易节点上，缓冲池必然被挤。所以容量规划时，向量索引不能按“占多少”算，要按“抢多少”算。

在 10 月 30 日的金仓发布会上，还有一组能直接用的数。条件是 1 亿条 768 维向量、余弦相似度、98% 召回率。在这个条件下，峰值内存开销降低 95.4%，查询延迟降低 80%，QPS 提升 5 倍。测试环境是 128 核国产 ARM、256GB 内存、麒麟 V10，工具用 VectorDBBenchmark。

这组数的用法不是拿去汇报，是拿去算账。按同规模折算，三百多 GB 的压力，能降到十几 GB 的量级。省下来的全留给缓冲池，这就是隔离的本钱。不用加机器，也能给交易侧留出空间。

再给一个更粗的算法，方便开会用。把向量条数乘维度乘四字节，得到本体大小，再乘副本数。这个数除以集群总内存，就是索引占比。占比过三成，就该考虑省内存的方案。这个算法不准，但足够判断要不要往下谈。

这里要提醒一句。脱离召回率谈内存降幅没有意义，98% 和 90% 是两个世界。别人给的条件不写全，这个数就不能用。我在别的地方踩过这个坑，拿一个百分比去汇报，被问住过一次。

回到索引本身。金仓在向量索引上给了磁盘优先这条路线，DiskANN 那套就是为容量吃紧的场景准备的。索引怎么选，我的经验是三问。内存够不够，决定能不能全放内存。召回要求多高，决定能不能接受近似。数据还会不会涨，决定要不要一步到位。

五、AI数据库的第三招：把峰值错开

第三招和技术无关，只是时间管理。批量入库的峰值在夜里，跑批也在夜里，撞上的概率比想象中高。错开的办法有两个：入库窗口后移，或者把跑批提前。两个都试过，后移更稳，因为跑批依赖上游数据的时间点不好改。

IO 这块还有两个动作值得做。把批量入库的并发压到可控范围，别让它一次吃满。把跑批的临时表空间和入库目录分到不同盘上，两条流互不踩。这两件都不花钱，只是配置。

错开之后还有一个隐性收益。发布会上提到 KES 的备机并行回放提升 1.3 倍，增量检查点带来的性能波动小于 5%。这两个数说明一件事：把 IO 峰值拉开，波动也跟着小。波动小意味着容量不用按最坏情况留三倍余量。

容量规划省下来的余量，最后都变成预算。这一条对技术负责人来说，比性能提升更直接。硬件钱是一次性的，余量是每年都要付的。所以这一招看着最土，算账的时候最值钱。

六、AI数据库资源隔离：三个最常答错的问题

资源隔离是不是就等于数据隔离？ 不是。分开部署解决的是抢资源，不解决谁能看什么。权限还是要在库内配，行级策略和语义级权限一样要开。这两件事混作一体，容易以为分开就安全了。

独立节点是不是要再建一套库？ 不用。有人以为挪出去就得复制一份数据，于是回到同步那条老路。库内方案的独立节点读的是同一份数据，这条别搞反。搞反了，省下的资源会花在运维上。

省了内存是不是就省了容量？ 也不是。内存降了，磁盘和备份还在。备份策略和恢复演练一样都不能少，省下来的是硬件预算。运维责任一分都没少，只是花钱的地方换了。

七、AI数据库上线后，每周看三个数

最后给三个每周要看的数，比看一堆监控面板有用。第一，交易侧 P99 的周中位数，看有没有系统性抬头。第二，向量索引占用与缓冲池的比值，看内存有没有被挤。第三，批量入库的持续时间，看峰值有没有变长。这三个数放进一张周报，AI数据库有没有影响业务，一目了然。

三个数里最先报警的通常是第二个。内存是慢变量，涨上去不容易降下来。等它把缓冲池挤到某个阈值，慢查询会成片出现，那时候再调就来不及了。所以每周看一次，比每月看一次有用。

周报不用长，三行就够。一行写 P99 的周中位数和上周对比。一行写索引占用与缓冲池的比值。一行写入库时长。三行连着看四周，趋势比单点更有说服力。

这三个数的采集不难。P99 从慢查询日志或 APM 里取，按周聚合取中位数，避开单日尖峰。索引占用从视图或监控里取当前值，缓冲池命中率一并记。入库时长看任务日志的起止时间，别只看成功失败。三个数落到同一张表，才谈得上趋势。

写在最后

回到那个同行。他最后没加机器，只做了三件事。把 AI 计算挪到独立节点，把索引换成省内存的方案。再把入库窗口后移两小时。第二周月结回到十二分钟，问数照常用。

代价不是没有。AI 那侧的批量入库多花了十几分钟。但那是独立节点上的事，交易侧没有感觉。这就是隔离的意思。不是把开销消灭，是把它关进另一个池子。

负载打架这件事，多半不是算力不够，是没分开摆。这三招能落地，是因为这些能力本来就长在库里。金仓这一轮把语义、推理、安全三块放进内核。落到运维手上，就是挪出去、省下来、错开。不用为了 AI 再搭一套系统，也不用在第二个地方再配一遍权限。

你们的 AI数据库上线后，交易侧有没有变慢？评论区聊聊。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋