概念解析与选型
0. 引言
前七章覆盖了分布式数据库的架构、机制与案例，本章辨析四个高频概念（云原生、HTAP、图、内存），并给出可落地的选型框架：先看概念之间的差异，再按维度与场景推荐，最后权衡一致性与迁移成本。
1. 四大概念辨析
| 概念 | 关注点 | 核心特征 | 与传统关系库差异 | 代表 |
|---|---|---|---|---|
| 云原生数据库 | 部署形态 | 计算存储分离、资源池化、托管运维 | 存算分离、弹性 | Amazon Aurora、TiDB、Snowflake |
| HTAP | 负载融合 | 行存服务事务 + 列存服务分析，异步同步保持准实时一致 | 行列混合，一套系统兼 OLTP/OLAP | TiDB（TiFlash）、PolarDB |
| 图数据库 | 数据模型 | 节点（Node）+ 边（Edge）建模关系，擅长多跳关联查询 | 关系优先，查询沿边遍历 | Neo4j、Nebula Graph、JanusGraph |
| 内存数据库 | 存储介质 | 数据主要驻留内存，持久化靠 WAL 或异步落盘 | 内存为主，微秒级读写 | Redis、VoltDB、SAP HANA |
- 云原生是部署形态的变革：计算节点无状态、弹性扩缩，存储独立扩展，其分片与副本机制仍建立在分片与复制原理之上；
- HTAP 的价值在于避免 OLTP 与 OLAP 分库 ETL 的延迟与冗余；
- 图数据库分原生图存储（Neo4j、Nebula Graph）与基于宽表（JanusGraph 底层 HBase/Cassandra），适用于社交网络、知识图谱、风控关系；
- 内存数据库的局限是成本随内存容量上升，且需持久化机制防丢。
2. 选型维度
- 数据模型：关系型（需 SQL / 事务）还是非关系型（键值 / 文档 / 图）；
- 一致性要求：是否需线性一致 / 强事务，或可接受最终一致；
- 扩展方式：读写比例、数据规模、是否需弹性扩缩；
- 运维能力：是否接受托管云服务，团队是否有分布式运维经验；
- 生态兼容：是否需兼容 MySQL / PostgreSQL 协议以复用存量应用。
3. 按场景推荐
| 场景 | 推荐类型 | 代表 |
|---|---|---|
| 金融级强事务 OLTP | NewSQL / 分布式关系库 | TiDB、PolarDB-X、CockroachDB |
| 高写入、可容忍最终一致 | 无主 NoSQL | Cassandra、DynamoDB |
| 文档 / 灵活模式 | 文档型 | MongoDB（分片集群） |
| 关联查询密集 | 图数据库 | Neo4j、Nebula Graph |
| 实时分析 | 列式 / HTAP | ClickHouse、TiDB（HTAP） |
| 低延迟缓存 | 内存数据库 | Redis |
| 存量 MySQL 平滑扩展 | 中间件 / 兼容型 | ShardingSphere、TiDB |
4. 一致性权衡与迁移成本
一致性权衡：
- 强一致（线性 / 串行化）依赖共识算法与同步复制，延迟与可用性代价高（详见《分布式协调》）；
- 最终一致吞吐与可用性高，但读可能过期（详见《一致性：CAP 与一致性模型》）。
迁移成本：
- 兼容 MySQL / PostgreSQL 协议的产品迁移成本最低；
- 分库分表存量系统可经数据库中间件平滑过渡；
- 全新系统优先评估原生 NewSQL，避免过度依赖中间件。
5. 小结
- 四个概念不在同一维度：云原生是部署形态、HTAP 是负载融合、图是数据模型、内存是存储介质；
- 选型先问数据模型与一致性，再看扩展方式、运维能力与生态兼容；
- 一致性越强代价越高，按业务后果决定，而非"显得严谨"；
- 存量系统靠兼容协议与中间件过渡，新系统优先原生分布式方案。
结语：分布式数据库知识体系回顾
本系列八篇构成完整的分布式数据库认知框架：
- 概述：定义、分类与核心特征；
- 数据分布：分片策略与复制模型；
- 一致性：CAP 与一致性谱系；
- 存储引擎：B+ 树 / LSM-Tree / 列式与三类放大；
- 事务与恢复：WAL、并发控制与原子提交协议；
- 分布式协调：侦测、选举、传播与共识；
- 系统实践：TiDB / PolarDB-X / Cassandra 与 NewSQL；
- 选型：概念辨析与场景决策。
掌握这条主线，即可读懂大多数主流分布式数据库的设计取舍。