后端要存数据、搭基建,选型怎么定?这篇分两个角度讲:传统业务(什么数据用什么存),和 AI 大模型基建(LLM 应用多出来的那一层)。各自怎么选、怎么搭、有哪些开源方案。

---

第一部分 · 传统业务:什么数据用什么存

一、选型前,先想清楚几个问题

存储选型没有标准答案,但有标准的"问自己"。下面几个问题想明白,答案基本就浮出来了:

• 数据长什么样? 结构固定(→ 关系型)、还是字段多变(→ 文档型)?是文件(→ 对象存储)、还是关系网络(→ 图数据库)?
• 拿来干嘛? 在线业务的增删改查(OLTP),还是海量数据的离线分析(OLAP)?要不要全文搜索、要不要语义检索?
• 要不要事务 / 强一致? 涉及钱、订单、库存 → 必须关系型;能容忍"稍后一致"→ 选择多得多。
• 数据量多大、长多快? 百万级关系型轻松扛;到亿级、TB 级,才需要分库分表、数仓这些重武器。
• 读多还是写多? 读多 → 加缓存、读写分离;写多且要分析 → 往大数据那套走。

二、什么数据用什么存

选型最常见的误区,是问"MySQL 和 MongoDB 哪个好"——这没有答案。对的问法是:我这份数据是什么形态、拿来干嘛,该放哪种存储。

数据 / 场景	用什么存	为什么
业务核心数据(订单、用户、账目)	关系型:MySQL / PostgreSQL	要事务、强一致、表关系清晰
结构灵活 / 嵌套文档	文档型:MongoDB	字段不固定,不想频繁改表结构
缓存、计数、排行榜、会话	Redis(内存)	微秒级快、扛高并发
图片 / 视频 / 大文件	对象存储:阿里云 OSS、AWS S3	文件不该塞进数据库,对象存储便宜、自带 CDN
海量埋点 / 行为日志(用来分析)	数仓 / OLAP:Hive、ClickHouse	数据量极大,主要做离线 / 统计分析
监控指标(按时间记录)	时序库:Prometheus、InfluxDB	按时间序列高效读写,配 Grafana 看板
全文搜索	Elasticsearch	模糊搜索、分词,关系库做不了
关系网络(社交、推荐、风控)	图数据库:Neo4j	多跳关联(朋友的朋友)查得快,关系型 join 不动
AI 语义检索(RAG / 以图搜图)	向量数据库:Milvus、pgvector	按 embedding 的"语义相似"检索

为什么是它?—— 每种存储的"看家本领"

光记"什么用什么"还不够,得知道凭什么。一句话点破每个的核心:

• 关系型(MySQL / PG):看家本领是事务 + 强一致。转账要么都成、要么都不成,余额绝不能算错——这种"出错不起"的数据,只有它的 ACID 扛得住。
• MongoDB:本领是无固定表结构。商品详情、配置这种字段老变、嵌套深的,一个 JSON 文档存下、改字段不用改表;关系型得频繁改表或多表 join。
• Redis:快是因为数据全在内存里——内存读写微秒级,比磁盘快上千倍。所以热点、计数、排行榜放它,扛得住高并发。
• 对象存储(OSS / S3):专为大文件而生,便宜、能直接 URL 访问、配 CDN。图片视频塞进数据库会撑爆库、拖慢查询。
• 数仓 / ClickHouse:本领是列式存储。分析是"扫一亿行算个总和",列式只读用到的那几列、压缩狠、扫得飞快;MySQL 行式得整行整行读,跪。
• 时序库(Prometheus):为时间序列优化——指标是"每秒一个点、按时间查趋势",它写入快、时间范围查快,还能自动丢弃旧数据。
• ES:全文搜索靠倒排索引(词 → 哪些文档)+ 分词,秒级搜、还能按相关性排;LIKE '%关键词%' 是全表扫,慢且不能分词。
• 图数据库(Neo4j):把关系当一等公民(直接存边)。查"朋友的朋友的朋友"它沿着边走;关系型每多一跳就多一次 join,越深越慢。
• 向量库(Milvus):有专门的向量相似度索引。语义检索要在亿级向量里找"意思最接近的 top-k",普通库算不动,它用 ANN 索引秒级搞定。

几个最常纠结的点:

• MySQL 还是 PostgreSQL? 都行。MySQL 生态最成熟、用得最广、招人好招;PostgreSQL 功能更强(强大的 JSON、地理信息、复杂查询、窗口函数),近年越来越火。普通业务 MySQL 够用,要那些高级特性就上 PG。
• 别滥用 MongoDB。 很多人冲着"不用设计表结构"就上 MongoDB,但业务核心数据(要事务、要多表关联)还是关系型更稳。MongoDB 真正的主场是:日志、商品详情、配置这类结构多变、关联少、读多的数据。拿它存订单、做转账,迟早踩坑。

三、真实系统都是"组合拳"

别想用一种存储解决所有问题——真实系统是多种存储各司其职。拿一个内容平台举例:

• 用户、文章、评论 → MySQL(核心数据,要一致)
• 热门榜、阅读数、登录态 → Redis(缓存,扛高频读)
• 文章配图、视频 → OSS(对象存储)
• 站内搜索 → Elasticsearch
• 用户阅读行为(埋点)→ 采集进数仓做分析
• 服务监控 → Prometheus + Grafana

这种"一种数据配一种存储"的做法,业界叫 polyglot persistence(混合持久化)。所以选型从来不是"二选一",而是"每块数据各自选对"。

四、自建,还是用云托管?

每种存储都有两条路:自己装一台(自建),或用云厂商的托管版(开箱即用、免运维)。

存储	自建	阿里云托管(其他云类似)
MySQL / PG	自己装、自己运维	RDS
Redis	自建	云数据库 Redis(Tair)
数仓	自建 Hive 集群	MaxCompute / Hologres
对象存储	自建 MinIO	OSS
搜索	自建 ES	阿里云 Elasticsearch
时序 / 监控	自建 Prometheus	托管 Prometheus + Grafana

自建省钱,但备份、扩容、故障都得自己扛;托管贵一点,换来省心。团队小、没专职运维,就尽量用托管。

五、按团队规模怎么选

规律是:规模越小,越要少而精、能托管就托管;规模越大,越分化、越自建。

• 小团队 / 个人:一个关系型 + 一个 Redis + 对象存储,就够;全用云托管;别碰数仓 / Kafka(数据量没到,纯添乱)。
• 中型公司:业务库(可能读写分离)+ Redis 集群 + 对象存储;有分析需求再上数仓 + 埋点链路 + ES + 监控;仍以云托管为主。
• 大公司:深度自建 + 分布式(分库分表、TiDB)+ 数据中台,有专门 DBA / 数据团队;通常"云 + 自建"混合。

六、架构是"长"出来的

存储架构跟着数据量走:一个 MySQL 起步 → 读慢了加 Redis + 读写分离 → 单库扛不住分库分表 → 要分析接数仓。每步都是被真实瓶颈逼出来的,不是一开始就堆上去的。

最容易踩的坑:小团队过早上大公司架构。 看了大厂分享就上 Kafka + ClickHouse + 数据中台,结果数据量没到、人手不够,架构反成负担。让需求拉着架构走。

七、选好了,怎么部署?

分本地和生产两套打法,别搞混:

本地开发 / 测试:图快,用 Docker 起一个就行——

docker run -d --name mysql -e MYSQL_ROOT_PASSWORD=pass -p 3306:3306 -v mysql-data:/var/lib/mysql mysql:8
docker run -d --name redis -p 6379:6379 -v redis-data:/data redis:7

多个一起起,用 docker-compose 写一个文件、docker compose up。(记得 -v 挂数据卷,不然容器一删数据就没了。)

生产:千万别拿 docker run 单机上生产——没主从、没备份、没监控,出事就是大事故。真实是这么跑的:

• 大多数公司 → 云托管 RDS(阿里云 / AWS):申请个实例,高可用、自动备份、主从、扩容、监控全是云厂商包,开发者根本不碰运维。首选。
• 规模大 / 要数据自控 → K8s + Operator(MySQL / Redis Operator 自动管主从、故障转移、备份),或公司自建数据库平台让人按需申请实例。
• 大厂另有专门的 DBA / 存储团队 + 自研中间件。

一句话:本地用 Docker 练手 / 跑测试,生产"能托管就托管"(RDS)。

---

第二部分 · AI 大模型基建:多了哪些新东西

LLM 应用火起来后,后端基建多了一层"AI 专属"的。一个 AI 应用(不自研模型的话)大致要搭这几块,每块都有开源方案:

模块	干嘛	涉及的存储	开源方案
LLM 网关	统一接各家大模型(OpenAI/Claude/开源),做路由 / 限流 / 计费 / 密钥管理	配置、调用记录	LiteLLM
可观测性	追踪每次调用、日志、评估	trace→ClickHouse、元数据→Postgres、payload→对象存储	Langfuse(对标闭源的 LangSmith)
向量库 + RAG	存知识的 embedding、做语义检索	向量数据库	Milvus / pgvector
Prompt 管理 + 评估	prompt 版本管理、自动评模型效果	关系型	Langfuse 自带 / 自建

(只有自研模型的公司才需要再往下:GPU 集群、推理服务 vLLM、训练 / 微调、数据标注。)

重点:LLM 调用日志怎么存

这是 AI 基建里最有代表性的一块。LLM 应用每次调用会产生一条 trace——这次请求的 prompt、response、调了哪些工具、token 数、延迟、成本,还有人工 / 自动打的评分。量极大,主要拿来调试、分析、评估、算成本。

以开源的 Langfuse 为例(架构公开),正好又是一套"组合拳":

• 海量 trace / 指标 → ClickHouse(OLAP,列式、高写入吞吐、分析快,能扛上亿条 trace)
• 账户、项目、prompt 配置等元数据 → PostgreSQL(要事务的关系型)
• 大 payload、多模态输入(图片等) → 对象存储(S3 / OSS / MinIO)
• 队列削峰 + 缓存 → Redis

Langfuse 早期纯用 Postgres,数据量一大就扛不住,后来把 trace 迁到 ClickHouse,查询从分钟级降到近实时——正好印证第一部分"架构是长出来的"。

它怎么收集到数据的? 你的应用里装 SDK(langfuse / langsmith 包)、配几个参数(endpoint、key),它就自动在每次 LLM 调用处插桩(基于 OpenTelemetry 的 trace / span 模型),把链路上报到后端——不用手写埋点。常见做法还有"用开源 SDK + 自建一个兼容的后端平台",数据自控、不出公司。

一句话记住 AI 基建

接模型(网关)＋ 看效果(观测 / 评估)＋ 喂知识(向量 / RAG)＋ 管 prompt。 能开源自托管就自托管(LiteLLM + Langfuse + Milvus),云上有托管的按需选。

---

附:名词速查

• OLTP / OLAP:前者是"业务交易"(增删改查),后者是"分析查询"(海量统计)。
• 关系型 (MySQL / PG) / 文档型 (MongoDB) / 对象存储 (OSS / S3) / 数仓 (Hive / ClickHouse) / 时序库 (Prometheus) / ES:各管一类数据(见上表)。
• 图数据库 (Neo4j):存关系网络,查多跳关联快。
• 向量数据库 (Milvus / pgvector):存 embedding,按语义相似检索(RAG 用)。
• polyglot persistence:混合持久化,一种数据配一种存储。
• LLM 网关 (LiteLLM):统一接各家大模型、做路由 / 限流 / 计费。
• 可观测性 / Langfuse:追踪 LLM 调用链路(trace / span),开源、可自托管;LangSmith 是其闭源托管对标。
• RAG:检索增强生成——先从向量库检索相关知识,再喂给大模型。
• trace / span:一次请求的完整调用链路(trace)由一个个步骤(span)按父子关系串成树。

---

这是「数据存储」专题第一篇。鉴权专题三篇见 这里。完整代码与系列都在 GitHub:Aimee1608/backend-notes。