尧图网页设计 
Easy Vibe 数据模型全景文档/图/时序/向量——为什么你的数据不能全塞进 MySQL【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe本指南是 Easy Vibe 课程体系中「数据」附录的核心章节对应 docs/es-es/appendix/5-data/data-models.md各语言版本内容一致如 中文版。当你面对社交关系网、每秒百万条的传感器流水、或者 AI 需要理解的语义向量时关系型表格就会力不从心。读完本文你将掌握文档、图、时序、向量四种非关系型数据模型的适用场景、核心原理与选型方法并能在多模型混用的现代系统架构中为每种数据找到最合适的家。1. 超越关系型为什么需要其他数据模型关系型数据库MySQL、PostgreSQL用表 行 列组织数据适合结构固定、关系明确的业务数据。但现实世界的数据远不止这一种形态数据形态关系型的痛点更合适的模型用户画像字段不固定嵌套结构频繁ALTER TABLE大量 NULL 列文档模型社交网络朋友的朋友的朋友多层 JOIN 性能指数级下降图模型监控指标每秒百万条写入写入瓶颈历史数据膨胀时序模型AI 语义搜索意思相近的内容无法表达语义相似度向量模型::: info 核心观点 不是替代关系型而是补充。大多数系统的核心业务仍然跑在 MySQL/PostgreSQL 上但在特定场景引入专用数据模型能获得数量级的性能提升。 :::这一点在 Easy Vibe 的学习路线中与 数据库原理索引/事务/查询优化 互为表里数据库原理一章讲透关系型的地基表、主键、外键、B 树、ACID而本文则向上拓展——当单一关系型模型无法承载某些数据形态时如何选用专用模型。2. 文档模型Document2.1 文档模型概述文档模型将数据存储为JSON/BSON 文档每条记录是一个自包含的文档可以有不同的字段结构{ _id: user_1001, name: 张三, tags: [VIP, 活跃], address: { city: 北京, district: 朝阳区 }, orders: [ { id: o1, amount: 299 }, { id: o2, amount: 599 } ] }关键特点无 Schema 约束不需要预定义表结构字段随时增减嵌套结构地址、订单直接嵌在文档里一次读取即可获得全部数据避免了关系型中一次页面展示 多次 JOIN的麻烦水平扩展天然适合分片Sharding轻松应对海量数据。2.2 文档 vs 关系型对比维度关系型MySQL文档型MongoDB数据结构固定 SchemaALTER TABLE修改灵活 Schema随时加字段嵌套数据需要多表 JOIN直接嵌套在文档中跨记录关联JOIN 很强关联查询较弱适合场景结构稳定的业务数据结构多变的内容数据2.3 典型场景CMS 内容管理文章、评论、标签结构各异用户画像不同用户有不同的属性字段字段随业务增长不断演进商品目录手机有屏幕尺寸食品有保质期字段完全不同若强行建关系表会出现大量稀疏 NULL 列配置中心各服务的配置结构不统一。::: warning ⚠️ 常见误区 MongoDB 不需要设计数据结构 —— 错文档模型同样需要认真设计嵌套层级不宜过深频繁更新的子文档应该拆分为独立集合否则会产生更新放大与并发锁竞争问题。 :::3. 图模型Graph3.1 图模型概述图模型用节点Node和边Edge表达实体及其关系。每个节点是一个实体每条边是一个关系节点和边都可以携带属性(张三) --[关注]-- (李四) --[关注]-- (王五) | | --------[购买]---- (iPhone) --[购买]--3.2 图模型的杀手级能力多跳查询场景在社交网络中找朋友的朋友的朋友3 度人脉。关系型做法3 层 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 查询语言通过指针直接遍历关系多跳查询性能几乎不变MATCH (me)-[:FOLLOWS*1..3]-(target) WHERE me.name 张三 RETURN DISTINCT target.name两者的本质区别在于数据组织方式关系型把关系建模成外键列 运行时 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% 空间从上表可以提炼出时序数据库的四个核心设计取向追加式写入引擎面向高吞吐顺序写、TTL 生命周期管理自动淘汰冷数据、预聚合/连续查询把降采样下沉到存储层、列式压缩编码同一指标相邻时间点的值高度相似压缩比极高。4.3 典型场景服务器监控CPU、内存、磁盘每秒采集IoT 传感器温度、湿度、GPS 轨迹金融行情股票价格、交易量的秒级数据日志分析应用日志的时间线聚合。5. 向量模型Vector5.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% 相似这一模型正是 Easy Vibe 课程体系中 AI 方向的核心地基之一向量检索是 RAG 检索增强生成 与 Embedding 与向量检索 的技术底座。上图展示了向量模型在真实系统中的典型落地形态知识片段以文本 向量的形式存入向量数据库Vector DB用户提问触发 Retrieve 检索命中片段被注入 Augmented Context最终交由模型基于检索到的上下文作答——这正是 RAG 中先检索、再生成的核心闭环。5.2 向量搜索 vs 关键词搜索对比关键词搜索LIKE / 全文索引向量搜索搜索方式精确匹配字符串语义相似度匹配好吃的日料只能匹配包含日料的文本能找到寿司刺身居酒屋多语言需要分别处理跨语言语义理解多模态仅文本文本、图片、音频统一检索5.3 典型场景RAG检索增强生成为 LLM 提供相关知识片段缓解幻觉并实现知识实时更新语义搜索理解用户意图而非关键词以图搜图上传一张图找到视觉相似的图片推荐系统基于内容语义的相似推荐。::: tip 向量数据库的选择独立向量数据库Pinecone、Milvus、Weaviate —— 专注向量检索性能最优传统数据库扩展pgvectorPostgreSQL、Atlas Vector SearchMongoDB—— 减少架构复杂度让关系型与向量检索共存于同一存储内存向量库FAISS、Annoy —— 适合小规模、低延迟场景。 :::从工程落地角度选型时可以按规模与运维成本梯度决策小规模原型优先用 pgvector 这类扩展需要独立扩展与混合检索标量 向量时再引入 Milvus 等专用引擎对延迟极度敏感的场景才考虑 FAISS 这类纯内存索引。6. 选择数据模型的方法6.1 数据形态 → 模型 → 产品对照表你的数据长什么样推荐模型代表产品结构固定关系明确订单、用户关系型MySQL、PostgreSQL结构灵活嵌套层级多内容、配置文档型MongoDB、DynamoDB实体之间关系复杂需要多跳遍历图Neo4j、Amazon Neptune按时间顺序写入按时间范围查询时序InfluxDB、TimescaleDB非结构化数据需要语义相似度搜索向量Pinecone、Milvus、pgvector6.2 多模型混用现代系统的常态::: info 实战建议 现代系统通常是多模型混用核心业务用 PostgreSQL关系型用户行为日志用 InfluxDB时序AI 知识库用 Milvus pgvector向量推荐引擎用 Neo4j图。不要追求一个数据库解决所有问题而是让每种数据找到最合适的家。 :::多模型混用的判断顺序可以简化为三个问题数据是否写入后极少变化且需要精确关联→ 关系型结构是否随业务快速变化、需要嵌套表达→ 文档型查询的核心价值是否在于关系链的深度遍历→ 图是否以时间为主轴持续追加→ 时序是否以相似程度而非是否相等为查询语义→ 向量。多数场景下答案会是多个模型的组合。7. 在 Easy Vibe 中的延伸学习掌握关系型地基后再读 数据库原理索引/事务/查询优化理解 B 树、ACID 与隔离级别——这是对比各类 NoSQL 模型的基准线向量模型是 AI 应用的入口建议接着学习 Embedding 与向量检索 与 RAG 架构再进入 RAG 检索增强生成实战教程 构建完整的检索生成系统数据治理环节可参考 数据治理与数据质量为多模型数据资产建立统一的标准与元数据管理完整知识地图见 附录总览可系统性回顾整个技术体系。一句话总结关系型是默认选项但绝非唯一选项。认清每种数据形态的固有特征把数据放进匹配的模型中才是数据建模的真正艺术。【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Easy Vibe 数据模型全景：文档/图/时序/向量——为什么你的数据不能全塞进 MySQL
Easy Vibe 数据模型全景文档/图/时序/向量——为什么你的数据不能全塞进 MySQL【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe本指南是 Easy Vibe 课程体系中「数据」附录的核心章节对应 docs/es-es/appendix/5-data/data-models.md各语言版本内容一致如 中文版。当你面对社交关系网、每秒百万条的传感器流水、或者 AI 需要理解的语义向量时关系型表格就会力不从心。读完本文你将掌握文档、图、时序、向量四种非关系型数据模型的适用场景、核心原理与选型方法并能在多模型混用的现代系统架构中为每种数据找到最合适的家。1. 超越关系型为什么需要其他数据模型关系型数据库MySQL、PostgreSQL用表 行 列组织数据适合结构固定、关系明确的业务数据。但现实世界的数据远不止这一种形态数据形态关系型的痛点更合适的模型用户画像字段不固定嵌套结构频繁ALTER TABLE大量 NULL 列文档模型社交网络朋友的朋友的朋友多层 JOIN 性能指数级下降图模型监控指标每秒百万条写入写入瓶颈历史数据膨胀时序模型AI 语义搜索意思相近的内容无法表达语义相似度向量模型::: info 核心观点 不是替代关系型而是补充。大多数系统的核心业务仍然跑在 MySQL/PostgreSQL 上但在特定场景引入专用数据模型能获得数量级的性能提升。 :::这一点在 Easy Vibe 的学习路线中与 数据库原理索引/事务/查询优化 互为表里数据库原理一章讲透关系型的地基表、主键、外键、B 树、ACID而本文则向上拓展——当单一关系型模型无法承载某些数据形态时如何选用专用模型。2. 文档模型Document2.1 文档模型概述文档模型将数据存储为JSON/BSON 文档每条记录是一个自包含的文档可以有不同的字段结构{ _id: user_1001, name: 张三, tags: [VIP, 活跃], address: { city: 北京, district: 朝阳区 }, orders: [ { id: o1, amount: 299 }, { id: o2, amount: 599 } ] }关键特点无 Schema 约束不需要预定义表结构字段随时增减嵌套结构地址、订单直接嵌在文档里一次读取即可获得全部数据避免了关系型中一次页面展示 多次 JOIN的麻烦水平扩展天然适合分片Sharding轻松应对海量数据。2.2 文档 vs 关系型对比维度关系型MySQL文档型MongoDB数据结构固定 SchemaALTER TABLE修改灵活 Schema随时加字段嵌套数据需要多表 JOIN直接嵌套在文档中跨记录关联JOIN 很强关联查询较弱适合场景结构稳定的业务数据结构多变的内容数据2.3 典型场景CMS 内容管理文章、评论、标签结构各异用户画像不同用户有不同的属性字段字段随业务增长不断演进商品目录手机有屏幕尺寸食品有保质期字段完全不同若强行建关系表会出现大量稀疏 NULL 列配置中心各服务的配置结构不统一。::: warning ⚠️ 常见误区 MongoDB 不需要设计数据结构 —— 错文档模型同样需要认真设计嵌套层级不宜过深频繁更新的子文档应该拆分为独立集合否则会产生更新放大与并发锁竞争问题。 :::3. 图模型Graph3.1 图模型概述图模型用节点Node和边Edge表达实体及其关系。每个节点是一个实体每条边是一个关系节点和边都可以携带属性(张三) --[关注]-- (李四) --[关注]-- (王五) | | --------[购买]---- (iPhone) --[购买]--3.2 图模型的杀手级能力多跳查询场景在社交网络中找朋友的朋友的朋友3 度人脉。关系型做法3 层 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 查询语言通过指针直接遍历关系多跳查询性能几乎不变MATCH (me)-[:FOLLOWS*1..3]-(target) WHERE me.name 张三 RETURN DISTINCT target.name两者的本质区别在于数据组织方式关系型把关系建模成外键列 运行时 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% 空间从上表可以提炼出时序数据库的四个核心设计取向追加式写入引擎面向高吞吐顺序写、TTL 生命周期管理自动淘汰冷数据、预聚合/连续查询把降采样下沉到存储层、列式压缩编码同一指标相邻时间点的值高度相似压缩比极高。4.3 典型场景服务器监控CPU、内存、磁盘每秒采集IoT 传感器温度、湿度、GPS 轨迹金融行情股票价格、交易量的秒级数据日志分析应用日志的时间线聚合。5. 向量模型Vector5.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% 相似这一模型正是 Easy Vibe 课程体系中 AI 方向的核心地基之一向量检索是 RAG 检索增强生成 与 Embedding 与向量检索 的技术底座。上图展示了向量模型在真实系统中的典型落地形态知识片段以文本 向量的形式存入向量数据库Vector DB用户提问触发 Retrieve 检索命中片段被注入 Augmented Context最终交由模型基于检索到的上下文作答——这正是 RAG 中先检索、再生成的核心闭环。5.2 向量搜索 vs 关键词搜索对比关键词搜索LIKE / 全文索引向量搜索搜索方式精确匹配字符串语义相似度匹配好吃的日料只能匹配包含日料的文本能找到寿司刺身居酒屋多语言需要分别处理跨语言语义理解多模态仅文本文本、图片、音频统一检索5.3 典型场景RAG检索增强生成为 LLM 提供相关知识片段缓解幻觉并实现知识实时更新语义搜索理解用户意图而非关键词以图搜图上传一张图找到视觉相似的图片推荐系统基于内容语义的相似推荐。::: tip 向量数据库的选择独立向量数据库Pinecone、Milvus、Weaviate —— 专注向量检索性能最优传统数据库扩展pgvectorPostgreSQL、Atlas Vector SearchMongoDB—— 减少架构复杂度让关系型与向量检索共存于同一存储内存向量库FAISS、Annoy —— 适合小规模、低延迟场景。 :::从工程落地角度选型时可以按规模与运维成本梯度决策小规模原型优先用 pgvector 这类扩展需要独立扩展与混合检索标量 向量时再引入 Milvus 等专用引擎对延迟极度敏感的场景才考虑 FAISS 这类纯内存索引。6. 选择数据模型的方法6.1 数据形态 → 模型 → 产品对照表你的数据长什么样推荐模型代表产品结构固定关系明确订单、用户关系型MySQL、PostgreSQL结构灵活嵌套层级多内容、配置文档型MongoDB、DynamoDB实体之间关系复杂需要多跳遍历图Neo4j、Amazon Neptune按时间顺序写入按时间范围查询时序InfluxDB、TimescaleDB非结构化数据需要语义相似度搜索向量Pinecone、Milvus、pgvector6.2 多模型混用现代系统的常态::: info 实战建议 现代系统通常是多模型混用核心业务用 PostgreSQL关系型用户行为日志用 InfluxDB时序AI 知识库用 Milvus pgvector向量推荐引擎用 Neo4j图。不要追求一个数据库解决所有问题而是让每种数据找到最合适的家。 :::多模型混用的判断顺序可以简化为三个问题数据是否写入后极少变化且需要精确关联→ 关系型结构是否随业务快速变化、需要嵌套表达→ 文档型查询的核心价值是否在于关系链的深度遍历→ 图是否以时间为主轴持续追加→ 时序是否以相似程度而非是否相等为查询语义→ 向量。多数场景下答案会是多个模型的组合。7. 在 Easy Vibe 中的延伸学习掌握关系型地基后再读 数据库原理索引/事务/查询优化理解 B 树、ACID 与隔离级别——这是对比各类 NoSQL 模型的基准线向量模型是 AI 应用的入口建议接着学习 Embedding 与向量检索 与 RAG 架构再进入 RAG 检索增强生成实战教程 构建完整的检索生成系统数据治理环节可参考 数据治理与数据质量为多模型数据资产建立统一的标准与元数据管理完整知识地图见 附录总览可系统性回顾整个技术体系。一句话总结关系型是默认选项但绝非唯一选项。认清每种数据形态的固有特征把数据放进匹配的模型中才是数据建模的真正艺术。【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考