教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载导读本指南源自 Datawhale easy-vibe 项目附录「数据模型」一章系统剖析关系型数据库在社交关系、传感器流水、AI 语义检索等场景下的力不从心之处并逐一讲解文档模型、图模型、时序模型、向量模型的适用边界与典型选型。读完你将掌握「按数据形态选型」的判断框架能够为一个新业务场景挑选最合适的数据存储方案并理解现代系统为什么普遍采用「多模型混用」架构。1. 关系型的边界为什么需要其他数据模型关系型数据库MySQL、PostgreSQL用「表 行 列」组织数据结构固定、关系明确非常适合订单、用户等传统业务数据。但现实世界的数据形态远不止这一种用户画像字段不定、社交网络关系层层嵌套、监控指标每秒百万条写入、AI 语义检索要求「意思相近」的匹配。面对这些形态关系型表格往往力不从心。数据形态关系型的痛点更合适的模型用户画像字段不固定嵌套结构频繁 ALTER TABLE大量 NULL 列文档模型社交网络朋友的朋友的朋友多层 JOIN 性能指数级下降图模型监控指标每秒百万条写入写入瓶颈历史数据膨胀时序模型AI 语义搜索「意思相近」的内容无法表达语义相似度向量模型这里要澄清一个核心观点不是「替代」关系型而是「补充」。大多数系统的核心业务仍然跑在 MySQL/PostgreSQL 上但在特定场景引入专用数据模型能获得数量级的性能提升。正如 数据库原理 一章所述关系型数据库擅长的是结构化数据的 CRUD、索引与事务ACID而文档、图、时序、向量模型解决的是关系型「不擅长」的那部分问题。2. 文档模型Document为「结构多变」而生2.1 文档模型概述文档模型将数据存储为JSON/BSON 文档每条记录是一个自包含的文档可以有不同的字段结构。MongoDB 是最具代表性的文档数据库{ _id: user_1001, name: 张三, tags: [VIP, 活跃], address: { city: 北京, district: 朝阳区 }, orders: [ { id: o1, amount: 299 }, { id: o2, amount: 599 } ] }关键特点无 Schema 约束不需要预定义表结构字段随时增减避免了关系型中「频繁 ALTER TABLE 大量 NULL 列」的窘境嵌套结构地址、订单直接嵌在文档里一次读取即可拿到全部数据省去多次 JOIN水平扩展天然适合分片Sharding轻松应对海量数据。2.2 文档 vs 关系型对比维度关系型MySQL文档型MongoDB数据结构固定 SchemaALTER TABLE 修改灵活 Schema随时加字段嵌套数据需要多表 JOIN直接嵌套在文档中跨记录关联JOIN 很强关联查询较弱适合场景结构稳定的业务数据结构多变的内容数据2.3 典型场景CMS 内容管理文章、评论、标签结构各异用户画像不同用户有不同的属性字段活跃度、地域、偏好各不相同商品目录手机有「屏幕尺寸」食品有「保质期」字段完全不同配置中心各服务的配置结构不统一。⚠️ 常见误区「MongoDB 不需要设计数据结构」——错文档模型同样需要认真设计嵌套层级不宜过深深嵌套会使更新与查询变得困难频繁更新的子文档应该拆分为独立集合。3. 图模型Graph为「关系遍历」而生3.1 图模型概述图模型用节点Node和边Edge表达实体及其关系。每个节点是一个实体每条边是一个关系节点和边都可以携带属性。Neo4j 是最具代表性的图数据库(张三) --[关注]-- (李四) --[关注]-- (王五) | | --------[购买]---- (iPhone) --[购买]--3.2 图模型的杀手级能力多跳查询场景在社交网络中找「朋友的朋友的朋友」。关系型的做法需要逐层 JOIN每多一跳就多一次 JOIN性能指数级下降SELECT DISTINCT f3.name FROM friends f1 JOIN friends f2 ON f1.friend_id f2.user_id JOIN friends f3 ON f2.friend_id f3.user_id WHERE f1.user_id 1001;图数据库的做法则用 Cypher 查询语言直接表达「1 到 3 跳」的遍历语义MATCH (me)-[:FOLLOWS*1..3]-(target) WHERE me.name 张三 RETURN DISTINCT target.name两种方式的本质差异在于关系型靠 JOIN 临时组装关系跳数越多成本越高而图数据库通过指针直接遍历关系多跳查询性能几乎不随跳数增长而变化。3.3 典型场景社交网络好友推荐、共同关注、影响力传播知识图谱实体关系推理「谁是谁的老师的学生」欺诈检测发现资金环路、关联账户网络推荐系统基于用户-商品-标签的关系图推荐。4. 时序模型Time-Series为「按时间写入与查询」而生4.1 时序模型概述时序模型以时间戳为主轴专门优化「按时间顺序写入、按时间范围查询」的场景timestamp device cpu_usage memory 2024-01-15 10:00:01 server-01 45% 12.3GB 2024-01-15 10:00:02 server-01 67% 12.5GB 2024-01-15 10:00:03 server-01 92% 14.1GB4.2 为什么不用 MySQL 存时序数据问题MySQL时序数据库InfluxDB写入速度万级/秒百万级/秒历史数据手动清理表越来越大自动过期策略TTL聚合查询GROUP BY 慢内置降采样5 秒 → 1 分钟均值存储效率通用存储空间浪费列式压缩节省 90% 空间时序数据库从存储引擎层面就针对「时间有序写入」做了优化追加式写入配合列式压缩大幅降低存储成本TTL 自动清理过期数据避免「表越来越大」的运维负担内置降采样让「秒级原始数据 → 分钟级聚合视图」开箱即用。4.3 典型场景服务器监控CPU、内存、磁盘每秒采集IoT 传感器温度、湿度、GPS 轨迹金融行情股票价格、交易量的秒级数据日志分析应用日志的时间线聚合。5. 向量模型Vector为「语义相似度」而生5.1 向量模型概述向量模型将文本、图片、音频等非结构化数据通过Embedding 模型转换为高维数字向量然后通过计算向量之间的距离来衡量语义相似度好吃的日料 → Embedding → [0.82, 0.15, 0.91, 0.33, ...] ↓ 余弦相似度 银座寿司之神 → [0.80, 0.18, 0.89, ...] → 96% 相似 意大利披萨 → [0.12, 0.85, 0.20, ...] → 31% 相似关于 Embedding 与向量检索的底层原理仓库中的 Embedding 与向量检索原理 一章做了更深入的展开Embedding 把「猫」和「狗」映射到相近的坐标、「汽车」映射到远处让语义相似度变成空间距离衡量相似度的核心度量包括余弦相似度看方向、忽略长度文本语义比较的首选与欧氏距离看端点直线距离。向量检索之所以能在百万级数据中毫秒级完成靠的是近似最近邻ANN索引暴力搜索Flat逐一比较准确但慢适合 10 万以下的小规模IVF 先聚类分区再就近搜索HNSW 构建多层图结构逐层导航召回率 99% 且查询极快PQ 把高维向量压缩成短编码以少量精度换取大幅内存节省适合超大规模数据集。5.2 向量搜索 vs 关键词搜索对比关键词搜索LIKE / 全文索引向量搜索搜索方式精确匹配字符串语义相似度匹配「好吃的日料」只能匹配包含「日料」的文本能找到「寿司」「刺身」「居酒屋」多语言需要分别处理跨语言语义理解多模态仅文本文本、图片、音频统一检索需要注意的是两种检索并非互斥RAG 工程实践中普遍采用Hybrid Search混合检索——关键词检索如 BM25对精确术语、代号、表格字段更稳健向量检索擅长捕捉语义相似度二者融合后经重排序Reranking可兼顾精度与召回。5.3 典型场景RAG检索增强生成为 LLM 提供相关知识片段——这是向量模型最热门的落地场景仓库中的 RAG检索增强生成的管道设计 一章详细介绍了「索引 → 检索 → 生成」三阶段流程语义搜索理解用户意图而非关键词以图搜图上传一张图找到视觉相似的图片推荐系统基于内容语义的相似推荐。5.4 向量数据库怎么选独立向量数据库Pinecone、Milvus、Weaviate —— 专注向量检索性能最优。其中 Milvus 为开源分布式方案适合大规模生产环境传统数据库扩展pgvectorPostgreSQL、Atlas Vector SearchMongoDB—— 减少架构复杂度已有 PostgreSQL 的团队无需引入新组件内存向量库FAISS、Annoy —— 适合小规模、低延迟场景轻量开源方案Chroma、Qdrant —— 前者嵌入式、API 简洁适合本地开发与小型项目后者基于 Rust 实现、过滤能力强。选型时通常遵循一条经验法则小项目用 Chroma/pgvector 起步生产环境上 Pinecone/Milvus。6. 如何选择数据模型从数据形态出发的决策框架把问题反过来问——「你的数据长什么样」——答案自然导向最合适的模型你的数据长什么样推荐模型代表产品结构固定关系明确订单、用户关系型MySQL、PostgreSQL结构灵活嵌套层级多内容、配置文档型MongoDB、DynamoDB实体之间关系复杂需要多跳遍历图Neo4j、Amazon Neptune按时间顺序写入按时间范围查询时序InfluxDB、TimescaleDB非结构化数据需要语义相似度搜索向量Pinecone、Milvus、pgvector7. 实战建议现代系统普遍「多模型混用」现代系统通常不是「一个数据库解决所有问题」而是让每种数据找到最合适的「家」核心业务用 PostgreSQL关系型——保证事务一致性与复杂查询能力用户行为日志用 InfluxDB时序——承受高写入并自动过期AI 知识库用 Milvus pgvector向量——支撑语义检索与 RAG推荐引擎用 Neo4j图——表达并遍历复杂的用户-商品关系。这套组合在 easy-vibe 的课程体系中也有印证后端阶段从 数据库到 Supabase 起步建立数据模型AI 能力阶段则通过 Dify 知识库 落地 RAG 场景——而 RAG 的底层正是「文档加载 → 分块 → Embedding 向量化 → 向量数据库检索」这一向量模型流水线。总结回顾本篇的关键要点关系型不是被替代而是被补充订单、用户等核心业务继续跑在 MySQL/PostgreSQL 上特定场景引入专用模型可获得数量级性能提升文档模型解决「结构多变」灵活 Schema 嵌套结构适合内容、画像、目录类数据但仍需认真设计嵌套深度图模型解决「关系遍历」指针直达让多跳查询性能几乎恒定是社交、知识图谱、反欺诈的杀手锏时序模型解决「时间写入与查询」百万级写入、TTL 过期、内置降采样、列式压缩四大优势向量模型解决「语义相似度」Embedding 把语义变成空间距离ANN 索引让百万级检索降到毫秒级是 RAG 与语义搜索的基础设施选型先看数据形态结构固定→关系型结构灵活→文档型关系复杂→图时间序→时序语义相似→向量多模型混用是常态PostgreSQL 管核心业务、InfluxDB 收日志、Milvus/pgvector 支撑知识库、Neo4j 驱动推荐——让每种数据各得其所才是现代系统的架构常态。赞分享教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载相关推荐Easy Vibe 数据模型全景文档/图/时序/向量——为什么你的数据不能全塞进 MySQLEasy Vibe 数据模型全景文档/图/时序/向量——为什么你的数据不能全塞进 MySQL 本指南是 Easy Vibe 课程体系中「数据」附录的核心章节教程文档人工智能Vibe Codingeasy-vibe 数据建模全景文档型、图、时序、向量四种数据模型的原理与选型实践easy vibe 数据建模全景文档型、图、时序、向量四种数据模型的原理与选型实践 本篇技术指南以 docs/es es/appendix/5 data/da教程文档Easy-Vibe 数据模型全景文档、图、时序与向量四类模型的选型与实战Easy Vibe 数据模型全景文档、图、时序与向量四类模型的选型与实战 ::: tip 导读 本文是 Datawhale easy vibe 学习项目「5教程文档上一篇2FAuth高级功能探索WebAuthn认证、分组管理和批量操作下一篇如何快速搭建开源客服聊天系统Papercups完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考