NoSQL 选型指南：文档、键值、宽列、图数据库与搜索引擎如何取舍

NoSQL 不是一种数据库，而是一组针对不同问题的数据库范式。文档数据库、键值数据库、宽列数据库、图数据库、搜索引擎解决的问题不同。选型错误会让后续开发、查询、扩容和运维都付出代价。

正确选型的第一步不是列技术清单，而是描述业务问题：数据是什么形态，读写模式如何，是否需要复杂查询，是否需要强一致，规模会增长到哪里，团队是否能运维。

文档数据库

代表系统包括 MongoDB、Couchbase 等。适合半结构化数据、聚合文档、快速迭代的业务模型。

适合场景：

• 内容管理。
• 用户配置。
• 订单快照。
• 商品属性。
• 灵活 schema 的业务对象。

优势是模型贴近应用对象，查询能力较强。风险是文档边界设计不当、索引膨胀和复杂事务需求。

键值数据库

代表系统包括 Redis、Memcached、DynamoDB 的部分使用模式等。适合通过 key 快速访问 value。

适合场景：

• 缓存。
• 会话。
• 限流计数。
• 排行榜。
• 临时状态。

优势是极低延迟和高吞吐。风险是查询能力弱，需要提前设计 key；如果把它当主数据库，要认真考虑持久化和一致性。

宽列数据库

代表系统包括 Cassandra、HBase、ScyllaDB。适合大规模写入、时间序列和固定查询模式。

适合场景：

• IoT 指标。
• 行为事件。
• 日志元数据。
• 大规模消息状态。
• 多地域高可用写入。

优势是水平扩展和写入吞吐。风险是查询模式受限、数据建模要求高、运维复杂。

图数据库

代表系统包括 Neo4j、JanusGraph、Amazon Neptune。适合关系网络和路径查询。

适合场景：

• 社交关系。
• 风控关系网络。
• 知识图谱。
• 推荐关系。
• 权限继承。

优势是多跳关系查询自然。风险是数据规模、写入吞吐、分布式图查询复杂度和团队经验。

搜索引擎

代表系统包括 Elasticsearch、OpenSearch、Solr。适合全文搜索、日志检索和聚合分析。

适合场景：

• 站内搜索。
• 日志分析。
• 订单检索。
• 商品搜索。
• 运营查询。

优势是搜索和聚合能力强。风险是它不是事务主库，mapping、分片、heap 和查询治理要求高。

选型维度

建议从以下维度打分：

• 数据模型是否匹配。
• 核心查询是否高效。
• 写入吞吐是否足够。
• 一致性能力是否满足业务。
• 扩容方式是否清晰。
• 备份恢复是否成熟。
• 运维复杂度是否可接受。
• 团队经验是否匹配。
• 云厂商托管能力是否可用。
• 成本是否可控。

不要只看 benchmark。公开 benchmark 很难代表你的数据分布、查询模式和运维环境。

多数据库组合

成熟系统往往不是只选一种数据库。常见组合：

• MySQL/PostgreSQL 做交易主库。
• Redis 做缓存和限流。
• MongoDB 存灵活文档。
• Elasticsearch 做搜索读模型。
• Cassandra 存大规模事件。

关键是明确主数据源。一个字段到底以哪个系统为准，其他系统如何同步，失败如何补偿。没有主数据源，多数据库会变成一致性灾难。

托管还是自建

如果团队数据库运维能力有限，优先考虑云托管服务。托管服务能减少备份、高可用、监控、补丁和扩容负担。但托管也会带来成本、限制和供应商绑定。

自建适合需要深度控制、特殊配置、成本优化或私有化部署的场景。自建前要确认团队具备 24 小时故障处理能力。

总结

NoSQL 选型不是技术偏好题，而是业务约束题。文档、键值、宽列、图和搜索各有边界。好的选择能让模型自然、查询高效、扩展清晰；坏的选择会把复杂度转嫁给应用层和运维团队。选型时先写清访问模式和一致性需求，再讨论产品名称，这样才不会被流行技术带偏。