数据库选型：如何从众多数据库中选出最理想的那一个

一、选型的第一性问题：先看数据模型，再看其他

选型时最容易犯的错是先看厂商、性能参数或流行度。正确的顺序是：

数据本身是什么形状（结构化表格 / 键值 / 文档 / 图 / 时间序列 / 向量 / 列式聚合）
主要访问模式是什么（点查、范围扫描、聚合分析、关系遍历、相似度检索）
一致性要求（强一致 / 最终一致 / 事务边界）
规模与分布（单机够用 / 需要水平扩展 / 全球分布）
运维与生态成本

数据模型是第 1 步，因为它直接决定后面几步的天花板。

二、数据模型

复制代码

数据库
├── 关系型（RDBMS）
│   ├── 传统集中式：Oracle / MySQL / SQL Server / PostgreSQL / DB2 / MariaDB / SQLite
│   ├── NewSQL 分布式：TiDB / OceanBase / CockroachDB / YugabyteDB / Google Spanner / VoltDB / SingleStore
│   └── 云原生关系型：Amazon Aurora / PolarDB / TDSQL / GaussDB
│
├── 非关系型（NoSQL）
│   ├── 键值型：Redis / Memcached / etcd / Riak / Voldemort
│   ├── 文档型：MongoDB / CouchDB / Couchbase / RavenDB / LiteDB / UnQLite
│   ├── 列族型：HBase / Cassandra
│   ├── 图型：Neo4j / JanusGraph / TigerGraph / ArangoDB / Amazon Neptune / NebulaGraph
│   ├── 时序型：InfluxDB / TimescaleDB / OpenTSDB / Prometheus / 腾讯云 CTSDB
│   ├── 搜索引擎型：Elasticsearch / Apache Solr
│   └── 向量型：FAISS / Milvus / Pinecone / Weaviate / Qdrant / Chroma
│
├── 列式 OLAP（独立一类）
│   └── ClickHouse / Apache Doris / StarRocks / Greenplum / Vertica / Apache Druid
│
├── 多模态
│   └── ArangoDB / Couchbase / OrientDB / Azure Cosmos DB / SurrealDB
│
└── 早期模型（仅遗留系统维护）
    ├── 层次型：IBM IMS / IDMS
    ├── 网状型：Unisys DMSII / HP IMAGE / Oracle CODASYL DBMS
    └── 对象型：ObjectDB / Versant ODB / Objectivity/DB / ZODB / db4o

三、按数据模型选型的核心判断

关系型（RDBMS）

特征：数据格式固定、关系明确、要事务（订单、账户、财务）
代表：Oracle / MySQL / PostgreSQL / SQL Server
选它的信号：业务规则能用表 + 外键 + 事务清晰表达
代价：单机写入和跨区域扩展有天花板，于是分化出 NewSQL 和云原生关系型

键值型（Redis / Memcached）

特征：简单键值对、高频读写，用于缓存 / 会话 / 排行
关键约束：不要当主库用，内存级速度的代价是持久性和复杂查询能力有限
选它的信号：访问模式几乎全是按 key 点查，且能接受数据在内存中重建

文档型（MongoDB / CouchDB）

特征：字段随时变、嵌套结构、快速迭代
选它的信号：你发现自己频繁 ALTER TABLE 加字段
代价：复杂 JOIN 和强事务支持弱，跨文档一致性要靠应用层兜底

列族型（HBase / Cassandra）

特征：海量写入、时序数据、IoT
选它的信号：row key + column family 能覆盖 90% 查询，且能接受最终一致或弱事务
注意：ClickHouse 常被误归到列族型，但它更准确的定位是列式 OLAP，和 HBase 的列族模型不是一回事

图型（Neo4j / NebulaGraph）

特征：遍历关系网络（社交、反欺诈、知识图谱）
选它的信号：关系跳数多，SQL 递归 JOIN 已经写不动了
代价：全图扫描和聚合分析不如列存，超大规模要选分布式图库

时序型（InfluxDB / TimescaleDB / Prometheus）

特征：带时间戳的指标、传感器、监控数据
选它的信号：写多读少、按时间窗口聚合、需要降采样和保留策略
注意：TimescaleDB 适合"时序 + 关系"混合，Prometheus 更适合云原生监控生态

搜索引擎型（Elasticsearch / Solr）

特征：全文检索、倒排索引、模糊匹配、日志分析
选它的信号：核心需求是"搜得到"而不是"存得准"
注意：通常不作为主库，而是"主库 + ES 索引"的组合，接受最终一致

向量型（Milvus / Pinecone / FAISS）

特征：语义搜索、RAG、AI 应用，是 2026 年增长最快的类别
选它的信号：数据是 embedding，核心操作是 ANN 相似度检索
注意：通常和关系型 / 文档型配合，做"标量过滤 + 向量检索"

列式 OLAP（ClickHouse / Doris / StarRocks / Druid）

特征：大规模扫描、聚合、GROUP BY、BI 报表
选它的信号：分析型负载、宽表、只查少数列、批量写入
注意：不要用它做点查事务，也不要用 MySQL 硬扛大规模聚合

多模态（ArangoDB / Cosmos DB / SurrealDB）

特征：一个系统里同时需要文档、图、KV 等多种模型
选它的信号：快速原型、中小规模、不想维护多套数据库
代价：每项都不是最强，大规模生产仍倾向"专用库组合"

早期模型（层次型 / 网状型 / 对象型）

特征：遗留系统维护，特定行业老系统
注意：新项目基本不考虑，除非有明确的兼容或迁移约束

四、一张决策速查表

核心需求	首选模型	代表
强事务 + 复杂 JOIN	关系型	PostgreSQL / MySQL / TiDB
极低延迟 KV	键值型	Redis
半结构化文档	文档型	MongoDB
海量写入 + 宽表	列族型	HBase / Cassandra
多跳关系遍历	图型	Neo4j / NebulaGraph
时间戳 + 窗口聚合	时序型	InfluxDB / TimescaleDB
全文检索	搜索引擎型	Elasticsearch
向量相似度	向量型	Milvus / Qdrant
大规模 OLAP 聚合	列式 OLAP	ClickHouse / Doris
多种模型混合	多模态	ArangoDB / Cosmos DB

五、选型的核心判断链

可以浓缩成一句话：

先问数据是什么形状，再问怎么查，再问要不要事务，最后问规模。

具体顺序：

数据形状 → 决定大类（关系 / 文档 / 图 / 时序 / 向量 / 列式）
访问模式 → 决定细分（点查 / 范围 / 聚合 / 遍历 / ANN）
一致性 + 事务 → 决定是否必须 RDBMS 或 NewSQL
规模 + 分布 → 决定单机 / 分布式 / 云原生
生态 + 运维 → 决定具体产品

最常见的错误：

用关系型硬扛图遍历或向量检索
用 NoSQL 硬扛复杂事务
用 OLTP 库做 OLAP 聚合
用 OLAP 库做点查事务
为了"技术先进"上分布式，而单机完全够用