1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

                          数据存储生态
                              │
       ┌──────────────────────┼──────────────────────┐
       │                      │                      │
   关系数据库               NoSQL                  大数据生态
   (RDBMS)                  (非关系)               (数据湖/数仓)
       │                      │                      │
   ┌───┴───┐            ┌─────┴─────┐          ┌────┴─────┐
   │       │            │           │          │          │
  OLTP   OLAP          键值/列族  文档/图形   数据仓库   数据湖
  MySQL  Doris         Redis     MongoDB    Snowflake  S3/HDFS
  PG     ClickHouse    Cassandra Neo4j      BigQuery
  Oracle StarRocks     DynamoDB
        Snowflake

   横切维度：
   ───────────────────────────────
   HTAP       TiDB / CockroachDB / SingleStore
   Lakehouse  Iceberg / Hudi / Delta / Paimon
   时序       InfluxDB / TimescaleDB / Prometheus
   图         Neo4j / JanusGraph / NebulaGraph

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

按数据模型：
  - 关系：MySQL / PG / Oracle
  - 键值：Redis / DynamoDB
  - 列族：Cassandra / HBase / Bigtable
  - 文档：MongoDB / CouchDB
  - 图：Neo4j / Dgraph
  - 时序：InfluxDB / TimescaleDB
  - 全文：Elasticsearch

按负载类型：
  - OLTP（联机事务处理）：高并发短事务
  - OLAP（联机分析处理）：长查询聚合
  - HTAP（混合）：两者兼顾

按部署形态：
  - 单机：传统 RDBMS
  - 分布式：Cassandra / HBase / Spanner
  - 云原生：Snowflake / BigQuery / Aurora
  - 一体机：Oracle Exadata / Teradata

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

OLTP 工作负载：
  - 大量短事务（毫秒级）
  - 高并发（数千 QPS）
  - 按主键点查、按索引范围查
  - 严格 ACID
  - 行存为主

典型业务：
  - 电商交易
  - 银行账户
  - 用户登录
  - 在线游戏

1
2
3
4
5
6
7

OLTP 不擅长：
  - 跨表大规模聚合（数据分析）
  - 千万行以上的范围扫描
  - 复杂的窗口函数
  - 海量历史数据存储

→ 这些场景交给 OLAP / 数据仓库

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

OLAP 工作负载：
  - 少量长查询（秒~分钟级）
  - 大范围扫描
  - 多维聚合（GROUP BY 多列）
  - 容忍弱一致性
  - 列存为主

典型业务：
  - BI 报表
  - 实时大屏
  - 用户行为分析
  - 日志检索

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

传统 OLAP（MPP）：
  - Teradata（一体机）
  - Greenplum（PG 衍生）
  - Vertica（列存）
  - Neteeza（IBM，已停）

新一代 OLAP：
  - ClickHouse：极致单表性能
  - Apache Doris：开箱即用的实时数仓（详见本博客 Doris 系列）
  - StarRocks：Doris 商业升级，联邦查询强
  - Apache Druid：时序 + 实时分析
  - Apache Pinot：LinkedIn 出品，类似 Druid

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

                高并发查询
                    ↑
                    │
            Doris   │   Druid
                    │   Pinot
   ─────────────────┼──────────────→  实时性
                    │
            ClickHouse
                    │
                    │   Greenplum
                    │   Vertica
                    ↓
                海量批处理

1
2
3
4

本博客已发布的 OLAP 笔记（坐标定位，不再展开）：
  - Elasticsearch 系列：搜索引擎 + 实时分析
  - Doris 系列：实时数仓 / OLAP
  - Redis 系列：缓存（KV，不是 OLAP 但常配合）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

传统架构：
  OLTP（MySQL）→ CDC / ETL → OLAP（ClickHouse / Hive）
  问题：
  - 数据延迟（T+1 或分钟级）
  - 数据冗余（多套存储）
  - ETL 维护复杂
  - 一致性难保证

HTAP 目标：
  一个数据库同时扛 OLTP + OLAP
  - 实时（无 ETL）
  - 单一数据源
  - 简化架构

1
2
3
4
5
6
7
8
9

思路 1：行列双存（Oracle IMCS / TiDB TiFlash）
  - 行存（用于 OLTP）+ 列存（用于 OLAP）
  - 后台同步两份

思路 2：单存优化（SingleStore）
  - 一种"通用"存储同时支持两种负载

思路 3：存算分离 + 多引擎（Snowflake / BigQuery）
  - 计算层动态选择执行引擎

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

代价：
  - 写入放大（双存）
  - 资源占用高
  - 调优复杂（两套优化）
  - 不可能同时极致优化两种负载

适用场景：
  - 中等规模（TB 级）
  - 实时分析需求强
  - 不想维护 ETL 链路

不适用：
  - 超大规模 OLAP（PB 级）→ 单独的 OLAP 引擎
  - 极致 OLTP 性能 → 单纯的 OLTP

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

数据仓库（Inmon 定义）：
  - 面向主题
  - 集成
  - 时变
  - 非易失

特点：
  - 来自多个源系统的统一数据存储
  - 用于决策支持、报表、分析
  - 历史 ETL 数据沉淀

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

第一代：单机数据库 + OLAP 工具（90s）
  - Oracle / SQL Server + Hyperion / BO

第二代：MPP 数据仓库（2000s）
  - Teradata / Greenplum / Vertica
  - Shared-Nothing 架构
  - 性能远超单机

第三代：Hadoop / Hive（2010s）
  - 基于 HDFS
  - 便宜但慢
  - 离线数仓 T+1

第四代：云原生数仓（2015+）
  - Snowflake / BigQuery / Redshift
  - 存算分离
  - 弹性扩展
  - 按用量付费

第五代：实时数仓 / Lakehouse（2020+）
  - Doris / StarRocks
  - Iceberg / Hudi / Delta
  - 实时 + 离线一体

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

数据分层（Kimball 模型）：

  ODS（原始数据层）：源系统原始数据
       │
       │ 清洗、转换
       ▼
  DWD（明细数据层）：标准化的事实明细
       │
       │ 轻度聚合
       ▼
  DWS（汇总数据层）：按主题汇总
       │
       │ 业务加工
       ▼
  ADS（应用数据层）：报表、大屏、API 数据

ETL 工具：Hive / Spark / Flink / dbt

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

Snowflake（2015）：
  - 完全 SaaS，无运维
  - 存算分离（S3 + 计算）
  - 多云（AWS / Azure / GCP）
  - 按用量付费
  - 自动扩展

BigQuery（2010）：
  - Google 内部 Dremel 开源
  - Serverless
  - PB 级查询
  - 标准 SQL

Redshift（2013）：
  - AWS 的 MPP 数仓
  - ParAccel 改造
  - 性价比好

Azure Synapse：
  - 微软的云数仓
  - 整合 Power BI / ADF

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

传统架构痛点：
  数据湖（HDFS/S3 + 文件）：
  - 便宜，能存所有数据
  - 但没有事务、没有 schema 强制
  - "数据沼泽"

  数据仓库：
  - 强 schema、ACID
  - 但贵、闭环

Lakehouse：把数据仓库的特性（ACID、schema、查询）带到数据湖上

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

开源三剑客 + 一匹黑马：

Apache Iceberg（Netflix）：
  - 表格式
  - ACID 事务（基于快照）
  - 时间旅行
  - Schema 演化
  - 分区演化
  - Spark / Flink / Trino / Doris / StarRocks 都支持

Apache Hudi（Uber）：
  - 表格式 + 数据管理
  - 支持 Upsert（更新插入）
  - 增量查询
  - CDC 友好

Delta Lake（Databricks）：
  - Databricks 出品
  - ACID 事务
  - 与 Spark 深度集成
  - 商业版有优化

Apache Paimon（Flink 表格）：
  - 流批一体
  - Flink 主推
  - 中国社区活跃（阿里主导）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

       ┌────────────────────────────────────────┐
       │         查询引擎（计算层）              │
       │   Spark / Flink / Trino / Doris        │
       └──────────────────┬─────────────────────┘
                          │
                          │ 读 / 写表格式
                          ▼
       ┌────────────────────────────────────────┐
       │       表格式（元数据 + 事务）           │
       │   Iceberg / Hudi / Delta / Paimon      │
       └──────────────────┬─────────────────────┘
                          │
                          │ 元数据指向数据文件
                          ▼
       ┌────────────────────────────────────────┐
       │         对象存储（存储层）              │
       │   S3 / OSS / HDFS / Azure Blob         │
       └────────────────────────────────────────┘

特点：
  - 存储、表格式、计算解耦
  - 每层可独立选择
  - 多引擎共享同一份数据
  - 弹性扩展

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

NoSQL = Not Only SQL
不同 NoSQL 解决不同问题：

KV（键值）：
  - Redis / Memcached（内存）
  - DynamoDB / etcd（持久）
  特点：极致性能，简单数据模型

列族（Wide Column）：
  - Cassandra / HBase / ScyllaDB
  特点：超高写入吞吐，海量稀疏数据

文档（Document）：
  - MongoDB / CouchDB
  特点：JSON 数据，灵活 schema

图（Graph）：
  - Neo4j / Dgraph / NebulaGraph
  特点：关系密集数据（社交、推荐）

时序（Time Series）：
  - InfluxDB / TimescaleDB / Prometheus
  特点：时间戳索引，写入密集

全文检索：
  - Elasticsearch / OpenSearch / Solr
  特点：倒排索引，文本搜索（详见本博客 ES 系列）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

CAP 定理（Brewer）：
  - C（Consistency）：一致性
  - A（Availability）：可用性
  - P（Partition tolerance）：分区容忍

只能选两个（实际上 P 必选，所以是 C vs A）：

CP：Cassandra（默认）/ HBase / MongoDB
AP：CouchDB / DynamoDB（默认）

不同选择对应不同业务场景：
  - 银行 / 关键业务：CP（保证一致）
  - 社交 / 推荐：AP（容忍最终一致）

1
2
3
4
5
6
7

BASE = Basically Available + Soft state + Eventually consistent
对应 ACID 的对立面

最终一致性的典型场景：
  - 微信朋友圈：你刚发的动态，朋友可能延迟 1 秒看到
  - 电商库存：超卖允许（事后对账）
  - 用户画像：分钟级同步

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

Q1：你的负载是 OLTP 还是 OLAP？
  → OLTP：看 Q2
  → OLAP：看 Q4
  → 两者都有：看 Q6（HTAP）

Q2：数据规模？
  → 单库 < 5TB：MySQL / PostgreSQL
  → 单库 > 5TB 但可控：分库分表（ShardingSphere / Vitess）
  → 单库压不下：分布式数据库（TiDB / CockroachDB）

Q3：业务复杂度？
  → 简单 CRUD：MySQL
  → 复杂查询 / JSON / GIS：PostgreSQL
  → 微软生态：SQL Server
  → 预算充足 / 关键业务：Oracle

Q4：查询模式？
  → 实时多维分析：Doris / StarRocks
  → 单表极致性能：ClickHouse
  → 时序 + 分析：Druid / Pinot
  → 文本搜索：Elasticsearch

Q5：数据规模 + 实时性？
  → PB 级 + 离线：Hive / Spark on S3
  → PB 级 + 实时：Lakehouse（Iceberg / Hudi）
  → TB 级 + Serverless：Snowflake / BigQuery

Q6：HTAP 评估？
  → 数据规模 TB 级 + 不想维护 ETL：TiDB / CockroachDB
  → 关键业务 + 预算充足：Oracle IMCS / OceanBase

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

典型组合：

  小型 SaaS（百万级用户）：
    MySQL（OLTP）+ Redis（缓存）+ Elasticsearch（搜索）

  互联网公司（亿级用户）：
    MySQL 分片 + Redis 集群 + Doris（实时数仓）+ Hive（离线）

  传统企业（关键业务）：
    Oracle RAC（核心）+ SQL Server（部门）+ Power BI

  数据驱动公司：
    PostgreSQL（业务）+ Snowflake（数仓）+ dbt（ETL）

  IoT / 监控：
    TimescaleDB / InfluxDB（时序）+ Grafana（可视化）

  推荐系统：
    MySQL / TiDB（OLTP）+ Neo4j（图）+ ClickHouse（行为分析）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

1. 关系数据库的"原理"是共通的
   - 四大家解决同一组问题
   - 只是命名和细节不同
   - 学透一个，迁移成本很低

2. 选型看场景
   - 没有最好的数据库
   - 只有最合适的数据库
   - 选错比"不会用"代价大

3. 底层原理决定上限
   - 性能调优必须懂底层
   - 排错必须懂底层
   - 升级迁移必须懂底层

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

本系列是"原理地图"，深入某一项可看：

  存储引擎：
    《Database Internals》（Alex Petrov）
    《Designing Data-Intensive Applications》（Martin Kleppmann）

  事务：
    《Transaction Processing》（Jim Gray）
    《Database System Concepts》（Silberschatz）

  PostgreSQL：
    《The Internals of PostgreSQL》
    官方文档"Internals"章节

  MySQL：
    《MySQL 实战 45 讲》（林晓斌）
    《High Performance MySQL》

  分布式：
    《Designing Data-Intensive Applications》
    Raft Paper / Paxos Paper

  数仓 / Lakehouse：
    Kimball《数据仓库工具箱》
    Iceberg / Hudi / Delta 官方文档

1
2
3
4

记住三句话：
  1. 数据库原理是一张网，不是一条线
  2. 选型 = 场景 + 约束 + 经验，没有标准答案
  3. 学无止境——技术会过时，原理不会