OLTP与OLAP访问模式的本质差异催生独立的数据仓库

本章前半部分讨论的索引结构（哈希索引、SSTable/LSM树、B树）都是为在线事务处理 （OLTP）优化的：应用通常通过某个键查找/插入/更新少量记录，访问模式类似处理一笔 商业交易——磁盘寻道时间往往是瓶颈。但数据库还有一种完全不同的用途：在线分析处理 （OLAP），典型查询是”扫描海量记录、只读每条记录的少数几列、计算汇总统计量”（如 总收入、平均值），而不是取回原始记录本身给用户看——这类查询通常由业务分析师编写， 支撑管理层决策。OLTP和OLAP的差异是全方位的：OLTP主要读少量记录并按键查找，写入 是随机访问且要求低延迟，服务的是通过Web应用交互的终端用户，处理的是数据的最新 状态，数据集通常GB到TB级；OLAP主要在大批量记录上聚合，写入以批量导入（ETL）或 事件流为主，服务的是内部数据分析师，处理的是随时间推移的历史事件，数据集可达TB到 PB级。正因为这两种访问模式对存储引擎的要求截然相反（OLTP要求索引精准定位少量 记录，OLAP要求高效顺序扫描海量记录），企业逐渐停止在同一个OLTP数据库上直接跑分析 查询——那些扫描大部分数据集的分析查询开销巨大，会拖累同时执行的事务性能——转而 把数据通过ETL（抽取-转换-加载）流程复制、转换并加载进一份独立的、专为分析优化的 只读副本，这就是数据仓库，分析师可以在其中自由查询而不影响线上业务系统。

结构图：

flowchart LR
    A[多个OLTP系统: 网站/收银/库存/供应链] -->|ETL: 抽取转换加载| B[数据仓库]
    B --> C[业务分析师: 只读查询, 不影响OLTP]
    A -.OLTP: 按键查少量记录, 随机写低延迟, 数据最新状态.-> A
    B -.OLAP: 大批量记录聚合, 批量导入, 历史事件.-> B