一、选型的第一性问题先看数据模型再看其他选型时最容易犯的错是先看厂商、性能参数或流行度。正确的顺序是数据本身是什么形状结构化表格 / 键值 / 文档 / 图 / 时间序列 / 向量 / 列式聚合主要访问模式是什么点查、范围扫描、聚合分析、关系遍历、相似度检索一致性要求强一致 / 最终一致 / 事务边界规模与分布单机够用 / 需要水平扩展 / 全球分布运维与生态成本数据模型是第 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 相似度检索注意通常和关系型 / 文档型配合做“标量过滤 向量检索”列式 OLAPClickHouse / 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 聚合列式 OLAPClickHouse / Doris多种模型混合多模态ArangoDB / Cosmos DB五、选型的核心判断链可以浓缩成一句话先问数据是什么形状再问怎么查再问要不要事务最后问规模。具体顺序数据形状→ 决定大类关系 / 文档 / 图 / 时序 / 向量 / 列式访问模式→ 决定细分点查 / 范围 / 聚合 / 遍历 / ANN一致性 事务→ 决定是否必须 RDBMS 或 NewSQL规模 分布→ 决定单机 / 分布式 / 云原生生态 运维→ 决定具体产品最常见的错误用关系型硬扛图遍历或向量检索用 NoSQL 硬扛复杂事务用 OLTP 库做 OLAP 聚合用 OLAP 库做点查事务为了“技术先进”上分布式而单机完全够用