作者按本文面向架构师和技术负责人把主流数据库按类型梳理清楚并给出一张可直接落地的选型决策流程图。目标是让你在 30 分钟内对用什么数据库有一个系统性的判断框架。所有内容均基于 2026 年主流版本的实际能力。一、数据库分类全景图先建立全局视角。现代数据库可以按数据模型和访问模式分为以下几大类关系型数据库 (RDBMS)PostgreSQL、MySQL、Oracle、SQL Server、MariaDB文档/NoSQL 数据库MongoDB、Couchbase、DocumentDBKV 存储Redis、Memcached、etcd搜索引擎Elasticsearch、OpenSearch、Meilisearch列式/分析型数据库 (OLAP)ClickHouse、Apache Doris、Snowflake、BigQuery、Redshift宽列数据库Cassandra、ScyllaDB、HBase时序数据库InfluxDB、TimescaleDBPG 扩展、Prometheus图数据库Neo4j、NebulaGraph、JanusGraph多模数据库Azure Cosmos DB、Amazon DynamoDB、ArangoDB每一类解决不同的问题。下面逐一拆解。二、关系型数据库RDBMS核心特征强 schema、强类型ACID 事务SQL 查询语言表关联JOIN主要选手数据库定位适合场景不适合场景PostgreSQL​功能最全的开源 RDBMS复杂业务、多数据类型、企业级极端简单 KV 场景MySQL​最流行的开源 RDBMSWeb 应用、简单 CRUD复杂分析、GISOracle​商业 RDBMS 标杆金融核心、超大规模 OLTP预算有限、不想被绑定SQL Server​微软生态 RDBMS.NET 技术栈、企业 BI非 Windows 生态MariaDB​MySQL 兼容分支MySQL 替代、需要开源保障需要 PG 特性的场景架构师视角关系型数据库是大多数系统的核心存储。选哪个 RDBMS 取决于团队能力和业务复杂度。上一篇已经详细对比了 PG 和 MySQL这里不再展开。三、文档数据库Document Store核心特征半结构化数据JSON/BSON无固定 schema或弱 schema文档内嵌套结构水平扩展友好主要选手数据库定位适合场景不适合场景MongoDB​最流行的文档数据库内容管理、目录、快速迭代 schema复杂事务、多文档强一致Couchbase​内存优先的文档数据库高吞吐缓存持久化复杂查询DocumentDB​AWS 托管 MongoDB 兼容AWS 生态、托管需求需要最新 MongoDB 特性关键判断文档数据库的核心价值是开发速度和schema 灵活性。但代价是事务能力弱MongoDB 4.0 支持多文档事务但性能有损耗JOIN 能力弱需要反范式设计数据一致性模型较松什么时候选文档数据库数据结构频繁变化嵌套层次深不适合关系模型读写比例高查询模式简单团队需要快速迭代四、KV 存储核心特征最简单的模型key → value极高性能微秒级内存为主或内存持久化主要选手数据库定位适合场景不适合场景Redis​内存数据结构存储缓存、会话、排行榜、分布式锁持久化为主的数据Memcached​纯内存缓存简单缓存需要持久化、复杂数据结构etcd​分布式 KV 一致性配置管理、服务发现大数据量存储架构师视角KV 存储通常不是主存储而是作为缓存层或分布式协调组件。Redis 是事实标准几乎每个系统都会用到。五、搜索引擎核心特征倒排索引全文搜索、模糊匹配聚合分析近实时NRT主要选手数据库定位适合场景不适合场景Elasticsearch​分布式搜索引擎全文搜索、日志分析、监控事务、主数据存储OpenSearch​ES 分支AWS 主导同 ES避免 ES 许可证问题同 ESMeilisearch​轻量级搜索引擎中小规模搜索、低延迟大规模、复杂聚合关键判断搜索引擎解决的是找东西的问题不是存东西的问题。典型架构是主库PG/MySQL存数据ES 做搜索索引。但如果你用 PostgreSQL它的全文搜索 GIN 索引可以覆盖简单搜索场景不一定需要 ES。六、分析型数据库OLAP核心特征列式存储批量写入、大量扫描聚合查询极快不适合高频单行更新主要选手数据库定位适合场景不适合场景ClickHouse​开源 OLAP 标杆实时分析、日志、监控事务、高频更新Apache Doris​国产 OLAP实时数仓、报表事务Snowflake​云原生数仓企业数仓、BI实时写入BigQuery​云数仓大数据分析事务架构师视角OLAP 数据库通常作为分析层存在通过 CDC 或 ETL 从主库同步数据。不要试图用 OLTP 数据库跑复杂分析也不要用 OLAP 做事务处理。七、宽列数据库核心特征列族模型海量数据、高写入吞吐最终一致性线性扩展主要选手数据库定位适合场景不适合场景Cassandra​高可用宽列时序数据、消息存储、海量写入复杂查询、事务ScyllaDB​Cassandra 兼容C 重写同 Cassandra性能更高同 CassandraHBase​Hadoop 生态列存储大数据生态、稀疏数据低延迟需求关键判断宽列数据库适合写多读少、数据量极大的场景但查询能力有限不适合需要复杂过滤和聚合的业务。八、时序数据库核心特征时间线数据模型高写入吞吐时间窗口聚合自动数据过期TTL主要选手数据库定位适合场景不适合场景InfluxDB​时序标杆监控、IoT、指标存储事务TimescaleDB​PG 扩展时序能力需要 SQL 时序超大规模PBPrometheus​监控专用容器监控长期存储架构师视角如果已经在用 PostgreSQLTimescaleDB 扩展是最低成本的时序方案。如果数据量极大且不需要 SQLInfluxDB 更合适。九、图数据库核心特征节点 边模型深度关联查询遍历效率高不适合聚合分析主要选手数据库定位适合场景不适合场景Neo4j​图数据库标杆社交网络、推荐系统、欺诈检测大规模写入NebulaGraph​分布式图数据库超大规模图数据事务JanusGraph​可扩展图数据库与大数据生态集成性能要求极高关键判断图数据库解决的是关系深度查询问题。如果关系超过 3 层 JOIN关系型数据库性能会急剧下降此时应考虑图数据库。十、多模数据库核心特征支持多种数据模型统一查询接口简化架构主要选手数据库定位适合场景不适合场景Azure Cosmos DB​全球分布式多模全球化应用、多模型需求成本敏感Amazon DynamoDB​托管 KV 文档AWS 生态、Serverless复杂查询ArangoDB​开源多模需要灵活模型超大规模十一、选型决策流程图以下是给架构师用的核心决策流从业务需求逐层收敛到数据库类型开始选型 │ ├─ 是否需要强事务 / ACID │ │ │ ├─ 是 → 数据关系复杂吗多表 JOIN / 强 Schema │ │ │ │ │ ├─ 是 → RDBMSPostgreSQL / MySQL / Oracle │ │ └─ 否 → 文档数据库MongoDB / Couchbase │ │ │ └─ 否 → 数据量 / 访问模式 │ │ │ ├─ 简单 KV / 缓存 → KV 存储Redis / Memcached │ ├─ 全文搜索 / 模糊匹配 → 搜索引擎Elasticsearch │ ├─ 时序 / 监控 / 日志 → 时序数据库InfluxDB / TimescaleDB │ ├─ 图关系 / 社交网络 → 图数据库Neo4j / NebulaGraph │ ├─ 海量写入 / 高可用 → 宽列数据库Cassandra / ScyllaDB │ └─ 实时分析 / OLAP → 分析型数据库ClickHouse / Doris │ └─ RDBMS 内部细化 │ ├─ 复杂业务 / 多数据类型 → PostgreSQL ├─ 简单 CRUD / 团队熟悉 → MySQL / MariaDB └─ 企业级 / 预算充足 → Oracle / SQL Server十二、架构分层选型图一个典型的现代系统数据库通常不是一个而是分层协作应用层 │ ├─ Redis缓存 / 会话 ├─ PostgreSQL / MySQL主数据库 ├─ Elasticsearch搜索 ├─ ClickHouse分析 └─ InfluxDB监控十三、总结选型的核心原则不要为了技术先进性打断业务连续性如果已有 MySQL 且团队只熟悉 MySQL不要强行迁移一个数据库解决一类问题不要试图用一个数据库解决所有问题默认选 PostgreSQL新项目、无历史包袱时PG 的天花板更高简单场景用简单工具高并发 KV 用 Redis全文搜索用 ES不要过度设计架构师的最终建议数据库选型不是选最好的而是选最合适的。理解业务需求匹配数据模型评估团队能力才是正确决策的路径。