MySQL 用 InnoDB 还是 MyISAM？Redis 选 RDB 还是 AOF？ClickHouse 和 HBase 哪个更适合你的场景？
选错存储引擎，轻则性能下降，重则数据丢失。本指南提供系统的决策框架。
选型决策树
业务类型
│
├── OLTP (事务型)
│ │
│ ├── 强一致性要求
│ │ │
│ │ └── MySQL InnoDB / PostgreSQL
│ │
│ └── 最终一致性可接受
│ │
│ └── MongoDB / Cassandra
│
├── OLAP (分析型)
│ │
│ ├── 实时分析
│ │ │
│ │ └── ClickHouse / Druid
│ │
│ └── 离线批处理
│ │
│ └── Hive / Spark SQL
│
└── KV 存储
│
├── 高性能本地存储
│ │
│ └── RocksDB / LevelDB
│
└── 分布式缓存
│
└── Redis / Memcached| 场景 | 推荐存储 | 理由 |
|---|---|---|
| 电商订单 | MySQL InnoDB | 强一致，事务支持好 |
| 金融交易 | PostgreSQL | 严格的 ACID，MVCC |
| 用户中心 | MySQL InnoDB | 读多写少，主键查询 |
| 游戏装备 | Redis Cluster | 高并发，支持丰富数据结构 |
| 社交 Feed | MongoDB | 文档模型灵活 |
| 场景 | 推荐存储 | 理由 |
|---|---|---|
| 实时大屏 | ClickHouse | 高吞吐，低延迟 |
| 用户行为分析 | Druid | 支持实时摄入，聚合查询 |
| 数据仓库 | Hive/Spark | 离线批处理，生态完善 |
| 日志分析 | Elasticsearch | 全文搜索，倒排索引 |
| 时序数据 | InfluxDB/TimescaleDB | 时序压缩，自动分区 |
| 场景 | 推荐存储 | 理由 |
|---|---|---|
| 日志采集 | Kafka + Elasticsearch | 高吞吐，支持全文搜索 |
| 消息队列持久化 | RocksDB | 高写入性能 |
| 消息存储 | Kafka | 分布式，可回溯 |
| 缓存 | Redis | 内存级延迟 |
读多写少 (90/10):
└── B+ Tree (InnoDB) > 列式存储
写多读少 (10/90):
└── LSM Tree (RocksDB) > B+ Tree
读写均衡 (50/50):
└── 取决于查询复杂度| 数据量 | 推荐存储 | 说明 |
|---|---|---|
| < 1GB | SQLite / MySQL | 轻量，简单部署 |
| 1GB ~ 100GB | MySQL InnoDB | 成熟稳定 |
| 100GB ~ 1TB | PostgreSQL / MongoDB | 可扩展 |
| 1TB ~ 10TB | ClickHouse / Elasticsearch | 列式，高压缩 |
| > 10TB | HBase / Cassandra | 分布式，水平扩展 |
| 一致性需求 | 推荐存储 | 说明 |
|---|---|---|
| 强一致 (线性一致) | PostgreSQL, MySQL InnoDB | 分布式事务代价高 |
| 最终一致 (可接受延迟) | MongoDB, Cassandra | CAP 取舍 |
| 弱一致 (无所谓) | Redis, Memcached | 仅作缓存 |
| 引擎 | 事务 | 并发 | 全文搜索 | 主从复制 | 适用场景 |
|---|---|---|---|---|---|
| InnoDB | ACID | MVCC | 插件 | 异步/半同步 | OLTP |
| MyISAM | 不支持 | 表锁 | 原生 | 异步 | 读多写少 |
| PostgreSQL | ACID | MVCC | 插件/GIN | 逻辑复制 | OLTP/OLAP |
| SQLite | ACID | WAL | FTS5 | 文件复制 | 嵌入式 |
| 引擎 | 数据模型 | 一致性 | 扩展性 | 适用场景 |
|---|---|---|---|---|
| MongoDB | 文档 | 可调 | 分片 | 内容管理 |
| Cassandra | 宽列 | 可调 | 线性 | 时序、消息 |
| HBase | 宽列 | 强一致 | 分片 | 随机读写 |
| Redis | KV/数据结构 | 可调 | 分片/集群 | 缓存、Session |
| 引擎 | 压缩率 | 查询性能 | 实时摄入 | 适用场景 |
|---|---|---|---|---|
| ClickHouse | 高 | 极快 | 支持 | 实时分析 |
| Druid | 高 | 快 | 支持 | 实时+历史 |
| Parquet | 极高 | 中 | 需转换 | 数据湖 |
| Kudu | 中 | 快 | 支持 | OLAP 混合 |
-- Buffer Pool 足够大（热点数据）
innodb_buffer_pool_size = 75% of RAM
-- Redo Log 足够大
innodb_log_file_size = 1GB -- (Buffer Pool * 25%)
innodb_log_files_in_group = 3
-- 独立表空间
innodb_file_per_table = ON
-- 刷盘策略
innodb_flush_log_at_trx_commit = 1Options options = new Options();
options.setWriteBufferSize(64 * 1024 * 1024); // 64MB MemTable
options.setMaxWriteBufferNumber(3); // 3 个 MemTable
options.setLevel0FileNumCompactionTrigger(4); // L0 触发合并
options.setMaxBytesForLevelBase(256 * 1024 * 1024); // L1 256MB
options.setMaxBytesForLevelMultiplier(10); // 每层 10 倍-- MergeTree 表引擎（主表）
CREATE TABLE events (
event_date Date,
event_type String,
user_id UInt32
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_type, user_id)
SETTINGS index_granularity = 8192;
-- MaterializedMySQL（实时同步 MySQL）
CREATE TABLE sync_orders AS mysql('host:3306', 'db', 'orders', 'user', 'pass')
ENGINE = MaterializedMySQL('host:3306', 'db');阶段 1: MySQL 单机
- 数据量 < 100GB
- QPS < 10000
- 单机 MySQL + Redis 缓存
问题: 读写混在一起，缓存命中率低阶段 2: 主从读写分离
- 读: 从库（多个）
- 写: 主库
- 缓存: Redis Cluster
问题: 单机存储瓶颈阶段 3: 分库分表 / NewSQL
- 按业务拆分
- 或迁移到 TiDB / CockroachDB
问题: 跨库查询复杂阶段 4: 混合架构
- OLTP: MySQL 分库分表 / TiDB
- OLAP: ClickHouse / Druid
- 缓存: Redis Cluster
- 消息: Kafka
实时同步: Canal/Debezium (MySQL → Kafka → ClickHouse)NoSQL 在特定场景（高并发写入、海量数据）有优势，但在事务复杂、关联查询多的场景不如关系型数据库。
缓存带来一致性问题和维护复杂度。核心数据不应该过度依赖缓存。
数据迁移虽然成本高，但业务发展超出预期时，更换存储引擎是正确的选择。
决策建议：选型前回答三个问题：数据量多大？并发多高？一致性要求多强？答案清晰了，选择就不难了。