Easy-Vibe 数据建模全景指南文档、图、时序与向量四大数据模型的选择与实践【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe导读本文是 Easy-Vibe 课程「数据」专题docs/fr-fr/appendix/5-data/data-models.md的核心讲解围绕一个关键问题展开为什么不能把所有数据都塞进 MySQL 的关系表当数据是社交网络关系、每秒百万级的传感器流、或是需要 AI 理解语义的向量时关系模型会触及其能力边界。读完本文你将掌握文档、图、时序、向量四种数据模型的适用边界与底层原理学会用「数据形态 → 模型 → 产品」的决策框架为每一类数据找到最合适的存储归宿并理解现代系统多模型混合架构PostgreSQL InfluxDB Milvus Neo4j的搭配逻辑。本文在继承原文档全部内容的基础上结合 Easy-Vibe 仓库中 数据库基础、Embedding 与向量检索、RAG 实战 等章节做纵深展开。1. 超越关系型为什么需要其他数据模型在深入之前先回顾关系型数据库的基本盘。如 数据库基础章节 所述关系型数据库MySQL、PostgreSQL以「表 行 列」组织数据配合主键唯一、非空、不可变、外键指向其他表主键的「桥梁」与 SQL 的 CRUDINSERT/SELECT/UPDATE/DELETE非常适合结构固定、关系清晰的业务数据——订单、用户、库存这类典型场景。但现实世界的数据形态远比这丰富关系模型面对四类数据时会暴露明显的短板数据形态关系型的痛点更合适的模型用户画像字段不固定、结构嵌套频繁ALTER TABLE、大量 NULL 列文档模型社交网络朋友的朋友的朋友多层 JOIN 性能指数级下降图模型监控指标每秒百万级写入写入瓶颈、历史数据膨胀时序模型AI 语义搜索「意思相近」的内容无法表达语义相似度向量模型::: info 核心观点 这四种模型的意义不是「取代」关系型而是「补充」它。大多数系统的核心业务仍然跑在 MySQL/PostgreSQL 上但在特定场景引入专用数据模型可以带来数量级的性能提升。 :::2. 文档模型Document2.1 什么是文档模型文档模型将数据存储为JSON/BSON 文档每条记录是一个自包含的文档可以拥有完全不同的字段结构。以一份用户数据为例{ _id: user_1001, name: Jean Dupont, tags: [VIP, actif], address: { city: Paris, district: Marais }, orders: [ { id: o1, amount: 299 }, { id: o2, amount: 599 } ] }核心特征无模式约束无需预先定义表结构字段可随时增删。对比关系型中修改结构需要ALTER TABLE文档模型天然支持「先写代码、结构随业务演进」的敏捷节奏嵌套结构地址、订单直接内嵌在文档中一次读取即可拿到全部相关数据省去多次 JOIN 的网络与计算开销水平扩展文档天然适合分片sharding——按_id或字段把文档分布到不同节点容易支撑海量数据。2.2 文档模型 vs 关系模型对比维度关系型MySQL文档型MongoDB数据结构固定 Schema靠ALTER TABLE修改灵活 Schema随时加字段嵌套数据需要多表 JOIN直接内嵌在文档中跨记录关系JOIN 能力极强关系查询能力较弱适合场景结构稳定的业务数据结构多变的内容数据2.3 典型应用场景CMS 内容管理文章、评论、标签结构千差万别用户画像不同用户拥有不同的属性字段商品目录手机有「屏幕尺寸」、食品有「保质期」——字段完全不同用一张关系表会产生大量稀疏 NULL 列配置中心每个服务的配置结构不统一。::: warning 常见误区 「MongoDB 不需要做数据结构设计」——错误文档模型同样需要精心设计嵌套层级不宜过深否则更新深层子文档代价高、查询复杂频繁更新的子文档应拆分为独立集合。 :::3. 图模型Graph3.1 什么是图模型图模型通过**节点Nodes和边Edges**表达实体及其关系每个节点是一个实体每条边是一个关系节点和边都可以携带属性。(Jean) --[suit]-- (Marie) --[suit]-- (Pierre) | | --------[achète]---- (iPhone) --[achète]--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表示 1 到 3 跳的变长路径MATCH (me)-[:FOLLOWS*1..3]-(target) WHERE me.name Jean RETURN DISTINCT target.name原理对比关系模型中每增加一跳就多一次 JOIN性能呈指数级恶化而图数据库通过指针直接遍历关系存储上边就是实体的直接引用多跳查询的性能几乎恒定。这背后对应 数据库基础章节 提到的 JOIN 机制——关系型的关联是查询期计算的图模型的关联是存储期固化的。3.3 典型应用场景社交网络好友推荐、共同关注、影响力传播知识图谱实体关系推理「谁是谁的老师的学生的学生」反欺诈发现资金环路、关联账户网络推荐系统基于用户-商品-标签关系图的推荐。4. 时序模型Time-Series4.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% 空间写入路径的差异值得展开关系型为了支持任意行更新与事务ACID见 数据库基础章节 的事务小节写入时需要维护索引、redo/undo 日志与锁单机吞吐受限时序数据库则按时间有序追加写入配合列式存储与压缩把「只追加、几乎不更新」的数据特性利用到极致从而把写入吞吐提升数个量级。TTL 与降采样则是把「历史数据治理」从手工运维变成引擎内置策略。4.3 典型应用场景服务器监控CPU、内存、磁盘每秒采集一次IoT 传感器温度、湿度、GPS 轨迹金融行情秒级股票价格与成交量日志分析应用日志的时间线聚合。5. 向量模型Vector5.1 什么是向量模型向量模型通过**嵌入模型Embedding**把文本、图像、音频等非结构化数据转换为高维数值向量再通过计算向量间距离衡量语义相似度。bon resto japonais → Embedding → [0.82, 0.15, 0.91, 0.33, ...] ↓ Similarité cosinus sushi maître Ginza → [0.80, 0.18, 0.89, ...] → 96 % similaire pizza italienne → [0.12, 0.85, 0.20, ...] → 31 % similaire关于 Embedding 的底层原理Embedding 与向量检索章节 给出了更完整的铺垫One-Hot 编码的致命缺陷是「所有词彼此等距」——「猫」与「狗」的距离和「猫」与「汽车」完全相同不携带任何语义Embedding把词/句投影到稠密低维空间维度通常 7681536语义相近的向量自然聚拢「猫」和「狗」近、「汽车」远语义相似度被转化为空间距离相似度的常用度量包括余弦相似度与欧氏距离其中余弦相似度关注方向、对向量模长不敏感是文本语义检索的首选。5.2 向量搜索 vs 关键词搜索对比项关键词搜索LIKE / 全文索引向量搜索搜索方式字符串精确匹配语义相似度匹配查询「好吃的日料」只能匹配含「日料」的文本能找到「寿司」「刺身」「居酒屋」多语言需单独处理跨语言语义理解多模态仅文本文本、图像、音频统一检索值得注意的是Easy-Vibe 的 数据库基础章节 在索引优化中特别警告LIKE %词%会触发全表扫描、无法走索引而LIKE 词%可用索引。这恰恰说明了关键词匹配的本质局限——它只能做「前缀/包含」级别的结构匹配永远无法回答「意思相近但字面不同」的查询而这正是向量模型的价值所在。5.3 典型应用场景RAG检索增强生成为 LLM 提供相关知识片段。Easy-Vibe 在 RAG 入门章节 和 RAG 原理章节 中演示了「文档切分 → 向量化入库 → 语义召回 → 组装提示词」的完整链路向量库是这条链路的地基语义搜索理解用户意图而非关键词以图搜图上传图片找到视觉相似的图片推荐系统基于内容语义做相似推荐。::: tip 向量数据库选型独立向量数据库Pinecone、Milvus、Weaviate——专注向量检索性能最优传统数据库扩展pgvectorPostgreSQL、Atlas Vector SearchMongoDB——减少架构复杂度让关系库顺带承担向量检索内存向量库FAISS、Annoy——适合小规模、低延迟场景。 :::在 Easy-Vibe 的 AI 能力字典章节 与 知识库构建实战 中可以进一步看到向量模型在真实产品如基于 Dify 搭建的知识库问答应用中的落地方案知识文档先被切块并向量化查询时对用户提问做同样的向量化再到向量库中做 ANN近似最近邻检索最后把召回片段交给 LLM 生成回答。6. 选型决策如何选择数据模型6.1 一张决策表你的数据长什么样推荐模型代表产品结构固定、关系清晰订单、用户关系型MySQL、PostgreSQL结构灵活、嵌套层次多内容、配置文档型MongoDB、DynamoDB实体关系复杂、需多跳遍历图Neo4j、Amazon Neptune按时间顺序写入、按时间范围查询时序InfluxDB、TimescaleDB非结构化数据、需语义相似检索向量Pinecone、Milvus、pgvector6.2 现代系统的默认答案多模型混合::: info 实战建议 现代系统通常采用多模型混合架构而不是寻找「一个解决所有问题的数据库」核心业务放 PostgreSQL关系型用户行为日志放 InfluxDB时序AI 知识库放 Milvus pgvector向量推荐引擎放 Neo4j图。不要追求「一库通吃」而是让每一类数据找到最合适的归宿。 :::这个思路与 Easy-Vibe 全栈实战章节的架构选型一脉相承核心交易数据用关系库保证事务一致性ACID行为埋点数据走 事件追踪章节 描述的「采集 → 4W1H 建模 → 批量传输 → ETL 清洗」流水线进入分析型存储AI 能力则依赖向量检索支撑 RAG 问答。数据在哪里存放取决于你要对它做什么样的操作。7. 结语让数据各得其所回顾全文四种数据模型分别回答了一类核心问题模型一句话概括解决的痛点关键要点文档模型一条记录一个自包含 JSON结构多变、嵌套数据无 Schema、内嵌、易分片嵌套不宜过深图模型节点 边表达关系多跳关系查询指针遍历多跳性能恒定时序模型时间戳为主轴追加写入高频写入与历史治理TTL、降采样、列式压缩向量模型语义距离 向量距离相似度检索Embedding 余弦相似度 ANN 索引选择数据模型的本质是匹配数据的读写模式关系型把一致性放在首位文档型把灵活性放在首位图模型把关联遍历放在首位时序型把追加写入与时间窗口聚合放在首位向量型把语义相似度放在首位。理解这五者你就能在搭建真实产品时无论是 Easy-Vibe 中的知识库应用、推荐系统还是监控大盘做出有理有据的存储选型。深入学习可继续阅读本仓库 附录数据专题目录按「数据库基础 → 数据模型 → 数据追踪 → 数据可视化」的路径循序渐进。【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Easy-Vibe 数据建模全景指南：文档、图、时序与向量四大数据模型的选择与实践
Easy-Vibe 数据建模全景指南文档、图、时序与向量四大数据模型的选择与实践【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe导读本文是 Easy-Vibe 课程「数据」专题docs/fr-fr/appendix/5-data/data-models.md的核心讲解围绕一个关键问题展开为什么不能把所有数据都塞进 MySQL 的关系表当数据是社交网络关系、每秒百万级的传感器流、或是需要 AI 理解语义的向量时关系模型会触及其能力边界。读完本文你将掌握文档、图、时序、向量四种数据模型的适用边界与底层原理学会用「数据形态 → 模型 → 产品」的决策框架为每一类数据找到最合适的存储归宿并理解现代系统多模型混合架构PostgreSQL InfluxDB Milvus Neo4j的搭配逻辑。本文在继承原文档全部内容的基础上结合 Easy-Vibe 仓库中 数据库基础、Embedding 与向量检索、RAG 实战 等章节做纵深展开。1. 超越关系型为什么需要其他数据模型在深入之前先回顾关系型数据库的基本盘。如 数据库基础章节 所述关系型数据库MySQL、PostgreSQL以「表 行 列」组织数据配合主键唯一、非空、不可变、外键指向其他表主键的「桥梁」与 SQL 的 CRUDINSERT/SELECT/UPDATE/DELETE非常适合结构固定、关系清晰的业务数据——订单、用户、库存这类典型场景。但现实世界的数据形态远比这丰富关系模型面对四类数据时会暴露明显的短板数据形态关系型的痛点更合适的模型用户画像字段不固定、结构嵌套频繁ALTER TABLE、大量 NULL 列文档模型社交网络朋友的朋友的朋友多层 JOIN 性能指数级下降图模型监控指标每秒百万级写入写入瓶颈、历史数据膨胀时序模型AI 语义搜索「意思相近」的内容无法表达语义相似度向量模型::: info 核心观点 这四种模型的意义不是「取代」关系型而是「补充」它。大多数系统的核心业务仍然跑在 MySQL/PostgreSQL 上但在特定场景引入专用数据模型可以带来数量级的性能提升。 :::2. 文档模型Document2.1 什么是文档模型文档模型将数据存储为JSON/BSON 文档每条记录是一个自包含的文档可以拥有完全不同的字段结构。以一份用户数据为例{ _id: user_1001, name: Jean Dupont, tags: [VIP, actif], address: { city: Paris, district: Marais }, orders: [ { id: o1, amount: 299 }, { id: o2, amount: 599 } ] }核心特征无模式约束无需预先定义表结构字段可随时增删。对比关系型中修改结构需要ALTER TABLE文档模型天然支持「先写代码、结构随业务演进」的敏捷节奏嵌套结构地址、订单直接内嵌在文档中一次读取即可拿到全部相关数据省去多次 JOIN 的网络与计算开销水平扩展文档天然适合分片sharding——按_id或字段把文档分布到不同节点容易支撑海量数据。2.2 文档模型 vs 关系模型对比维度关系型MySQL文档型MongoDB数据结构固定 Schema靠ALTER TABLE修改灵活 Schema随时加字段嵌套数据需要多表 JOIN直接内嵌在文档中跨记录关系JOIN 能力极强关系查询能力较弱适合场景结构稳定的业务数据结构多变的内容数据2.3 典型应用场景CMS 内容管理文章、评论、标签结构千差万别用户画像不同用户拥有不同的属性字段商品目录手机有「屏幕尺寸」、食品有「保质期」——字段完全不同用一张关系表会产生大量稀疏 NULL 列配置中心每个服务的配置结构不统一。::: warning 常见误区 「MongoDB 不需要做数据结构设计」——错误文档模型同样需要精心设计嵌套层级不宜过深否则更新深层子文档代价高、查询复杂频繁更新的子文档应拆分为独立集合。 :::3. 图模型Graph3.1 什么是图模型图模型通过**节点Nodes和边Edges**表达实体及其关系每个节点是一个实体每条边是一个关系节点和边都可以携带属性。(Jean) --[suit]-- (Marie) --[suit]-- (Pierre) | | --------[achète]---- (iPhone) --[achète]--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表示 1 到 3 跳的变长路径MATCH (me)-[:FOLLOWS*1..3]-(target) WHERE me.name Jean RETURN DISTINCT target.name原理对比关系模型中每增加一跳就多一次 JOIN性能呈指数级恶化而图数据库通过指针直接遍历关系存储上边就是实体的直接引用多跳查询的性能几乎恒定。这背后对应 数据库基础章节 提到的 JOIN 机制——关系型的关联是查询期计算的图模型的关联是存储期固化的。3.3 典型应用场景社交网络好友推荐、共同关注、影响力传播知识图谱实体关系推理「谁是谁的老师的学生的学生」反欺诈发现资金环路、关联账户网络推荐系统基于用户-商品-标签关系图的推荐。4. 时序模型Time-Series4.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% 空间写入路径的差异值得展开关系型为了支持任意行更新与事务ACID见 数据库基础章节 的事务小节写入时需要维护索引、redo/undo 日志与锁单机吞吐受限时序数据库则按时间有序追加写入配合列式存储与压缩把「只追加、几乎不更新」的数据特性利用到极致从而把写入吞吐提升数个量级。TTL 与降采样则是把「历史数据治理」从手工运维变成引擎内置策略。4.3 典型应用场景服务器监控CPU、内存、磁盘每秒采集一次IoT 传感器温度、湿度、GPS 轨迹金融行情秒级股票价格与成交量日志分析应用日志的时间线聚合。5. 向量模型Vector5.1 什么是向量模型向量模型通过**嵌入模型Embedding**把文本、图像、音频等非结构化数据转换为高维数值向量再通过计算向量间距离衡量语义相似度。bon resto japonais → Embedding → [0.82, 0.15, 0.91, 0.33, ...] ↓ Similarité cosinus sushi maître Ginza → [0.80, 0.18, 0.89, ...] → 96 % similaire pizza italienne → [0.12, 0.85, 0.20, ...] → 31 % similaire关于 Embedding 的底层原理Embedding 与向量检索章节 给出了更完整的铺垫One-Hot 编码的致命缺陷是「所有词彼此等距」——「猫」与「狗」的距离和「猫」与「汽车」完全相同不携带任何语义Embedding把词/句投影到稠密低维空间维度通常 7681536语义相近的向量自然聚拢「猫」和「狗」近、「汽车」远语义相似度被转化为空间距离相似度的常用度量包括余弦相似度与欧氏距离其中余弦相似度关注方向、对向量模长不敏感是文本语义检索的首选。5.2 向量搜索 vs 关键词搜索对比项关键词搜索LIKE / 全文索引向量搜索搜索方式字符串精确匹配语义相似度匹配查询「好吃的日料」只能匹配含「日料」的文本能找到「寿司」「刺身」「居酒屋」多语言需单独处理跨语言语义理解多模态仅文本文本、图像、音频统一检索值得注意的是Easy-Vibe 的 数据库基础章节 在索引优化中特别警告LIKE %词%会触发全表扫描、无法走索引而LIKE 词%可用索引。这恰恰说明了关键词匹配的本质局限——它只能做「前缀/包含」级别的结构匹配永远无法回答「意思相近但字面不同」的查询而这正是向量模型的价值所在。5.3 典型应用场景RAG检索增强生成为 LLM 提供相关知识片段。Easy-Vibe 在 RAG 入门章节 和 RAG 原理章节 中演示了「文档切分 → 向量化入库 → 语义召回 → 组装提示词」的完整链路向量库是这条链路的地基语义搜索理解用户意图而非关键词以图搜图上传图片找到视觉相似的图片推荐系统基于内容语义做相似推荐。::: tip 向量数据库选型独立向量数据库Pinecone、Milvus、Weaviate——专注向量检索性能最优传统数据库扩展pgvectorPostgreSQL、Atlas Vector SearchMongoDB——减少架构复杂度让关系库顺带承担向量检索内存向量库FAISS、Annoy——适合小规模、低延迟场景。 :::在 Easy-Vibe 的 AI 能力字典章节 与 知识库构建实战 中可以进一步看到向量模型在真实产品如基于 Dify 搭建的知识库问答应用中的落地方案知识文档先被切块并向量化查询时对用户提问做同样的向量化再到向量库中做 ANN近似最近邻检索最后把召回片段交给 LLM 生成回答。6. 选型决策如何选择数据模型6.1 一张决策表你的数据长什么样推荐模型代表产品结构固定、关系清晰订单、用户关系型MySQL、PostgreSQL结构灵活、嵌套层次多内容、配置文档型MongoDB、DynamoDB实体关系复杂、需多跳遍历图Neo4j、Amazon Neptune按时间顺序写入、按时间范围查询时序InfluxDB、TimescaleDB非结构化数据、需语义相似检索向量Pinecone、Milvus、pgvector6.2 现代系统的默认答案多模型混合::: info 实战建议 现代系统通常采用多模型混合架构而不是寻找「一个解决所有问题的数据库」核心业务放 PostgreSQL关系型用户行为日志放 InfluxDB时序AI 知识库放 Milvus pgvector向量推荐引擎放 Neo4j图。不要追求「一库通吃」而是让每一类数据找到最合适的归宿。 :::这个思路与 Easy-Vibe 全栈实战章节的架构选型一脉相承核心交易数据用关系库保证事务一致性ACID行为埋点数据走 事件追踪章节 描述的「采集 → 4W1H 建模 → 批量传输 → ETL 清洗」流水线进入分析型存储AI 能力则依赖向量检索支撑 RAG 问答。数据在哪里存放取决于你要对它做什么样的操作。7. 结语让数据各得其所回顾全文四种数据模型分别回答了一类核心问题模型一句话概括解决的痛点关键要点文档模型一条记录一个自包含 JSON结构多变、嵌套数据无 Schema、内嵌、易分片嵌套不宜过深图模型节点 边表达关系多跳关系查询指针遍历多跳性能恒定时序模型时间戳为主轴追加写入高频写入与历史治理TTL、降采样、列式压缩向量模型语义距离 向量距离相似度检索Embedding 余弦相似度 ANN 索引选择数据模型的本质是匹配数据的读写模式关系型把一致性放在首位文档型把灵活性放在首位图模型把关联遍历放在首位时序型把追加写入与时间窗口聚合放在首位向量型把语义相似度放在首位。理解这五者你就能在搭建真实产品时无论是 Easy-Vibe 中的知识库应用、推荐系统还是监控大盘做出有理有据的存储选型。深入学习可继续阅读本仓库 附录数据专题目录按「数据库基础 → 数据模型 → 数据追踪 → 数据可视化」的路径循序渐进。【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考