场景选型篇：不同业务场景应该用什么数据库
数据库选型不要从产品名开始，而要从数据规模、读写模式、一致性要求、查询形态和团队能力开始。
场景选型篇：不同业务场景应该用什么数据库
数据库选型最怕一上来就问“哪个数据库最好”。数据库没有抽象意义上的最好，只有在某个业务约束下是否合适。
一个订单系统和一个日志分析系统，面对的是完全不同的问题。前者关心事务和正确性，后者关心吞吐和扫描效率。用同一个数据库硬扛所有问题，早期看起来省事，后期往往会变成性能和运维的债。
先看业务问题，再看数据库产品
选型时可以先问几个问题：
- 数据是结构化、半结构化，还是非结构化。
- 读多还是写多。
- 是单行点查多，还是大范围扫描多。
- 是否需要强事务。
- 是否需要复杂 Join。
- 能接受多少数据延迟。
- 数据量现在多大，未来一年可能多大。
- 团队熟悉什么，能维护什么。
这些问题比产品宣传更重要。
业务交易系统
用户系统、订单系统、支付系统、库存系统、账户系统，优先考虑 OLTP 数据库。
常见选择是 MySQL、PostgreSQL、SQL Server、Oracle。如果业务已经有明显的水平扩展诉求，可以考虑 TiDB、OceanBase、CockroachDB 这类分布式 SQL。
这类系统不要优先追求分析能力，而要先保证事务、约束、索引、备份、恢复、审计和高可用。
报表和 BI 分析
日报、月报、经营分析、漏斗分析、用户留存、商品销售排行，通常应该进入 OLAP 数据库或数据仓库。
常见选择包括 ClickHouse、Apache Doris、StarRocks、BigQuery、Snowflake、Redshift。
如果报表只是少量简单统计，业务初期可以先在 MySQL 或 PostgreSQL 上做。但一旦开始扫历史大表、聚合多维指标、影响主库性能，就应该拆出报表库。
日志分析
日志分析分两类：偏检索和偏聚合。
如果核心需求是全文检索、错误排查、按关键字搜索日志，Elasticsearch 或 OpenSearch 更合适。
如果核心需求是按时间、服务、接口、状态码做聚合分析，ClickHouse、Doris、StarRocks 这类 OLAP 数据库也很适合。
很多成熟系统会同时使用搜索引擎和 OLAP：搜索引擎负责定位问题，OLAP 负责统计趋势和指标。
实时大屏和实时指标
实时大屏通常需要秒级或分钟级延迟，常见架构是 Kafka + Flink + OLAP 数据库。
Kafka 负责缓冲和解耦，Flink 负责清洗、窗口聚合和状态计算，OLAP 数据库负责承接明细或聚合结果并支撑查询。
可选数据库包括 Doris、StarRocks、ClickHouse、Druid、Pinot。具体选择取决于写入方式、查询并发、维度数量、是否需要更新和团队经验。
缓存和热点数据
热点读取、Session、验证码、排行榜、限流计数、分布式锁，通常会使用 Redis。
Redis 的优势是快，数据结构丰富，生态成熟。但它不应该替代核心数据库。缓存丢失、过期、穿透、击穿、雪崩，都需要有策略。
核心状态必须有可靠持久化来源。缓存可以提升性能，但不能成为唯一事实来源，除非业务已经明确接受这种风险。
时序数据
监控指标、IoT 设备数据、金融行情、传感器数据，都有明显的时间序列特征。
可选方案包括 InfluxDB、TimescaleDB、VictoriaMetrics，也可以使用 ClickHouse 或 Doris 承接部分时序分析场景。
时序系统的重点是高频写入、按时间范围查询、降采样、数据保留策略和压缩。
AI 和向量检索
RAG、语义搜索、相似图片、推荐召回，通常需要向量检索。
如果系统规模不大，PostgreSQL + pgvector 是非常务实的选择，因为它减少了额外组件。
如果向量规模大、召回延迟要求高、需要更专业的索引和分布式能力，可以考虑 Milvus、Qdrant、Weaviate 等向量数据库。
常见组合架构
MySQL + Redis 是最常见的业务系统组合。MySQL 保证正确性，Redis 提升热点访问性能。
MySQL + Elasticsearch 适合业务数据检索。MySQL 存事实，Elasticsearch 建搜索索引。
MySQL + ClickHouse 适合业务系统加分析系统。MySQL 承接交易，ClickHouse 承接报表。
Kafka + Flink + Doris 或 StarRocks 适合实时数仓。它能把业务事件变成实时指标。
PostgreSQL + pgvector 适合中小规模 AI 应用。关系数据和向量检索可以先放在一个系统里。
选型避坑
不要为了未来十倍规模过度设计。如果现在只有几十万数据量，团队也没有分布式数据库运维能力，直接上复杂架构可能弊大于利。
不要只看 benchmark。benchmark 里的数据分布、查询类型、机器配置和真实业务可能完全不同。
不要忽视团队熟悉度。一个理论上更强但没人会维护的系统，生产风险很高。
不要让一个数据库解决所有问题。业务库、缓存、搜索、分析库、对象存储，本来就应该各自承担不同职责。
小结
数据库选型可以记住一张简单判断表：
- 强事务、核心业务：MySQL / PostgreSQL。
- 大规模分析：ClickHouse / Doris / StarRocks。
- 全文检索：Elasticsearch / OpenSearch。
- 热点缓存：Redis。
- 时序指标：InfluxDB / TimescaleDB / VictoriaMetrics。
- 向量检索：pgvector / Milvus / Qdrant / Weaviate。
真正好的架构不是数据库越多越好，而是每个数据库都只承担它擅长的问题。
选型速查表
| 场景 | 优先考虑 | 不建议 |
|---|---|---|
| 用户、订单、支付 | MySQL / PostgreSQL | 直接用 OLAP 承接交易 |
| 经营报表、BI | ClickHouse / Doris / StarRocks | 长期压业务主库 |
| 日志全文检索 | Elasticsearch / OpenSearch | 只用关系库 LIKE |
| 日志聚合分析 | ClickHouse / Doris / StarRocks | 只依赖搜索引擎聚合 |
| 热点缓存 | Redis | 把缓存当唯一事实来源 |
| 监控时序 | VictoriaMetrics / InfluxDB / TimescaleDB | 普通业务表无限堆指标 |
| RAG / 语义搜索 | pgvector / Milvus / Qdrant | 手写全表向量距离计算 |