分类、选型、核心原理、分布式架构、调优与趋势 (2025-2026)
| 类型 | 数据模型 | 核心优势 | 典型场景 | 代表产品 |
|---|---|---|---|---|
| 关系型 (RDBMS) | 表 + 行 + 列，强 Schema | ACID 事务、SQL 标准、数据一致性 | 交易系统、ERP、金融 | MySQL、PostgreSQL、Oracle |
| 文档型 | JSON/BSON 文档，灵活 Schema | Schema 灵活、开发快、水平扩展 | 内容管理、用户画像、配置 | MongoDB、CouchDB |
| 列族型 | 列族 + 行键，稀疏存储 | 海量数据、高写入吞吐 | 日志、IoT、消息存储 | HBase、Cassandra、ScyllaDB |
| 键值型 (KV) | Key → Value，极简模型 | 极低延迟、高吞吐 | 缓存、会话、计数器 | Redis、Memcached、DynamoDB |
| 列式分析 (OLAP) | 列存储，面向分析 | 聚合查询极快、高压缩比 | BI 报表、实时分析、数仓 | ClickHouse、Doris、StarRocks |
| 时序型 | 时间戳 + 标签 + 值 | 时间范围查询、降采样、高写入 | 监控、IoT、金融行情 | InfluxDB、TimescaleDB、TDengine |
| 图数据库 | 节点 + 边 + 属性 | 关系遍历极快、模式匹配 | 社交网络、知识图谱、反欺诈 | Neo4j、NebulaGraph、TigerGraph |
| 搜索引擎 | 倒排索引 + 文档 | 全文搜索、聚合分析 | 搜索、日志分析、推荐 | Elasticsearch、Meilisearch |
| 向量数据库 | 高维向量 + 元数据 | 相似度搜索 (ANN)、语义检索 | RAG、推荐、图像搜索 | Milvus、Qdrant、Pinecone |
| NewSQL | 关系型 + 分布式 | SQL + 水平扩展 + 强一致 | 大规模 OLTP、缓解分库分表复杂度 | TiDB、CockroachDB、OceanBase |
| 数据库 | 架构 | 查询性能 | 写入性能 | 适用场景 | 生态 |
|---|---|---|---|---|---|
| ClickHouse | 列存、MergeTree 引擎 | 极快 (亿级秒回) | 高 (批量写入) | 日志分析、实时报表、用户行为 | 俄罗斯 Yandex 出品，社区活跃 |
| Apache Doris | MPP、列存、向量化 | 极快 | 高 (实时导入) | 实时数仓、多维分析 | 百度开源，国内生态强 |
| StarRocks | MPP、列存 (Doris fork) | 极快 | 高 | 实时分析、湖仓一体 | Doris 商业化分支，性能优化 |
| DuckDB | 嵌入式列存 OLAP | 快 (单机) | 中等 | 本地分析、数据科学、ETL | "SQLite for Analytics"，零依赖 |
| Apache Druid | 列存 + 预聚合 | 亚秒级 | 高 (流式) | 实时仪表盘、时序分析 | 适合高并发查询场景 |
| BigQuery / Snowflake | 云原生、存算分离 | 快 (弹性) | 批量 | 云数仓、BI、数据湖 | 全托管，按查询量计费 |
| 数据库 | 架构 | 兼容性 | 一致性 | 适用场景 | 背景 |
|---|---|---|---|---|---|
| TiDB | 计算存储分离 (TiKV) | MySQL 协议兼容 | 强一致 (Raft) | 替代 MySQL 分库分表、HTAP | PingCAP，国内最活跃 |
| OceanBase | Shared-Nothing、Paxos | MySQL/Oracle 兼容 | 强一致 | 金融核心、去 O 替代 | 蚂蚁集团，TPC-C 世界纪录 |
| CockroachDB | 分布式 KV + SQL | PostgreSQL 兼容 | 强一致 (Raft) | 全球部署、多活 | 前 Google Spanner 团队 |
| YugabyteDB | DocDB 存储引擎 | PostgreSQL 兼容 | 强一致 | 云原生分布式 SQL | 开源，兼容 PG 生态 |
| PolarDB | 共享存储、计算节点扩展 | MySQL/PG 兼容 | 强一致 | 阿里云 RDS 升级版 | 阿里云自研 |
| 数据库 | 架构 | 索引算法 | 特色 | 适用场景 | 部署 |
|---|---|---|---|---|---|
| Milvus | 分布式、存算分离 | HNSW / IVF / DiskANN | 十亿级向量、混合搜索 | 大规模 RAG、推荐 | 自部署 / Zilliz Cloud |
| Qdrant | Rust 实现、单机/分布式 | HNSW | 过滤性能强、Payload 丰富 | RAG、语义搜索 | 自部署 / Cloud |
| Pinecone | 全托管 SaaS | 专有 | 零运维、Serverless | 快速上手、中小规模 | 纯 SaaS |
| Weaviate | Go 实现、模块化 | HNSW | 内置向量化、GraphQL API | 语义搜索、多模态 | 自部署 / Cloud |
| Chroma | 嵌入式 (Python) | HNSW | 极简 API、开发友好 | 原型、小规模 RAG | 嵌入式 / Server |
| pgvector | PostgreSQL 扩展 | IVFFlat / HNSW | 无需新数据库、SQL 查询 | 已有 PG 的团队 | PG 扩展 |
| 数据库 | 语言 | 写入性能 | 压缩率 | 特色 | 适用 |
|---|---|---|---|---|---|
| InfluxDB | Go/Rust | 高 | 高 | Flux 查询语言、生态成熟 | 监控、IoT |
| TimescaleDB | C (PG 扩展) | 高 | 高 | 完整 SQL、PG 生态兼容 | 已有 PG 的时序场景 |
| TDengine | C | 极高 | 极高 | 超级表、国产、IoT 优化 | 工业 IoT、车联网 |
| VictoriaMetrics | Go | 极高 | 极高 | Prometheus 兼容、长期存储 | 监控指标存储 |
| QuestDB | Java | 极高 | 高 | SQL 原生、列存、SIMD | 金融行情、实时分析 |
结构: 多路平衡搜索树，叶子节点有序链表连接
优势: 范围查询高效、随机读写均衡、磁盘友好
适合: OLTP 场景，读写混合负载
结构: 内存 MemTable → 磁盘 SSTable，分层合并 (Compaction)
优势: 写入极快 (顺序写)、空间放大可控
劣势: 读放大 (需查多层)、写放大 (Compaction)
适合: 写多读少、日志型、KV 存储
结构: 同一列数据连续存储，而非同一行
优势: 聚合查询只读需要的列、压缩率极高 (同类型数据)
适合: OLAP 分析、数仓、宽表查询
Atomicity (原子性): 事务要么全部成功，要么全部回滚
Consistency (一致性): 事务前后数据满足所有约束
Isolation (隔离性): 并发事务互不干扰
Durability (持久性): 提交后数据不丢失 (WAL)
Read Uncommitted: 脏读 — 几乎不用
Read Committed: 不可重复读 — PostgreSQL 默认、Oracle 默认
Repeatable Read: 幻读 (InnoDB 通过 Gap Lock 解决) — MySQL 默认
Serializable: 完全串行化 — 性能最差，极少使用
每行数据保留多个版本，读操作看到一致性快照，不阻塞写操作。
MySQL: Undo Log 存储旧版本，ReadView 判断可见性
PostgreSQL: 堆表中直接存多版本，VACUUM 清理旧版本
B+ Tree 索引: 最通用，支持等值/范围/排序/前缀匹配
Hash 索引: 只支持等值查询，O(1) 查找
GIN (倒排索引): 全文搜索、数组包含、JSON 查询 (PostgreSQL)
GiST (通用搜索树): 地理数据、范围类型 (PostgreSQL)
BRIN (块范围索引): 有序数据的极小索引，时序数据友好
1. 最左前缀: 联合索引 (a, b, c) 可用于 a / a,b / a,b,c 查询
2. 覆盖索引: 索引包含查询所需所有列，避免回表
3. 选择性: 高选择性列 (唯一值多) 适合建索引
4. 避免过多索引: 每个索引都有写入开销和存储成本
分布式系统最多同时满足三者中的两个:
C (Consistency): 所有节点看到相同数据
A (Availability): 每个请求都能得到响应
P (Partition Tolerance): 网络分区时系统仍能运行
现实: P 不可避免，所以实际选择是 CP (强一致) 或 AP (高可用)
CP 系统: TiDB、CockroachDB、ZooKeeper — 宁可不可用也要一致
AP 系统: Cassandra、DynamoDB、Redis Cluster — 宁可不一致也要可用
Basically Available: 基本可用 (允许降级)
Soft State: 软状态 (允许中间状态)
Eventually Consistent: 最终一致性 (不要求实时一致)
| 算法 | 原理 | 使用者 | 特点 |
|---|---|---|---|
| Raft | Leader 选举 + 日志复制 | TiDB、CockroachDB、etcd | 易理解、工程实现多、强一致 |
| Paxos | 提案-承诺-接受三阶段 | OceanBase、Google Spanner | 理论完备但实现复杂 |
| Gossip | 节点间随机传播信息 | Cassandra、Redis Cluster | 最终一致、去中心化、容错强 |
| ZAB | 类 Paxos，原子广播 | ZooKeeper | 保证全序、Leader 驱动 |
| 场景 | 首选 | 备选 | 关键考量 |
|---|---|---|---|
| Web 应用 (中小规模) | PostgreSQL | MySQL | 功能丰富 vs 生态成熟 |
| 高并发交易 (金融) | OceanBase / TiDB | Oracle / PG + Citus | 强一致 + 水平扩展 |
| 缓存层 | Redis | Memcached / Dragonfly | 数据结构丰富 vs 纯缓存 |
| 全文搜索 | Elasticsearch | Meilisearch / Typesense | 功能全 vs 轻量易用 |
| 实时分析 (OLAP) | ClickHouse | Doris / StarRocks | 单表极快 vs 多表 Join |
| 日志存储 | Elasticsearch + ClickHouse | Loki (Grafana) | 搜索能力 vs 成本 |
| IoT 时序数据 | TDengine / TimescaleDB | InfluxDB / QuestDB | 国产生态 vs 国际生态 |
| 社交关系/知识图谱 | Neo4j / NebulaGraph | TigerGraph / JanusGraph | 易用性 vs 性能 |
| AI 向量检索 (RAG) | Milvus / Qdrant | pgvector / Pinecone | 规模 vs 简单性 |
| 内容管理 (CMS) | MongoDB | PostgreSQL (JSONB) | 灵活 Schema vs SQL 能力 |
| 消息/事件存储 | Kafka (日志型) | Cassandra / ScyllaDB | 流处理 vs 随机查询 |
| 缓解分库分表复杂度 | TiDB | CockroachDB / Vitess | MySQL 兼容 vs PG 兼容 |
结构化 + 关系 → 关系型 | 半结构化 → 文档型 | 键值对 → KV | 图关系 → 图数据库
OLTP (事务) → MySQL/PG/TiDB | OLAP (分析) → ClickHouse/Doris | 混合 (HTAP) → TiDB
单机够用 (< 1TB) → 单实例 PG/MySQL | 需要扩展 → 分布式 (TiDB/CockroachDB)
强一致 (金融) → CP 系统 | 最终一致 (社交/日志) → AP 系统
运维能力强 → 自建 | 运维能力弱 → 云托管 (RDS/Cloud SQL)
innodb_buffer_pool_size: 物理内存的 70-80%innodb_log_file_size: 1-2GB (减少 checkpoint)innodb_flush_log_at_trx_commit: 1=安全 2=性能max_connections: 根据实际并发设置，配合连接池sort_buffer_size: 适当增大减少磁盘排序1. 开启慢查询日志: slow_query_log = ON，设置阈值 (如 1s)
2. 定位慢 SQL: mysqldumpslow 或 pt-query-digest 分析
3. EXPLAIN 分析: 查看执行计划，关注全表扫描 (type=ALL)
4. 索引优化: 添加/调整索引，验证执行计划变化
5. SQL 改写: 拆分复杂查询、避免子查询、用 JOIN 替代 IN
6. 验证效果: 对比优化前后的执行时间和扫描行数
type: ALL (全表) < index < range < ref < eq_ref < const < system
rows: 预估扫描行数，越少越好
Extra: Using index (覆盖索引好) | Using filesort (需优化) | Using temporary (需优化)
| 模式 | 架构 | RTO | RPO | 适用场景 | 代表方案 |
|---|---|---|---|---|---|
| 主从复制 | 1 主 N 从，异步复制 | 分钟级 | 秒级丢失 | 读多写少、容忍少量丢失 | MySQL Replication |
| 半同步复制 | 至少 1 从确认后提交 | 分钟级 | 接近 0 | 需要较强一致性 | MySQL Semi-Sync |
| 组复制/Paxos | 多节点共识，自动选主 | 秒级 | 0 | 金融级高可用 | MySQL Group Replication / PG Patroni |
| 共享存储 | 多计算节点共享一份数据 | 秒级 | 0 | 云数据库 | Aurora / PolarDB |
| 多活 | 多地域同时读写 | 0 (无切换) | 取决于冲突解决 | 全球化业务 | CockroachDB / OceanBase |
3: 至少 3 份数据副本
2: 存储在 2 种不同介质上
1: 至少 1 份异地备份
全量备份: 完整数据快照，恢复最快，存储最大。频率: 每天/每周
增量备份: 只备份上次以来的变化，存储小，恢复需要全量+所有增量
Binlog/WAL 备份: 连续归档事务日志，支持任意时间点恢复 (PITR)
MySQL: mysqldump (逻辑) / XtraBackup (物理) / mysqlbinlog (PITR)
PostgreSQL: pg_dump / pg_basebackup / WAL 归档 + pg_pitr
验证: 定期恢复演练，备份不验证等于没备份
PostgreSQL 影响力继续扩大: 正在成为越来越多团队的优先评估选项。pgvector (向量) + PostGIS (地理) + TimescaleDB (时序) + Citus (分布式) 让 PG 覆盖面持续扩大。
HTAP 融合: OLTP + OLAP 在同一系统中完成。TiDB、OceanBase、AlloyDB 都在走这条路。减少数据搬运。
Serverless 数据库: 按使用量计费、自动扩缩容。Neon (PG)、PlanetScale (MySQL)、Turso (SQLite) 代表方向。
向量能力内置: 很多中小规模场景不再必须单独引入向量数据库。PG (pgvector)、MongoDB (Atlas Vector)、Elasticsearch 都在补强内置向量搜索。
AI + 数据库: AI 辅助调优 (索引推荐、查询改写)、自然语言查询 (Text-to-SQL)、智能运维 (异常检测)。
湖仓一体 (Lakehouse): 数据湖 + 数仓融合。Iceberg/Delta Lake + Spark/Flink + OLAP 引擎。
边缘数据库: SQLite (libSQL/Turso)、DuckDB 在边缘/嵌入式场景复兴。
国产数据库持续扩张: 信创和本地化需求推动 OceanBase、TiDB、openGauss、达梦等在更多场景进入评估与落地。
过度分布式: 很多团队不需要分布式数据库。单机 PG + 好的索引设计能撑到很大规模。分布式带来的复杂度远超想象。
NoSQL 万能论: MongoDB 不是银弹。需要事务一致性、复杂 JOIN 的场景，关系型仍然是最优解。
独立向量数据库重新分层: 越来越多通用场景会先评估 PG/ES/MongoDB 的内置能力是否已经够用；只有在规模、隔离和检索复杂度更高时，才更值得引入专门方案。