拓冰网站定制 
easy-vibe 数据模型全景指南文档、图、时序与向量模型的选择与实践【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址: https://gitcode.com/datawhalechina/easy-vibe导读当数据从能塞进 Excel 表格的订单变成每秒百万条的传感器流水朋友的朋友的朋友这样的社交关系网以及需要 AI 理解语义相似度的向量时关系型数据库就会力不从心。本文以 easy-vibe 数据与存储附录中的《数据模型全景》为核心系统讲解文档、图、时序、向量四种非关系数据模型的建模思路、适用场景与代表产品并通过 MySQL 对照与可运行 SQL/Cypher 示例帮助你在实际项目中为不同形态的数据选对家。1. 超越关系型为什么需要其他数据模型关系型数据库MySQL、PostgreSQL用表 行 列组织数据适合结构固定、关系明确的业务数据。但现实世界的数据远不止这一种形态数据形态关系型的痛点更合适的模型用户画像字段不固定嵌套结构频繁ALTER TABLE大量 NULL 列文档模型社交网络朋友的朋友的朋友多层 JOIN 性能指数级下降图模型监控指标每秒百万条写入写入瓶颈历史数据膨胀时序模型AI 语义搜索意思相近的内容无法表达语义相似度向量模型核心观点引入这些模型不是要替代关系型而是补充。大多数系统的核心业务仍然跑在 MySQL/PostgreSQL 上但在特定场景引入专用数据模型能获得数量级的性能提升。easy-vibe 在 数据库基础 中详细讲解了关系型数据库的表、行、列、主键、索引与事务ACID本节正是沿着这条主线继续回答关系型之外还有什么。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 } ] }关键特点无 Schema 约束不需要预定义表结构字段随时增减——新业务字段上线时关系型需要ALTER TABLE而文档型直接写入即可嵌套结构地址、订单直接嵌在文档里一次读取即可拿到全部相关数据省去多表 JOIN水平扩展天然适合分片Sharding轻松应对海量数据。2.2 文档模型 vs 关系型对比维度关系型MySQL文档型MongoDB数据结构固定 SchemaALTER TABLE修改灵活 Schema随时加字段嵌套数据需要多表 JOIN直接嵌套在文档中跨记录关联JOIN 很强关联查询较弱适合场景结构稳定的业务数据结构多变的内容数据2.3 典型场景CMS 内容管理文章、评论、标签结构各异用户画像不同用户有不同的属性字段会员等级、兴趣标签、消费习惯各不相同商品目录手机有屏幕尺寸食品有保质期不同品类字段完全不同配置中心各服务的配置结构不统一用文档模型可避免为每种配置建一张表。⚠️常见误区MongoDB 不需要设计数据结构——错文档模型同样需要认真设计嵌套层级不宜过深过深会带来读取与更新的复杂度频繁更新的子文档应该拆分为独立集合避免整篇文档的写放大。3. 图模型Graph3.1 图模型概述图模型用节点Node和边Edge表达实体及其关系。每个节点是一个实体每条边是一个关系节点和边都可以携带属性(Jean) --[suit]-- (Marie) --[suit]-- (Pierre) | | --------[achète]---- (iPhone) --[achète]--在这个结构中关注suit与购买achète作为边直接连接实体关系本身就是一等公民查询关系时无需像关系型那样通过外键 JOIN 现场拼接。3.2 图模型的杀手级能力多跳查询场景在社交网络中找朋友的朋友的朋友。关系型做法3 层 JOINSELECT 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 Jean 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.1GB数据按时间持续追加、很少修改查询几乎总是某台设备在某段时间内的趋势这与关系型 OLTP 的随机读写模型完全不同。4.2 为什么不用 MySQL 存时序数据问题MySQL时序数据库InfluxDB写入速度万级/秒百万级/秒历史数据手动清理表越来越大自动过期策略TTL聚合查询GROUP BY慢内置降采样5 秒 → 1 分钟均值存储效率通用存储空间浪费列式压缩节省约 90% 空间这四项差距解释了为什么监控大盘、IoT 平台几乎都选择 InfluxDB、TimescaleDB 等专用时序引擎而不是在 MySQL 上强行建分区表。4.3 典型场景服务器监控CPU、内存、磁盘每秒采集IoT 传感器温度、湿度、GPS 轨迹金融行情股票价格、交易量的秒级数据日志分析应用日志的时间线聚合。5. 向量模型Vector5.1 向量模型概述向量模型将文本、图片、音频等非结构化数据通过Embedding 模型转换为高维数字向量然后通过计算向量之间的距离如余弦相似度来衡量语义相似度bon resto japonais → Embedding → [0.82, 0.15, 0.91, 0.33, ...] ↓ 余弦相似度 sushi maître Ginza → [0.80, 0.18, 0.89, ...] → 96% 相似 pizza italienne → [0.12, 0.85, 0.20, ...] → 31% 相似注意查询好吃的日料时向量模型能找到字面上完全不同但语义相近的寿司刺身居酒屋这正是关键词搜索做不到的。5.2 向量搜索 vs 关键词搜索对比关键词搜索LIKE / 全文索引向量搜索搜索方式精确匹配字符串语义相似度匹配好吃的日料只能匹配包含日料的文本能找到寿司刺身居酒屋多语言需要分别处理跨语言语义理解多模态仅文本文本、图片、音频统一检索从实现上看关键词搜索依赖倒排索引做字面匹配LIKE 甚至可能触发全表扫描这一点在 数据库基础 的索引章节有专门警告而向量搜索依赖 ANN近似最近邻索引在向量空间中快速召回候选。5.3 典型场景RAG检索增强生成为 LLM 提供相关知识片段——这是向量模型在 AI 应用中最常见的落地形态语义搜索理解用户意图而非关键词以图搜图上传一张图找到视觉相似的图片推荐系统基于内容语义的相似推荐。向量数据库的选择独立向量数据库Pinecone、Milvus、Weaviate——专注向量检索性能最优传统数据库扩展pgvectorPostgreSQL、Atlas Vector SearchMongoDB——减少架构复杂度在已有业务库上直接加向量能力内存向量库FAISS、Annoy——适合小规模、低延迟场景。6. 选择数据模型的方法你的数据长什么样推荐模型代表产品结构固定关系明确订单、用户关系型MySQL、PostgreSQL结构灵活嵌套层级多内容、配置文档型MongoDB、DynamoDB实体之间关系复杂需要多跳遍历图Neo4j、Amazon Neptune按时间顺序写入按时间范围查询时序InfluxDB、TimescaleDB非结构化数据需要语义相似度搜索向量Pinecone、Milvus、pgvector实战建议现代系统通常是多模型混用——核心业务用 PostgreSQL关系型订单、用户等强一致性数据用户行为日志用 InfluxDB时序埋点事件按时间海量追加AI 知识库用 Milvus pgvector向量支撑 RAG 检索推荐引擎用 Neo4j图利用关系网络做推荐。不要追求一个数据库解决所有问题而是让每种数据找到最合适的家。7. 在 easy-vibe 仓库中的学习脉络本篇文章所属的 easy-vibe 数据附录docs/fr-fr/appendix/5-data围绕数据全链路展开本页解决数据用什么模型存储而相邻章节解决数据从哪来、怎么分析、如何治理数据库基础关系型数据库的表、行、列、主键、外键、SQL、索引与事务ACID是理解为什么要超越关系型的起点数据埋点行为数据的采集与上报正是时序模型与行为日志的主要数据来源数据分析 与 数据可视化对存储下来的数据进行查询、聚合与呈现数据治理质量、规范与安全任何模型都绕不开的底线A/B 测试用数据验证产品决策的实验方法。此外本文原页面末尾挂载了DataModelsDemo /交互演示组件该组件在 docs/.vitepress/theme/index.js 中随 VitePress 主题注册用于以可视化方式展示四种模型的形态差异。读者可在本地运行 easy-vibe 文档站点后直接在对应页面上交互体验文档、图、时序、向量四种模型的结构对比将上文的理论表格转化为直观印象。一句话总结关系型不是终点而是起点——先按结构是否固定、关系是否深层、写入是否时序化、检索是否语义化四问判断数据形态再为每一种数据形态选择最合适的模型最终在真实系统中以多模型混用的方式各司其职。【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址: https://gitcode.com/datawhalechina/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 easy-vibe 数据模型全景指南：文档、图、时序与向量模型的选择与实践
easy-vibe 数据模型全景指南文档、图、时序与向量模型的选择与实践【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址: https://gitcode.com/datawhalechina/easy-vibe导读当数据从能塞进 Excel 表格的订单变成每秒百万条的传感器流水朋友的朋友的朋友这样的社交关系网以及需要 AI 理解语义相似度的向量时关系型数据库就会力不从心。本文以 easy-vibe 数据与存储附录中的《数据模型全景》为核心系统讲解文档、图、时序、向量四种非关系数据模型的建模思路、适用场景与代表产品并通过 MySQL 对照与可运行 SQL/Cypher 示例帮助你在实际项目中为不同形态的数据选对家。1. 超越关系型为什么需要其他数据模型关系型数据库MySQL、PostgreSQL用表 行 列组织数据适合结构固定、关系明确的业务数据。但现实世界的数据远不止这一种形态数据形态关系型的痛点更合适的模型用户画像字段不固定嵌套结构频繁ALTER TABLE大量 NULL 列文档模型社交网络朋友的朋友的朋友多层 JOIN 性能指数级下降图模型监控指标每秒百万条写入写入瓶颈历史数据膨胀时序模型AI 语义搜索意思相近的内容无法表达语义相似度向量模型核心观点引入这些模型不是要替代关系型而是补充。大多数系统的核心业务仍然跑在 MySQL/PostgreSQL 上但在特定场景引入专用数据模型能获得数量级的性能提升。easy-vibe 在 数据库基础 中详细讲解了关系型数据库的表、行、列、主键、索引与事务ACID本节正是沿着这条主线继续回答关系型之外还有什么。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 } ] }关键特点无 Schema 约束不需要预定义表结构字段随时增减——新业务字段上线时关系型需要ALTER TABLE而文档型直接写入即可嵌套结构地址、订单直接嵌在文档里一次读取即可拿到全部相关数据省去多表 JOIN水平扩展天然适合分片Sharding轻松应对海量数据。2.2 文档模型 vs 关系型对比维度关系型MySQL文档型MongoDB数据结构固定 SchemaALTER TABLE修改灵活 Schema随时加字段嵌套数据需要多表 JOIN直接嵌套在文档中跨记录关联JOIN 很强关联查询较弱适合场景结构稳定的业务数据结构多变的内容数据2.3 典型场景CMS 内容管理文章、评论、标签结构各异用户画像不同用户有不同的属性字段会员等级、兴趣标签、消费习惯各不相同商品目录手机有屏幕尺寸食品有保质期不同品类字段完全不同配置中心各服务的配置结构不统一用文档模型可避免为每种配置建一张表。⚠️常见误区MongoDB 不需要设计数据结构——错文档模型同样需要认真设计嵌套层级不宜过深过深会带来读取与更新的复杂度频繁更新的子文档应该拆分为独立集合避免整篇文档的写放大。3. 图模型Graph3.1 图模型概述图模型用节点Node和边Edge表达实体及其关系。每个节点是一个实体每条边是一个关系节点和边都可以携带属性(Jean) --[suit]-- (Marie) --[suit]-- (Pierre) | | --------[achète]---- (iPhone) --[achète]--在这个结构中关注suit与购买achète作为边直接连接实体关系本身就是一等公民查询关系时无需像关系型那样通过外键 JOIN 现场拼接。3.2 图模型的杀手级能力多跳查询场景在社交网络中找朋友的朋友的朋友。关系型做法3 层 JOINSELECT 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 Jean 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.1GB数据按时间持续追加、很少修改查询几乎总是某台设备在某段时间内的趋势这与关系型 OLTP 的随机读写模型完全不同。4.2 为什么不用 MySQL 存时序数据问题MySQL时序数据库InfluxDB写入速度万级/秒百万级/秒历史数据手动清理表越来越大自动过期策略TTL聚合查询GROUP BY慢内置降采样5 秒 → 1 分钟均值存储效率通用存储空间浪费列式压缩节省约 90% 空间这四项差距解释了为什么监控大盘、IoT 平台几乎都选择 InfluxDB、TimescaleDB 等专用时序引擎而不是在 MySQL 上强行建分区表。4.3 典型场景服务器监控CPU、内存、磁盘每秒采集IoT 传感器温度、湿度、GPS 轨迹金融行情股票价格、交易量的秒级数据日志分析应用日志的时间线聚合。5. 向量模型Vector5.1 向量模型概述向量模型将文本、图片、音频等非结构化数据通过Embedding 模型转换为高维数字向量然后通过计算向量之间的距离如余弦相似度来衡量语义相似度bon resto japonais → Embedding → [0.82, 0.15, 0.91, 0.33, ...] ↓ 余弦相似度 sushi maître Ginza → [0.80, 0.18, 0.89, ...] → 96% 相似 pizza italienne → [0.12, 0.85, 0.20, ...] → 31% 相似注意查询好吃的日料时向量模型能找到字面上完全不同但语义相近的寿司刺身居酒屋这正是关键词搜索做不到的。5.2 向量搜索 vs 关键词搜索对比关键词搜索LIKE / 全文索引向量搜索搜索方式精确匹配字符串语义相似度匹配好吃的日料只能匹配包含日料的文本能找到寿司刺身居酒屋多语言需要分别处理跨语言语义理解多模态仅文本文本、图片、音频统一检索从实现上看关键词搜索依赖倒排索引做字面匹配LIKE 甚至可能触发全表扫描这一点在 数据库基础 的索引章节有专门警告而向量搜索依赖 ANN近似最近邻索引在向量空间中快速召回候选。5.3 典型场景RAG检索增强生成为 LLM 提供相关知识片段——这是向量模型在 AI 应用中最常见的落地形态语义搜索理解用户意图而非关键词以图搜图上传一张图找到视觉相似的图片推荐系统基于内容语义的相似推荐。向量数据库的选择独立向量数据库Pinecone、Milvus、Weaviate——专注向量检索性能最优传统数据库扩展pgvectorPostgreSQL、Atlas Vector SearchMongoDB——减少架构复杂度在已有业务库上直接加向量能力内存向量库FAISS、Annoy——适合小规模、低延迟场景。6. 选择数据模型的方法你的数据长什么样推荐模型代表产品结构固定关系明确订单、用户关系型MySQL、PostgreSQL结构灵活嵌套层级多内容、配置文档型MongoDB、DynamoDB实体之间关系复杂需要多跳遍历图Neo4j、Amazon Neptune按时间顺序写入按时间范围查询时序InfluxDB、TimescaleDB非结构化数据需要语义相似度搜索向量Pinecone、Milvus、pgvector实战建议现代系统通常是多模型混用——核心业务用 PostgreSQL关系型订单、用户等强一致性数据用户行为日志用 InfluxDB时序埋点事件按时间海量追加AI 知识库用 Milvus pgvector向量支撑 RAG 检索推荐引擎用 Neo4j图利用关系网络做推荐。不要追求一个数据库解决所有问题而是让每种数据找到最合适的家。7. 在 easy-vibe 仓库中的学习脉络本篇文章所属的 easy-vibe 数据附录docs/fr-fr/appendix/5-data围绕数据全链路展开本页解决数据用什么模型存储而相邻章节解决数据从哪来、怎么分析、如何治理数据库基础关系型数据库的表、行、列、主键、外键、SQL、索引与事务ACID是理解为什么要超越关系型的起点数据埋点行为数据的采集与上报正是时序模型与行为日志的主要数据来源数据分析 与 数据可视化对存储下来的数据进行查询、聚合与呈现数据治理质量、规范与安全任何模型都绕不开的底线A/B 测试用数据验证产品决策的实验方法。此外本文原页面末尾挂载了DataModelsDemo /交互演示组件该组件在 docs/.vitepress/theme/index.js 中随 VitePress 主题注册用于以可视化方式展示四种模型的形态差异。读者可在本地运行 easy-vibe 文档站点后直接在对应页面上交互体验文档、图、时序、向量四种模型的结构对比将上文的理论表格转化为直观印象。一句话总结关系型不是终点而是起点——先按结构是否固定、关系是否深层、写入是否时序化、检索是否语义化四问判断数据形态再为每一种数据形态选择最合适的模型最终在真实系统中以多模型混用的方式各司其职。【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址: https://gitcode.com/datawhalechina/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考