数据模型全景实战文档、图、时序与向量模型的选择与应用easy-vibe 数据篇【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址: https://gitcode.com/datawhalechina/easy-vibe导读本文以 easy-vibe 开源教程仓库中《数据模型全景》一文docs/en/appendix/5-data/data-models.md为核心骨架系统讲解为什么关系型数据库不是万能的以及文档模型、图模型、时序模型、向量模型四种专用数据模型各自解决什么问题、如何建模、何时选用。读完本文你将掌握按数据形态选存储的判断框架理解多跳查询、TTL 降采样、语义向量检索等核心机制并能参照仓库附录知识体系数据库原理、Embedding 与向量检索、RAG 检索增强生成构建一套多模型混用的完整数据架构。1. 超越关系型为什么我们需要其他数据模型关系型数据库MySQL、PostgreSQL用表 行 列组织数据擅长结构固定、关系明确的业务数据。但现实世界的数据形态远不止这一种。当数据变成社交关系网、每秒百万条的传感器流水、或者 AI 需要理解的语义向量时关系型表格就会力不从心。数据形态关系型的痛点更合适的模型用户画像字段不固定嵌套结构频繁 ALTER TABLE大量 NULL 列文档模型社交网络朋友的朋友的朋友多层 JOIN 性能指数级下降图模型监控指标每秒百万条写入写入瓶颈历史数据膨胀时序模型AI 语义搜索意思相近的内容无法表达语义相似度向量模型核心观点不是替代关系型而是补充。大多数系统的核心业务仍然跑在 MySQL/PostgreSQL 上但在特定场景引入专用数据模型能获得数量级的性能提升。这一判断与仓库附录中 数据库原理 的定位一脉相承关系型数据库解决的是结构化数据 高并发 复杂关联的通用问题而本文讨论的四种专用模型则是为特定数据形态量身定制的特种兵。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 很强关联查询较弱适合场景结构稳定的业务数据结构多变的内容数据注意取舍的核心嵌套带来读取效率却削弱了跨记录关联能力。当业务需要订单与用户强关联统计时关系型的外键 JOIN 仍然是更自然的选择可对比 数据库原理 中的 JOIN 多表查询示例。2.3 典型场景CMS 内容管理文章、评论、标签结构各异用户画像不同用户有不同的属性字段商品目录手机有屏幕尺寸食品有保质期字段完全不同配置中心各服务的配置结构不统一::: warning ⚠️ 常见误区 MongoDB 不需要设计数据结构 —— 错文档模型同样需要认真设计嵌套层级不宜过深过深会导致更新路径复杂、性能下降频繁更新的子文档应该拆分为独立集合避免每次更新都重写整个大文档。 :::3. 图模型Graph3.1 图模型概述图模型用节点Node和边Edge表达实体及其关系。每个节点是一个实体每条边是一个关系节点和边都可以携带属性(张三) --[关注]-- (李四) --[关注]-- (王五) | | --------[购买]---- (iPhone) --[购买]--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 张三 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% 相似关于 Embedding 的底层原理One-Hot 到稠密向量的演进、余弦相似度与欧氏距离、HNSW/IVF 等 ANN 索引算法仓库附录的 Embedding 与向量检索原理 一文给出了完整推导核心突破在于把语义相似变成空间距离近词向量满足king − man woman ≈ queen这类类比运算。5.2 向量搜索 vs 关键词搜索对比关键词搜索LIKE / 全文索引向量搜索搜索方式精确匹配字符串语义相似度匹配好吃的日料只能匹配包含日料的文本能找到寿司刺身居酒屋多语言需要分别处理跨语言语义理解多模态仅文本文本、图片、音频统一检索补充一点来自 数据库原理 的提醒关键词搜索中LIKE %日料%这类两侧通配查询会导致全表扫描、无法利用索引这正是向量搜索在语义与性能两个维度上都要优于朴素关键词匹配的原因之一。5.3 典型场景RAG检索增强生成为 LLM 提供相关知识片段完整链路见 RAG 一文语义搜索理解用户意图而非关键词以图搜图上传一张图找到视觉相似的图片推荐系统基于内容语义的相似推荐向量数据库的选择三层选型独立向量数据库Pinecone、Milvus、Weaviate —— 专注向量检索性能最优传统数据库扩展pgvectorPostgreSQL、Atlas Vector SearchMongoDB—— 减少架构复杂度复用既有基础设施内存向量库FAISS、Annoy —— 适合小规模、低延迟场景从 Embedding 与向量检索原理 的选型表可以进一步细化Chroma 适合本地开发与小项目Pinecone 是全托管云服务开箱即用Milvus 适合大规模生产环境pgvector 适合已经在用 PostgreSQL 的团队。6. 选择数据模型的方法决策指南你的数据长什么样推荐模型代表产品结构固定关系明确订单、用户关系型MySQL、PostgreSQL结构灵活嵌套层级多内容、配置文档型MongoDB、DynamoDB实体之间关系复杂需要多跳遍历图Neo4j、Amazon Neptune按时间顺序写入按时间范围查询时序InfluxDB、TimescaleDB非结构化数据需要语义相似度搜索向量Pinecone、Milvus、pgvector实战建议现代系统通常是多模型混用Polyglot Persistence。核心业务用 PostgreSQL关系型—— 订单、用户等强一致业务数据用户行为日志用 InfluxDB时序—— 行为埋点与指标埋点方案参考 数据追踪AI 知识库用 Milvus pgvector向量—— 为 RAG 提供语义检索能力推荐引擎用 Neo4j图—— 挖掘用户-商品-标签的关系网络不要追求一个数据库解决所有问题而是让每种数据找到最合适的家。7. 总结从选型到架构的关键认知回顾全文四条选型主线可以浓缩为四句话文档模型 用自包含文档换 Schema 灵活性与单次读取效率代价是跨记录关联能力弱嵌套层级要克制图模型 把关系存成指针让多跳遍历性能几乎恒定专治社交网络、知识图谱、反欺诈时序模型 以时间戳为主轴的写入与聚合优化配合 TTL 与降采样治理历史数据膨胀向量模型 用 Embedding 把语义变成空间距离配合 ANN 索引实现毫秒级语义检索是 RAG 类 AI 应用的地基。为什么选型比写 SQL 更重要关系型数据库擅长的是结构固定、关系明确的数据一旦数据形态偏离这个假设嵌套、多跳、时序、语义通用方案就会在性能或开发效率上付出数量级代价。正确的姿势是像上文的多模型混用示例那样让每种数据形态找到最合适的存储而不是强求one database to rule them all。如果你希望进一步深入仓库附录给出了完整的延伸路径数据库原理索引 B 树、事务 ACID、查询优化、Embedding 与向量检索相似度度量、ANN 索引、端到端检索管线、RAG 检索增强生成LLM 与知识库的落地结合配合本文的四种模型足以支撑从数据存储选型到 AI 应用落地的完整知识闭环。备注本文对应仓库文档以多语言发布如 中文版、英文版文末的DataModelsDemo /为文档中的交互式演示组件用于可视化呈现各模型的差异读者可在对应章节页面中直接体验。【免费下载链接】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导读本文以 easy-vibe 开源教程仓库中《数据模型全景》一文docs/en/appendix/5-data/data-models.md为核心骨架系统讲解为什么关系型数据库不是万能的以及文档模型、图模型、时序模型、向量模型四种专用数据模型各自解决什么问题、如何建模、何时选用。读完本文你将掌握按数据形态选存储的判断框架理解多跳查询、TTL 降采样、语义向量检索等核心机制并能参照仓库附录知识体系数据库原理、Embedding 与向量检索、RAG 检索增强生成构建一套多模型混用的完整数据架构。1. 超越关系型为什么我们需要其他数据模型关系型数据库MySQL、PostgreSQL用表 行 列组织数据擅长结构固定、关系明确的业务数据。但现实世界的数据形态远不止这一种。当数据变成社交关系网、每秒百万条的传感器流水、或者 AI 需要理解的语义向量时关系型表格就会力不从心。数据形态关系型的痛点更合适的模型用户画像字段不固定嵌套结构频繁 ALTER TABLE大量 NULL 列文档模型社交网络朋友的朋友的朋友多层 JOIN 性能指数级下降图模型监控指标每秒百万条写入写入瓶颈历史数据膨胀时序模型AI 语义搜索意思相近的内容无法表达语义相似度向量模型核心观点不是替代关系型而是补充。大多数系统的核心业务仍然跑在 MySQL/PostgreSQL 上但在特定场景引入专用数据模型能获得数量级的性能提升。这一判断与仓库附录中 数据库原理 的定位一脉相承关系型数据库解决的是结构化数据 高并发 复杂关联的通用问题而本文讨论的四种专用模型则是为特定数据形态量身定制的特种兵。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 很强关联查询较弱适合场景结构稳定的业务数据结构多变的内容数据注意取舍的核心嵌套带来读取效率却削弱了跨记录关联能力。当业务需要订单与用户强关联统计时关系型的外键 JOIN 仍然是更自然的选择可对比 数据库原理 中的 JOIN 多表查询示例。2.3 典型场景CMS 内容管理文章、评论、标签结构各异用户画像不同用户有不同的属性字段商品目录手机有屏幕尺寸食品有保质期字段完全不同配置中心各服务的配置结构不统一::: warning ⚠️ 常见误区 MongoDB 不需要设计数据结构 —— 错文档模型同样需要认真设计嵌套层级不宜过深过深会导致更新路径复杂、性能下降频繁更新的子文档应该拆分为独立集合避免每次更新都重写整个大文档。 :::3. 图模型Graph3.1 图模型概述图模型用节点Node和边Edge表达实体及其关系。每个节点是一个实体每条边是一个关系节点和边都可以携带属性(张三) --[关注]-- (李四) --[关注]-- (王五) | | --------[购买]---- (iPhone) --[购买]--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 张三 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% 相似关于 Embedding 的底层原理One-Hot 到稠密向量的演进、余弦相似度与欧氏距离、HNSW/IVF 等 ANN 索引算法仓库附录的 Embedding 与向量检索原理 一文给出了完整推导核心突破在于把语义相似变成空间距离近词向量满足king − man woman ≈ queen这类类比运算。5.2 向量搜索 vs 关键词搜索对比关键词搜索LIKE / 全文索引向量搜索搜索方式精确匹配字符串语义相似度匹配好吃的日料只能匹配包含日料的文本能找到寿司刺身居酒屋多语言需要分别处理跨语言语义理解多模态仅文本文本、图片、音频统一检索补充一点来自 数据库原理 的提醒关键词搜索中LIKE %日料%这类两侧通配查询会导致全表扫描、无法利用索引这正是向量搜索在语义与性能两个维度上都要优于朴素关键词匹配的原因之一。5.3 典型场景RAG检索增强生成为 LLM 提供相关知识片段完整链路见 RAG 一文语义搜索理解用户意图而非关键词以图搜图上传一张图找到视觉相似的图片推荐系统基于内容语义的相似推荐向量数据库的选择三层选型独立向量数据库Pinecone、Milvus、Weaviate —— 专注向量检索性能最优传统数据库扩展pgvectorPostgreSQL、Atlas Vector SearchMongoDB—— 减少架构复杂度复用既有基础设施内存向量库FAISS、Annoy —— 适合小规模、低延迟场景从 Embedding 与向量检索原理 的选型表可以进一步细化Chroma 适合本地开发与小项目Pinecone 是全托管云服务开箱即用Milvus 适合大规模生产环境pgvector 适合已经在用 PostgreSQL 的团队。6. 选择数据模型的方法决策指南你的数据长什么样推荐模型代表产品结构固定关系明确订单、用户关系型MySQL、PostgreSQL结构灵活嵌套层级多内容、配置文档型MongoDB、DynamoDB实体之间关系复杂需要多跳遍历图Neo4j、Amazon Neptune按时间顺序写入按时间范围查询时序InfluxDB、TimescaleDB非结构化数据需要语义相似度搜索向量Pinecone、Milvus、pgvector实战建议现代系统通常是多模型混用Polyglot Persistence。核心业务用 PostgreSQL关系型—— 订单、用户等强一致业务数据用户行为日志用 InfluxDB时序—— 行为埋点与指标埋点方案参考 数据追踪AI 知识库用 Milvus pgvector向量—— 为 RAG 提供语义检索能力推荐引擎用 Neo4j图—— 挖掘用户-商品-标签的关系网络不要追求一个数据库解决所有问题而是让每种数据找到最合适的家。7. 总结从选型到架构的关键认知回顾全文四条选型主线可以浓缩为四句话文档模型 用自包含文档换 Schema 灵活性与单次读取效率代价是跨记录关联能力弱嵌套层级要克制图模型 把关系存成指针让多跳遍历性能几乎恒定专治社交网络、知识图谱、反欺诈时序模型 以时间戳为主轴的写入与聚合优化配合 TTL 与降采样治理历史数据膨胀向量模型 用 Embedding 把语义变成空间距离配合 ANN 索引实现毫秒级语义检索是 RAG 类 AI 应用的地基。为什么选型比写 SQL 更重要关系型数据库擅长的是结构固定、关系明确的数据一旦数据形态偏离这个假设嵌套、多跳、时序、语义通用方案就会在性能或开发效率上付出数量级代价。正确的姿势是像上文的多模型混用示例那样让每种数据形态找到最合适的存储而不是强求one database to rule them all。如果你希望进一步深入仓库附录给出了完整的延伸路径数据库原理索引 B 树、事务 ACID、查询优化、Embedding 与向量检索相似度度量、ANN 索引、端到端检索管线、RAG 检索增强生成LLM 与知识库的落地结合配合本文的四种模型足以支撑从数据存储选型到 AI 应用落地的完整知识闭环。备注本文对应仓库文档以多语言发布如 中文版、英文版文末的DataModelsDemo /为文档中的交互式演示组件用于可视化呈现各模型的差异读者可在对应章节页面中直接体验。【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址: https://gitcode.com/datawhalechina/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考