数据库选型是什么
数据库选型的起点是数据模型与访问模式，而不是产品热度：关系型适合强事务与多表关联查询，文档型适合以聚合为单位读写的半结构化数据，宽列适合海量顺序写入与按行键查询，图数据库适合多跳关系遍历。确定类型之后再叠加一致性等级、扩展方式、团队运维能力与成本约束，最后用贴近生产规模的数据做基准验证，而不是靠功能演示下结论。
基本信息
| 选型输入 | 数据模型、读写比例、一致性要求、数据规模与增长速度 |
|---|---|
| 硬约束 | 事务边界、查询模式、可用性目标、合规与数据驻留要求 |
| 配套能力 | 备份恢复、监控告警、扩容路径、团队既有经验 |
| 验证方式 | 用同量级数据做 PoC，量化 P99 延迟与写入吞吐 |
典型使用场景
- 交易与账务：多表关联、强事务，优先关系型并明确隔离级别
- 内容与目录：整篇聚合读写、结构多变，文档型更贴合存取路径
- 时序与日志：写入量大、按时间与行键扫描，宽列或专用时序库更合适
- 关系网络：好友推荐、风控关联、多跳遍历，图库比递归 SQL 更直接
- 全文与多条件检索：把检索交给搜索引擎，源数据仍留在主库
- 分析与报表：列式存储或独立只读仓库，避免压榨在线库
选型问题清单
选型问题清单
# 1 访问模式：主键查询、范围扫描、聚合、多跳，各占多少比例
# 2 事务范围：单行、单表还是跨表跨库，能否接受最终一致
# 3 规模假设：三年后的行数与日写入量，分片键是否已确定
# 4 一致性：读己之写是否必须，跨区域复制能否接受延迟
# 5 运维代价：备份窗口、版本升级、故障切换由谁负责
# 6 退出成本：导出格式是否通用，迁移脚本是否已演练过类型与取舍
| 类型 | 数据特征 | 典型场景 | 常见坑 |
|---|---|---|---|
| 关系型 | 强事务、多表关联 | 交易、账务、订单 | 单库扛不住写时改造代价高 |
| 文档型 | 半结构化聚合读写 | 内容、目录、配置 | 跨文档事务弱，一致性靠应用保证 |
| 宽列 | 海量写入、按行键查询 | 时序、日志、消息归档 | 查询模式受限，二级索引设计不当会拖慢 |
| 图 | 多跳关系遍历 | 风控关系网、推荐 | 超大规模下的分片与跨片遍历复杂 |
先明确一致性与查询模式再选类型：用产品热度做对比维度，很容易选出与业务访问路径不匹配的库，后期靠应用层补丁硬撑。
多存储并用是常态，但要限制种类：每引入一种数据库，就多一套备份、监控、升级与值守流程，团队规模撑不住时应先合并同类项。