数据库选型路线图

使用方式

数据库选型先看访问模式，再看一致性、规模、运维成本和团队熟悉度。不要因为“新技术流行”就选型，也不要用一种数据库解决所有问题。下面按数据类型和访问模式给出决策路径。

先回答五个问题：读写比例、单条/范围/聚合查询、事务一致性要求、数据规模增长、团队是否能运维。

检查清单

1. 关系型 OLTP

适合强事务、复杂关联、中等规模数据。

• PostgreSQL：复杂查询、JSONB、扩展生态、地理/向量能力。
• MySQL：互联网 OLTP、主从复制、运维生态成熟。
• 云托管 RDS：希望减少运维、接受云绑定。
• 是否需要读写分离、分库分表或分布式事务。

2. OLAP / 分析

适合大范围扫描、聚合、报表和实时分析。

• ClickHouse：高吞吐列式分析、日志/指标场景。
• Doris/StarRocks：实时数仓、MySQL 协议兼容。
• Trino/Presto：联邦查询、多数据源。
• Apache Druid/Pinot：时序和实时聚合。
• 是否需要湖仓（Iceberg/Hudi/Delta Lake）。

3. 缓存与 KV

• Redis/Valkey：丰富数据结构、缓存、会话、锁。
• KeyDB/Dragonfly：多主或高吞吐缓存。
• Memcached：简单纯缓存。
• etcd：强一致小规模元数据，不要当业务数据库。

4. 文档与搜索

• MongoDB：灵活 schema、文档模型、副本集。
• Elasticsearch/OpenSearch：全文搜索、日志检索。
• Meilisearch/Typesense：站内搜索、即时搜索。
• 是否需要向量检索和混合检索。

5. 向量与 AI

• pgvector：已有 PostgreSQL、数据量中等。
• Qdrant/Milvus/Weaviate：大规模向量、元数据过滤、分布式。
• Chroma：本地原型和轻量 RAG。
• 是否需要混合检索、量化和多租户。

6. 消息与流

• Kafka：高吞吐事件流、日志、CDC。
• Pulsar：多租户、分层存储。
• RabbitMQ：传统消息队列、复杂路由。
• NATS：轻量、低延迟、云原生。
• MQTT（EMQX/Mosquitto）：IoT 设备接入。

7. 运维与成本

• 备份、恢复、监控、升级路径是否清晰。
• 高可用和容灾能否满足 RTO/RPO。
• 许可、托管费用和人力成本。
• 团队是否有人能处理故障和调优。
• 是否有退出方案，避免供应商锁定。

常见误区

• 用 OLTP 数据库跑大范围分析，拖垮在线业务。
• 用搜索数据库当主库，事务和一致性无法保证。
• 只看 benchmark，不看自己的数据分布和查询模式。
• 忽略运维成本，选了一个团队不会排障的数据库。
• 过早分库分表，增加复杂度却没有解决瓶颈。
• 没有备份恢复演练，选型报告里只有性能没有可靠性。

相关条目

• psql、mysql、mongodb-replica-set、redis-cli
• build-clickhouse、doris、starrocks、trino
• elasticsearch、opensearch、meilisearch
• qdrant、milvus、pgvector
• kafka-broker、pulsar、nats、rabbitmq、emqx
• psql-vs-mysql、kafka-vs-pulsar、redis-vs-memcached