波仔
🗄️ 第八章 活用数据库-在应用程序中使用数据库
📄 一句话概括

大数据＝量大到常规数据库嚼不动的数据，思路从「存好」转向「挖出价值」——OLTP 管日常交易，OLAP 管回头分析，两条流水线各干各的。

📝 本节和前面几节的关系

前七节都在让数据库「又稳又快地服务应用」，本节换视角：数据积累多了本身就是资产。它回收 1-7「分析」那条伏笔——交易库（书评网站每天写的）与分析库（每周算一次的）要分开。

一、大数据的「大」到什么程度

二、OLTP 与 OLAP：一写一读，分工不同

OLTP（联机事务） OLAP（联机分析）
干什么 日常交易：下单、发评论 回头分析：周报、用户画像
读写特征 高频小读写 大规模只读聚合
数据库 MySQL/PostgreSQL 数据仓库（如 BigQuery）、列存引擎
数据形态 当下最新的 历史全量的

流水线：业务库（OLTP）每天抽取 → 数据仓库（OLAP）→ SQL 聚合出报表——两边的表结构都按各自任务优化（行存利交易、列存利聚合）。

三、动手 Demo：同一张表，两种命运

-- OLTP 场景：用户刚发了一条书评（高频小写）
INSERT INTO reviews (user_id, isbn, score, comment)
VALUES (1, '9787115428028', 5, '好书！');

-- OLAP 场景：月底分析「各月书评量与均分」（一次大读）
SELECT substr(created_at, 1, 7) AS 月份,
       COUNT(*)          AS 书评量,
       AVG(score)        AS 均分
FROM reviews
GROUP BY 月份
ORDER BY 月份;

【准备块】5-19 的 book_review 库；体会一句写、一句算，性格完全不同——量大时第二条就该搬进数据仓库了。

四、30 秒实验

想便利店：收银机每扫一件货就是 OLTP（又快又碎）；老板月底看「哪个啤酒卖最好」是 OLAP（量大慢算）。收银不会因为做月报而变卡——因为两条线分开了。这就是 OLTP/OLAP 分离的全部意义。

五、常见误区

自测三问 1. OLTP 与 OLAP 的分工？（日常高频交易 vs 历史只读聚合——行存利交易、列存利聚合） 2. 大数据的 3V？（量大、增速快、种类杂） 3. 为什么报表不该跑在业务库上？（全表聚合拖垮在线服务——分析去数据仓库，两线分离）

相关笔记