朋友好学朋友好学
40 分钟
AI 时代的全栈 App 开发实战

数据库深度选型：PostgreSQL / MySQL / Redis / MongoDB / 向量库

关系型、NoSQL、缓存、向量数据库，搞懂它们的核心特性、适用场景和选型方法。摸透PostgreSQL的能力，避开数据库选型的过度工程和常见陷阱。

  • 就说数据库的核心分类，分这几类：关系型（SQL）、文档型（NoSQL）、键值缓存、搜索引擎、向量数据库、时序数据库
  • 深入掌握 PostgreSQL 的核心能力：关系存储、JSONB、全文搜索、事务、扩展（pgvector/TimescaleDB/PostGIS）
  • MySQL 和 PostgreSQL 各有特点，用的时候看场景选。
  • 就这几个：Redis 的核心数据结构，还有对应的适用场景——缓存、会话、排行榜、限流、消息队列。
  • 理解 MongoDB（文档型）的适用场景和不适用场景，别什么都往 MongoDB 里塞。
  • 掌握向量数据库（pgvector/Milvus/Qdrant）在 RAG 和 AI 推荐中的应用
  • 学会一个 PostgreSQL 搞定 90%的极简选型策略，避免过度工程

数据库分类全景

数据库不止MySQL。现代应用可能要多种数据库一起用，但MVP阶段尽量简化。先建立全局视野：

示例代码（可运行）
🐍MVP 阶段的数据库选型原则

90% 的产品，一个 PostgreSQL 就够了。别一上来就 MySQL+Redis+MongoDB+ES+向量库五件套——那是大厂的架构，不是你的。PostgreSQL 能做：关系存储（默认）、JSONB（当文档数据库用）、全文搜索（tsvector，中小规模够用）、向量检索（pgvector 插件）、时序数据（TimescaleDB 插件）、地理空间（PostGIS 插件）、物化视图、窗口函数、CTE。等你真的遇到性能瓶颈（QPS 过万、数据量过亿、搜索延迟高），再引入 Redis/MongoDB/ES 做专项优化。过早引入多种数据库，只会增加运维复杂度、数据一致性问题和认知负担。本课程的朋友好学 App 目前是纯前端+本地存储（localStorage 经 Zustand persist 持久化），后端 server.js 用内存+文件存储，没有用数据库——因为 MVP 阶段用户数据存在本地就够了，等需要云端同步时再引入 PostgreSQL。

PostgreSQL：最强大的开源关系型数据库

PostgreSQL（简称 Postgres）是开源关系型数据库，被称为「开源界的 Oracle」。它是 SQL 数据库，也是可扩展的数据平台——通过插件系统，能给它加向量检索、时序、地理空间、全文搜索等能力。

核心能力

PostgreSQL

PostgreSQL 核心能力详解

①关系存储与 ACID 事务

PostgreSQL 是完整的 ACID 关系型数据库：原子性（Atomicity，事务要么全成功要么全失败）、一致性（Consistency，数据始终满足约束）、隔离性（Isolation，并发事务互不干扰，支持4种隔离级别）、持久性（Durability，提交后数据不丢失）。支持复杂的 JOIN、子查询、窗口函数、CTE（公用表表达式）、递归查询。适合：用户数据、订单、交易、任何需要强一致性和关联查询的数据。

②JSONB：当文档数据库用

JSONB 是 PostgreSQL 的二进制 JSON 类型，支持在 JSON 字段上建 GIN 索引、查询、修改。你可以把结构不固定的数据（如用户偏好、配置、动态表单）存在 JSONB 字段里，同时享受关系型数据库的事务和一致性。中小规模的应用，用 PostgreSQL + JSONB 完全可以替代 MongoDB，不需要单独引入文档数据库。

SQL
-- PostgreSQL JSONB 示例
-- CREATE TABLE users (
--   id SERIAL PRIMARY KEY,
--   email TEXT UNIQUE NOT NULL,
--   profile JSONB DEFAULT '{}'::jsonb  -- 结构不固定的用户资料
-- );
-- 
-- -- 插入 JSON 数据
-- INSERT INTO users (email, profile) VALUES
--   ('alice@example.com', '{"age": 25, "skills": ["Python", "React"], "city": "深圳"}'::jsonb);
-- 
-- -- 查询 JSON 字段（->> 取文本，-> 取 JSON 对象）
-- SELECT email, profile->>'city' as city FROM users WHERE profile->>'city' = '深圳';
-- 
-- -- 在 JSON 字段上建 GIN 索引（加速查询）
-- CREATE INDEX idx_users_profile ON users USING GIN (profile);
-- 
-- -- 更新 JSON 字段（jsonb_set）
-- UPDATE users SET profile = jsonb_set(profile, '{age}', '26'::jsonb) WHERE email = 'alice@example.com';

③全文搜索：tsvector

PostgreSQL 内置全文搜索能力：把文本转换成 tsvector（词元向量），支持分词、词干提取、停用词、排名。中小规模的应用（几十万到几百万条记录），PostgreSQL 全文搜索完全够用，不需要引入 Elasticsearch。中文分词需要装 zhparser 或 pg_jieba 插件。

④扩展生态：一个数据库顶五个

PostgreSQL 的扩展系统是它最强大的地方：pgvector（向量检索，RAG 必备）、TimescaleDB（时序数据，监控/IoT）、PostGIS（地理空间，地图/LBS）、pg_stat_statements（性能分析）、uuid-ossp（UUID 生成）、fdw（外部数据包装器，能查询其他数据库/CSV/API）。装一个扩展就多一种能力，不需要单独部署和维护新的数据库服务。

⑤其他高级特性

物化视图（预计算复杂查询）、分区表（大表按时间/范围分区）、行级安全（RLS，多租户数据隔离）、逻辑复制（数据同步到其他库）、热备（高可用）、存储过程/函数（PL/pgSQL、PL/Python、PL/V8）、自定义类型和操作符。

ℹ️PostgreSQL 的优势

功能最强大的开源关系型数据库，没有之一；JSONB 让它能当文档数据库用；全文搜索中小规模够用；扩展生态（pgvector/TimescaleDB/PostGIS）一个顶五个；ACID 事务完整，支持复杂查询；社区活跃，长期维护；云厂商全支持（AWS RDS/Aurora、GCP Cloud SQL、Azure、阿里云、腾讯云都有托管版）；免费开源，无授权费用。

⚠️PostgreSQL 的劣势

极端高并发写入（每秒十万+写入）不如 Cassandra/ClickHouse（但 99% 的产品到不了这个量级）；复杂查询的性能调优需要经验（索引设计、查询计划分析 EXPLAIN）；复制和高可用配置比 MySQL 复杂（虽然有 Patroni 等工具）；某些老应用/老框架对 PostgreSQL 支持不如 MySQL（但现代框架都支持）；内存占用比 SQLite/Redis 高，不适合嵌入式/极轻量场景。

MySQL：最流行的关系型数据库

MySQL 是全球使用的关系型数据库，尤其在 Web 开发和 LAMP 栈时代用得特别多，现在由 Oracle 维护，还有社区分支 MariaDB。特点是简单、稳定、高性能、生态成熟。WordPress、Facebook（早期）、淘宝（早期）都用 MySQL。

ℹ️MySQL vs PostgreSQL：怎么选

相同点：都是成熟的 ACID 关系型数据库，都能满足 90% 的应用需求。差异：功能丰富度：PostgreSQL > MySQL（JSONB、窗口函数、CTE、扩展生态 PG 更强）；简单易用：MySQL > PostgreSQL（配置少、上手快、中文资料多）；复制和高可用：MySQL 更成熟简单（主从复制配置容易），PostgreSQL 相对复杂；复杂查询和数据分析：PostgreSQL 更强；Web 生态：MySQL 更普及（WordPress/PHP/老项目）；扩展能力：PostgreSQL 完胜（pgvector 等）。选型建议：新项目、AI 产品、需要复杂查询/JSON/向量 → PostgreSQL；老项目维护、团队熟悉 MySQL、简单 CRUD 应用 → MySQL。两者都能托管在云平台，迁移成本不高。

Redis：不是数据库，是「数据结构服务器」

Redis（Remote Dictionary Server）严格来说不是传统数据库，而是「内存中的数据结构服务器」——所有数据存在内存里（可持久化到磁盘），支持多种数据结构（字符串、哈希、列表、集合、有序集合、流、位图、HyperLogLog），读写速度极快（微秒级，单节点 10万+ QPS）。

示例代码（可运行）
ℹ️Redis 的典型用途

缓存：把数据库查询结果存在 Redis，减少数据库压力；会话存储：存用户登录态、Session，比数据库快还支持自动过期；排行榜：ZSet 天然按分数排序，游戏、内容排行榜首选；限流：用计数器加过期时间，实现 API 限流，防止刷接口；分布式锁：用 SETNX 实现跨服务互斥锁；消息队列：用 List/Stream 做简单异步任务队列，复杂场景用 RabbitMQ/Kafka；实时计数：在线人数、点赞数、浏览量。注意：Redis 是缓存和辅助存储，不是主数据库——数据存在内存里，虽有 RDB/AOF 持久化，但极端情况可能丢少量数据，核心业务数据必须存在 PostgreSQL/MySQL。

⚠️Redis 的陷阱

把 Redis 当主数据库用：错！Redis 是内存存储，虽然能持久化，但不适合做核心业务的主存储（数据量大了内存成本高，持久化恢复慢）；不设过期时间：缓存不设 TTL，内存会被占满，最终 OOM；大 Key 问题：一个 Key 存几十 MB 数据（如大列表/大哈希），会阻塞 Redis、导致慢查询；热 Key 问题：某个 Key 被超高并发访问，打满单个 Redis 实例的 CPU；缓存穿透/击穿/雪崩：穿透（查不存在的数据，每次都打数据库）、击穿（热点 Key 过期瞬间大量请求打数据库）、雪崩（大量 Key 同时过期），需要用布隆过滤器/互斥锁/随机过期时间来防护。

MongoDB：文档型数据库的代表

MongoDB 是最流行的文档型 NoSQL 数据库，用 BSON（二进制 JSON）存储数据，不需要固定的表结构（schema-less），每个文档可以有不同的字段。适合：结构不固定的数据、内容管理、快速原型、日志存储。

ℹ️MongoDB 的优势与适用

schema-less，字段灵活，适合需求变化快的原型；文档模型天然匹配面向对象，一个对象就是一个文档，不需要 JOIN；水平扩展简单，分片 Sharding；查询能力强，支持丰富的查询操作符、聚合管道；GridFS 支持大文件存储。适用：内容管理系统（博客/文章/产品目录）、实时分析（IoT/日志）、移动应用的用户数据、原型/MVP。

⚠️MongoDB 的陷阱和不适用场景

别用 MongoDB 这几种场景：需要复杂 JOIN 和事务的（MongoDB 4.0+ 虽支持多文档事务，但性能和成熟度不如关系型）；数据高度关联且要强一致性的（订单/库存/财务）；需要复杂数据分析和报表的（SQL 的窗口函数/CTE 更强）；团队不熟文档模型，容易写出反范式的混乱数据结构。最大的坑：什么都存 MongoDB。很多新手因为 MongoDB 灵活就什么都往里塞，结果数据结构乱、查询性能差、数据一致性没法保证。正确做法：核心业务数据（用户/订单/交易）用关系型，结构不固定的辅助数据（日志/配置/内容）才用 MongoDB 或 PostgreSQL JSONB。

向量数据库：AI 时代的新基础设施

向量数据库是 AI 时代的新物种，专门存储和检索「向量」（embedding，把文本/图片/音频转换成的高维数值数组）。核心能力是「相似性搜索」——给定一个向量，找出数据库中最相似的 N 个向量。这是 RAG（检索增强生成）和 AI 推荐的核心基础设施。

向量数据库在 RAG 中的作用

文档切分：把长文档切成小块（chunk）向量化：用 embedding 模型（如 text-embedding-3）把每个 chunk 转成向量（如 1536 维）存储：把向量和原文存在向量数据库查询：用户提问时，把问题也转成向量检索：在向量数据库里找最相似的 N 个 chunk（语义匹配，不是关键词匹配）生成：把检索到的 chunk 作为上下文，和问题一起发给大模型生成答案向量数据库=RAG的记忆，让大模型能查到你的私有知识

配对题向量数据库方案与适用匹配
💡向量数据库选型建议

MVP/中小规模（百万级向量以内）→ pgvector，不用单独部署，和 PostgreSQL 在一起，运维成本为零，本课程的朋友好学 App 如果做 RAG 就选 pgvector；中大规模（千万到亿级）→ Qdrant 或 Milvus，性能更好，支持分布式；不想运维 → Pinecone 全托管；原型开发 → Chroma，几行代码就能跑。别一上来就部署 Milvus 集群——那是亿级数据才需要的，百万级 pgvector 完全够用，且查询延迟在 50ms 以内。

极简选型策略：一个 PostgreSQL 搞定 90%

就说人或者小团队，极简的数据库选型策略。

选择题

2人团队做AI知识库SaaS——用户上传文档、AI问答这种，MVP阶段用什么数据库合适？

🐍资深工程师的数据库选型心法

MVP 阶段：一个 PostgreSQL 搞定一切（关系+JSONB+全文+向量+时序+地理空间），不要引入多种数据库；性能瓶颈出现时：加 Redis 做缓存（读多写少的热点数据），加只读副本（读压力大），加分区表（数据量大），而不是换数据库；搜索需求：先试 PostgreSQL 全文搜索，不够用再引入 Elasticsearch/Meilisearch；AI/RAG：先试 pgvector，百万级够用，千万级再上 Milvus/Qdrant；时序数据：先试 PostgreSQL + TimescaleDB 插件，不够用再上 InfluxDB；永远不要把 Redis 当主数据库，永远不要把 MongoDB 当事务型数据库，永远不要在 MVP 阶段搞五件套；数据备份是底线：无论选什么数据库，都要有自动备份（至少每天一次，存到不同的地方），并定期测试恢复（能备份不能恢复=没备份）。

找 BugMVP 阶段搞多数据库架构是典型的过度工程，会把精力浪费在运维上而不是产品核心价值。
# 一个新手的数据库架构：「用户数据存 MySQL，缓存用 Redis，日志存 MongoDB，搜索用 Elasticsearch，向量用 Milvus，时序用 InfluxDB」

本节小结

数据库分类：关系型（PostgreSQL/MySQL）、文档型（MongoDB）、键值缓存（Redis）、搜索引擎（ES）、向量库（pgvector/Milvus）、时序（TimescaleDB）、图（Neo4j）。PostgreSQL 是开源关系型数据库：支持 ACID 事务，能当文档库用 JSONB，自带全文搜索，扩展生态（pgvector/TimescaleDB/PostGIS）覆盖多种场景。MySQL 更简单普及，老项目或团队熟悉时选。Redis 是内存数据结构服务器，用于缓存/会话/排行榜/限流/分布式锁，不是主数据库。MongoDB 适合结构不固定的辅助数据，不适合事务和强关联核心数据。向量数据库是 AI/RAG 的基础设施，MVP 用 pgvector，大规模用 Milvus/Qdrant。极简策略：一个 PostgreSQL 搞定 90%，瓶颈出现再专项优化，不要在 MVP 搞多数据库五件套。下一节讲 API 设计与鉴权——数据库选好了，前端怎么和后端通信。

资深工程师加餐

底层原理 · 大厂视角 · 工程经验，点卡片展开

独立开发者选栈的第一标准是“能不能一个人最快稳定交付”，而不是哪个框架最新。Next.js 这类全栈框架把路由、构建、静态导出、服务端接口收敛到一套工具链里，配合静态导出 + WebView 原生壳，能让一个人同时覆盖 Web 与移动端；选型时先验证最不确定的环节（离线运行、原生能力、AI 流式），跑通原型再全面投入，避免做到一半发现关键能力不成立。