为什么 OLTP 与 OLAP 负载很少应该放在同一数据库中

OLTP vs OLAP：它们是什么（无行话）

当人们说“OLTP”和“OLAP”时，他们在讲数据库被使用的两种非常不同的方式。

OLTP：支撑业务运行的数据库

OLTP（在线事务处理） 是支撑日常操作的负载，要求每次都快速且正确。想想：“现在就保存这个变更。”

典型的 OLTP 任务包括创建订单、更新库存、记录付款或更改客户地址。这些操作通常很小（几行）、频繁，并且需要在毫秒级内响应，因为有用户或其他系统在等候。

OLAP：解释业务的数据库

OLAP（在线分析处理） 用来理解发生了什么以及原因。想想：“扫描大量数据并汇总它。”

典型的 OLAP 任务包括仪表板、趋势报告、分群分析、预测，以及“切片与切块”类问题，比如：“过去 18 个月里按区域和产品类别的收入如何变化？”这些查询通常读取大量行，执行复杂聚合，运行时间可为几秒（甚至几分钟），并且允许稍长的延迟。

同样的数据，不同的目标——以及不同的需求

核心思想很简单：OLTP 优化写入速度与一致性、以及小规模读取，而OLAP 优化大规模读取与复杂计算。因为目标不同，最佳的数据库设置、索引、存储布局和扩展策略通常也不同。

也要注意措辞：是很少，而不是永不。一些小团队在数据量低且查询有纪律的情况下，短期内可以共用一个数据库。后面章节会讨论首先会出现的问题、常见的分离模式，以及如何安全地将报表迁离生产环境。

快速示例

• 结账（OLTP）： 客户点击“支付”，应用写入订单、支付状态和库存更新。
• 报表仪表板（OLAP）： 经理打开一个汇总成千上万（或百万）订单的仪表板来显示转化率、平均订单价值和周度趋势。

不同目标，不同成功指标

OLTP 和 OLAP 可能都“用 SQL”，但它们为不同工作而优化——这体现在各自认为的成功是什么上。

OLTP：速度、并发与正确性

事务系统支撑日常操作：结账流程、账户更新、预定、支持工具。优先级很明确：

• 快速响应，针对小规模读/写（以毫秒计）
• 大量并发用户 而不致变慢
• 正确性与一致性，因为错误的余额或重复订单会带来真实的业务问题

成功通常用延迟指标（如 p95/p99 请求时间）、错误率以及系统在高并发下的表现来衡量。

OLAP：扫描、聚合与灵活性

分析系统回答诸如“本季度发生了什么变化？”或“新定价后哪个分段流失了？”之类问题。这些查询通常：

• 扫描大量数据（许多行）
• 执行 聚合（SUM、COUNT、分位数）和连接
• 在分析师探索问题时频繁变化

成功在这里更像是 查询吞吐量、洞察获得时间（time-to-insight），以及在无需手工微调每份报表的情况下运行复杂查询的能力。

为什么“一个系统搞定一切”会产生权衡

当你强迫两种负载在一个数据库上运行时，你是在要求它既要擅长微小高频的事务，也要擅长大型探索性扫描。结果通常是妥协：OLTP 出现不可预测的延迟，OLAP 被节流以保护生产环境，团队之间也会为谁的查询“被允许”而争论。不同的目标应有不同的成功指标——通常也应有不同的系统。

资源争用：当分析抢走事务的资源时

当 OLTP（应用的日常事务）和 OLAP（报表与分析）在同一数据库上运行时，它们会争用相同的有限资源。结果不仅是“报表变慢”。通常会出现结账变慢、登录停滞和不可预测的应用故障。

CPU 与内存：长查询 vs 短查询

分析查询往往运行时间长且资源重：跨大表的连接、聚合、排序与分组。它们可能占用大量 CPU 核心和用于哈希连接与排序缓冲的内存。

与此同时，事务查询通常很小但对延迟敏感。如果 CPU 饱和或内存压力导致频繁驱逐，那些小查询就会排在大查询后面等待——即便每个事务实际只需要几毫秒工作时间。

磁盘 I/O：大规模扫描 vs 许多小读写

分析会触发大表扫描并顺序读取大量页面。OLTP 则是许多小型随机读以及对索引和日志的持续写入。

混在一起后，存储子系统必须调度不兼容的访问模式。原本有助于 OLTP 的缓存可能被分析扫描“洗掉”，当磁盘忙于为报表流式读取数据时，写入延迟也可能激增。

连接池压力与排队

少数分析师运行宽范围查询可能会占用连接数达数分钟。如果应用使用固定大小的连接池，请求会排队等候可用连接。排队效应会让健康系统感觉像坏了：平均延迟可能看起来可接受，但尾延迟（p95/p99）会痛苦地增长。

用户实际感受到的情况

从外部看，这是超时、结账变慢、搜索结果延迟和总体不稳定的行为——通常是“仅在报表运行时”或“仅在月底”。应用团队看到错误；分析团队看到慢查询；真正的问题是下面的共享争用。

数据布局与索引需求朝相反方向拉扯

OLTP 与 OLAP 不仅“以不同方式使用数据库”——它们在物理设计上也有相反的偏好。当你试图在一处满足两者时，通常会得到既昂贵又仍然表现不佳的折中方案。

OLTP：为快速、选择性查找优化

事务负载由短查询主导，这些查询只触及数据的很小一部分：获取一个订单、更新一行库存、列出某个用户的最近 20 条事件。

这推动 OLTP 模式倾向于行式存储和支持点查找与小范围扫描的索引（通常是主键、外键和少量高价值的二级索引）。目标是可预测的低延迟，尤其是写入。

OLAP：为扫描、分组与汇总优化

分析负载通常需要读取大量行但只需少数列：“按周按区域的收入”、“按投放活动的转化率”、“按利润率的热门商品”。

OLAP 系统受益于列式存储（只读取所需列）、分区（快速裁剪过期或无关数据）以及预聚合（物化视图、汇总表），以避免报表重复计算相同总和。

为什么“为所有东西建立索引”会适得其反

一个常见反应是添加索引直到每个仪表板都变快。但每个额外索引都会增加写入成本：插入、更新和删除现在需维护更多结构。它也增加了存储并可能拖慢像 vacuum、重建索引和备份这样的维护工作。

查询规划器与统计信息漂移（通俗说法）

数据库基于统计信息选择查询计划——估计有多少行匹配过滤条件、索引的选择性及数据分布。OLTP 的数据在不断变化。随着分布转移，统计信息会漂移，规划器可能选择昨天很优但今天很慢的计划。

混入重度 OLAP 查询（大规模扫描和连接）会增加变异性：“最优计划”变得难以预测，为一种工作负载调优往往会让另一种变差。

锁、MVCC 与维护的副作用

即便数据库“支持并发”，将重度报表与实时事务混合也会产生微妙的慢化，难以预测——更难向盯着转圈图标的客户解释清楚原因。

长查询仍会引起锁问题

OLAP 型查询常常扫描大量行、连接多张表并运行数秒或数分钟。在此期间它们可能持有锁（例如针对模式对象，或在需要将排序/聚合写入临时结构时），并且它们经常通过保持许多行“在处理过程中”间接增加锁竞争。

即便使用 MVCC（多版本并发控制），数据库也必须跟踪相同行的多个版本以避免读写互相阻塞。这有帮助，但并不能消除争用——尤其是当查询触及事务频繁更新的热点表时。

MVCC 的隐性成本：清理变得更难

MVCC 意味着旧的行版本会保留直到数据库可以安全地删除它们。长时间运行的报表可能保持旧快照打开，这会阻止清理回收空间。

这会影响：

• vacuum/垃圾回收： 无法尽快移除死元组/版本。
• 膨胀/碎片化： 存储增长，索引效率下降，缓存价值减弱。
• 压缩压力： 一些引擎会通过更激进的后台工作来响应，进而窃取事务的 I/O 与 CPU。

结果是双重打击：报表让数据库工作量增加，且随着时间推移系统会变慢。

隔离级别放大延迟的可变性

报表工具经常请求更强的隔离（或无意中在长事务中运行）。更高的隔离会增加对锁的等待并增加引擎必须管理的版本数量。从 OLTP 角度看，你会看到不可预测的延迟峰值：大多数订单写入很快，但少数突然滞后。

实例：月末报表导致下单变慢

在月底，财务运行一个“按产品的月度收入”查询，扫描整个月的订单和品项。在查询运行期间，新订单仍被接受，但 vacuum 无法回收旧版本，索引发生大量 churn。订单 API 开始出现偶发超时——并不是因为它“宕机”，而是争用和清理开销悄悄把延迟推到了你的阈值之上。

工作负载的突发性与不可预测延迟

OLTP 系统靠可预测性生存。一次下单、支持工单或余额更新如果“95% 时间都快”仍然不能接受——用户会注意到变慢的时刻。相比之下，OLAP 常常是突发性的：少量沉重查询可以长时间不出现，然后突然消耗大量 CPU、内存与 I/O。

突发是由正常业务原因引起的

分析流量常在例行时刻集中：

• 早上的“例会仪表板”，许多人同时刷新相同图表
• 定时报表在整点同时触发
• 月末结账和季度回顾触发长时间的扫描与连接

与此同时，OLTP 流量通常更稳定（至少更持续）。当两种工作负载共用一个数据库时，这些分析突发会转化为事务的不可预测延迟——超时、页面加载慢和偶发重试会进一步增加负载。

限制与调度有帮助，但不能根本解决不匹配问题

通过在夜间运行报表、限制并发、强制语句超时或设置查询成本上限等策略可以降低损害。这些是有价值的防护措施，尤其是针对“在生产上做报表”。

但它们并不能移除根本张力：OLAP 查询天生就设计为使用大量资源来回答大问题，而 OLTP 需要全天候的小、快的资源片段。一旦有意外的仪表板刷新、临时查询或回填任务穿过这些护栏，共享数据库就会再次暴露问题。

噪声邻居问题

在共享基础设施上，一个“吵闹”的分析用户或作业可能会占用缓存、饱和磁盘或施压 CPU 调度——而它并没有犯错。OLTP 工作负载变成了附带损害，最难的是这些故障看上去是随机的：是延迟峰值而不是清晰可复现的错误。

运维复杂度：备份、安全与容量规划

混合 OLTP（事务）与 OLAP（分析）不仅造成性能头疼——也让日常运维更难。数据库变成一个“全能盒子”，每个运维任务都继承了两类工作负载的风险。

备份、恢复与灾难恢复变慢

分析表往往增长得又宽又快（更多历史、更多少列、更多少汇总）。额外的数据量改变了你的恢复策略。

完整备份耗时更长、占用更多存储，并增加错过备份窗口的风险。恢复更糟：当你需要快速恢复时，不仅需要恢复应用所需的事务数据，还要恢复大量并非业务启动所必需的分析数据。灾难恢复测试也更耗时，因此发生频率会降低——这正好与你想要的相反。

容量规划变成猜测游戏

事务增长通常可预测：更多客户、更多订单、更多行。分析增长常常不稳定：新仪表板、新保留策略，或某个团队决定保留“再多一年”的原始事件数据。

当两者共存时，你很难回答：

• 我们的增长是因为产品成功，还是因为报表保留了更多历史？
• 我们需要更快的存储来支撑事务，还是需要更多廉价的存储来存放分析数据？

这种不确定性导致过度配置（为不必要的余量付费）或配置不足（意外宕机）。

惩罚性护栏更难公平地执行

在共享数据库中，一个“无害”的查询可能演变成事故。你会加上护栏，例如查询超时、工作负载配额、定时报表窗口或工作负载管理规则。这些有帮助，但也很脆弱：应用和分析师现在要竞争相同的限制，为一方改动策略可能会破坏另一方。

安全与权限控制变得混乱

应用通常需要窄而有针对性的权限。分析师常常需要跨表的广泛只读访问以便探索与验证。将两者放在同一个数据库会增加给予更宽权限以“使报表工作” 的压力，从而扩大失误的冲击范围并增加看到敏感运营数据的人数。

扩展与成本：你会付出双倍（或更糟）的代价

试图在同一数据库上运行 OLTP 与 OLAP 看起来更便宜——直到你开始扩展。问题不仅在性能。每种工作负载的“正确”扩展方式通常推动你采用不同的基础设施，合并它们会迫使你做出昂贵的妥协。

OLTP 的扩展以写为驱动（通常痛苦）

事务系统受写入约束：大量小更新、严格延迟和需要立即吸收的突发。扩展 OLTP 通常意味着纵向扩展（更强的 CPU、更快的磁盘、更多内存），因为写密集型工作负载不容易水平扩展。

当纵向达到极限，你会考虑分片或其他写扩展模式。这会增加工程开销，并常常需要对应用做出细致修改。

OLAP 的扩展以计算为驱动（通常是弹性的）

分析工作负载以长时间扫描、重度聚合和大量读取吞吐为特征。OLAP 系统通常通过增加分布式计算来扩展，许多现代架构将计算与存储分离，这样你可以在不复制数据的情况下增加查询算力。

如果 OLAP 与 OLTP 共享数据库，你就无法独立扩展分析。你要扩展整个数据库——即便事务部分并不需要更多资源。

隐形账单：为分析支付 OLTP 级别的资源

为了在运行报表时保持事务快速，团队会对生产数据库进行过度配置：额外的 CPU 余量、高端存储和更大的实例“以防万一”。这意味着你在为 OLAP 行为支付 OLTP 的价格。

分离后每个系统可以按其职责调整规模：OLTP 针对可预测的低延迟写入，OLAP 针对突发的大量读取。结果通常更便宜——尽管是“两套系统”——因为你不再为在生产上运行报表而购买高端事务资源。

常见架构：将 OLTP 与 OLAP 分开

大多数团队通过添加第二个“面向读取”的系统来把**事务性负载（OLTP）与分析负载（OLAP）**分离，而不是强迫一个数据库承担两者。

模式 1：用于报表的只读副本

常见的第一步是为 OLTP 数据库建立只读副本（或 follower），让 BI 工具在上面运行查询。

优点：最小的应用改动、熟悉的 SQL、快速搭建。

缺点：它仍然是相同的引擎与模式，繁重报表仍可能使副本 CPU/I/O 饱和；有些报表需要副本上不可用的功能；复制延迟会让数据落后几分钟或更久。延迟也会在事故期间引发“为什么和生产不一致？”的困惑。

最佳适配：小团队、适度数据量、“几分钟级”近实时可接受且报表查询受控的场景。

模式 2：专用数据仓库 / 分析数据库

在这种方式中，OLTP 保持为写与点查优化，而分析放到为扫描、压缩和大规模聚合设计的数据仓库（或列式分析数据库）。

优点：OLTP 性能可预测、仪表板更快、分析并发更好、更清晰的成本/性能调优。

缺点：你需要运维另一个系统，并构建一个对分析友好的数据模型（通常是星型模式）。

最佳适配：数据增长、利益相关者众多、复杂报表或严格的 OLTP 延迟要求。

模式 3：基于 CDC 的管道到分析

与周期性 ETL 不同，你可以使用 CDC（变更数据捕获） 从 OLTP 日志流式传输变更到仓库（通常配合 ELT）。

优点：数据更新鲜且对 OLTP 影响小，增量处理更容易，且审计性更好。

缺点：更多活动部件，需谨慎处理模式变更。

最佳适配：较大数据量、高新鲜度需求且具备数据管道能力的团队。

如何安全地把数据从 OLTP 送到 OLAP

把数据从事务数据库（OLTP）移动到分析系统（OLAP）不仅仅是“复制表”，而是构建可靠且低影响的管道。目标很简单：分析方得到所需的数据，同时不危及生产流量。

ETL vs ELT（通俗版）

ETL（抽取、转换、加载） 是在加载到仓库之前先清洗与重塑数据。当仓库计算昂贵或你希望严格控制存储内容时，这很有用。

ELT（抽取、加载、转换） 是先把较原始的数据加载进仓库，再在仓库内转换。这通常更易于搭建与演进：你可以保留“可信来源”的历史并在需求变化时调整转换逻辑。

实用规则：如果业务逻辑经常变化，ELT 可以减少重复工作；如果治理要求只存放经过策划的数据，则 ETL 更合适。

CDC 基本概念：在不做重扫描的情况下捕获变更

变更数据捕获（CDC） 将 OLTP 的插入/更新/删除（通常来自数据库日志）流向分析系统。与反复扫描大表不同，CDC 只移动发生变化的部分。

它能实现：

• 近实时报表，而无需在生产上跑大读操作
• 回放与补跑，在需要重建分析表时更方便
• 历史追踪（谁何时改了什么），如果你保存变更事件的话

数据新鲜度：实时 vs 几分钟级 vs 每日

新鲜度是一个业务决策，伴随技术成本：

• 实时（秒级）： 适用于运维型仪表板，但最难稳定；管道小故障会立即显现。
• 近实时（分钟级）： 常见的折中：利于决策且复杂度适中。
• 每日批次： 最简单最便宜，适合“昨天的数据就够用”的财务报表。

定义明确的 SLA（例如：“数据延迟不超过 15 分钟”），让利益相关者知道“新鲜”的含义。

防止静默失败的数据质量检查

管道常常悄然出错——直到有人发现数据不对。添加轻量级检查：

• 模式变更监测： 新列、重命名字段或类型变化会导致数据变空。
• 迟到事件处理： 几小时后到达的订单或付款；用“回溯窗口”处理。
• 去重： 重试与回放可能导致双计；使用稳定 ID 和幂等加载。

这些保障能让 OLAP 更可信，同时保护 OLTP 不受影响。

何时共用一个数据库是可以接受的

将 OLTP 和 OLAP 放在一起并非自动“错误”。当应用小、报表需求窄且你能强制执行严格边界以防分析意外影响客户（慢结账、失败支付或超时）时，这可以是一个合理的临时选择。

适用情形

轻量分析且严格查询限制的小型应用 往往可以在单一数据库上正常工作——尤其是在早期。关键是诚实定义“轻量”意味着什么：少量仪表板、适度行数，以及对查询运行时间和并发有明确上限。

对于一组固定的经常性报表，使用物化视图或汇总表可以降低分析成本。你预先计算每日汇总、热门类别或按客户汇总，而不是每次扫描原始事务表。这样大多数查询都保持短且可预测。

如果业务方能容忍数据延迟，非高峰报表窗口 也有帮助。把较重的作业安排在夜间或低流量时段，并考虑为报表设置专门角色、紧缩权限与资源限制。

应该加的护栏

• 设置语句超时并取消失控查询。
• 为报表用户限制并发。
• 分别监控核心事务的 p95/p99 与报表延迟。

明确的警告信号，说明该拆分了

如果你看到事务延迟上升、报表运行时反复故障、连接池耗尽或“某个查询把生产拖垮”这样的故事，你已超出安全区。到那时，分离数据库（或至少使用只读副本）不再是优化，而是基本的运维卫生措施。

实用迁移清单：从共享到分离

把分析迁出生产数据库更像是把工作可见化、设定目标并按受控步骤迁移，而不是一次性大重写。

1) 清点当前实际发生的事情

从证据开始，而不是假设。列出：

• 按频率和 p95/p99 延迟排序的顶级 OLTP 端点/查询（结账、登录、创建订单等）
• 按运行时间、扫描量和业务重要性排序的顶级 OLAP 报表/仪表板

包括“隐藏的”分析：BI 的零散 SQL、定时导出和 CSV 下载。

2) 定义目标：OLTP 的 SLO 与分析新鲜度

写下你要优化的目标：

• OLTP SLO：必须维持的 p95/p99 延迟、错误率与峰值吞吐
• 分析新鲜度：可接受的延迟（5 分钟、1 小时、次日），以及管道故障时的重建时间

这可避免“慢了”与“可接受”之争，并帮助选对架构。

3) 选择分离路径

选择满足目标的最简单方案：

• 只读副本： 对读密集报表最快上手，但仍可能受副本压力与延迟影响
• 仓库： 适合大规模扫描、多连接与长期历史；通常是 BI 的合适归宿
• CDC 管道（ETL/ELT）： 需要近实时而又不压生产时的最佳方案

4) 安全部署（先并行运行）

1. 验证定义（时区、退款、“活跃用户”等），确保口径一致。
2. 在完整业务周期内并行运行旧报表与新报表进行校验。
3. 报表按次切换，从最痛点的查询开始。
4. 一旦利益相关者信任新来源，锁定直接“在生产上做报表”的访问。

5) 加入护栏以防回归

监控副本延迟/管道延迟、仪表板运行时间和仓库花费。设置查询预算（超时、并发限制），并保留事故处理手册：新鲜度下降、负载激增或关键指标分歧时的应对步骤。

一个针对应用构建者的实用提示

如果你还在产品早期快速迭代，最大风险是无意中把分析构建到与核心事务同一路径（例如，某些仪表板查询悄然变成“生产关键”）。避免这一点的做法是从一开始就设计分离——即便是用一个小型只读副本起步——并把它写进你的架构检查清单。

像 Koder.ai 这样的平台可以在此帮助你，因为你可以在规划模式下原型化 OLTP 侧（React 应用 + Go 服务 + PostgreSQL）并勾画报表/仓库边界。在产品增长时，你可以导出源代码、演进模式并添加 CDC/ELT 组件，而不会把“在生产上做报表”变成永久习惯。