diff --git a/docs/.vitepress/theme/components/appendix/data/DataModelsDemo.vue b/docs/.vitepress/theme/components/appendix/data/DataModelsDemo.vue index 6301dd4..d95105d 100644 --- a/docs/.vitepress/theme/components/appendix/data/DataModelsDemo.vue +++ b/docs/.vitepress/theme/components/appendix/data/DataModelsDemo.vue @@ -200,3 +200,314 @@ const vecResults = [ { text: '意大利手工披萨 — 窑烤玛格丽特', score: 0.31 } ] + + diff --git a/docs/zh-cn/appendix/5-data/data-models.md b/docs/zh-cn/appendix/5-data/data-models.md index 18d99e3..5b80863 100644 --- a/docs/zh-cn/appendix/5-data/data-models.md +++ b/docs/zh-cn/appendix/5-data/data-models.md @@ -1,114 +1,203 @@ -# 数据模型：设计的强健骨架 +# 数据模型全景（文档 / 图 / 时序 / 向量） ::: tip 🎯 核心问题 -**如果房子没有蓝图，那盖到一半该怎么走线和装门呢？** -当我们构建一个涉及百万用户和千万订单的电商应用时：用户的地址、订单号、支付状态该如果高效摆放？如果今天加了个折扣功能，明天又要发优惠券该怎么扩展？本章带你重回设计的“地基”，理清这些表该怎么长出最强健的骨架：**数据模型设计 (Data Modeling)**。 +**为什么不能把所有数据都塞进 MySQL 的表格里？** 当你的数据是社交关系网、每秒百万条的传感器流水、或者 AI 需要理解的语义向量时，关系型表格就力不从心了。不同的数据形态，需要不同的建模方式。 ::: --- -## 0. 先问一个问题：你有没有经历过这些噩梦？ +## 1. 关系型之外：为什么需要其他数据模型？ -在一个软件项目最初狂欢般的冲刺期，很多人会用最粗暴的方式写下他们的结构。 +关系型数据库（MySQL、PostgreSQL）用"表 + 行 + 列"组织数据，适合结构固定、关系明确的业务数据。但现实世界的数据远不止这一种形态： -```text -users 表： -| id | name | address | order_1 | order_1_amount | order_2 | order_2_amount | ... | +| 数据形态 | 关系型的痛点 | 更合适的模型 | +|----------|-------------|-------------| +| 用户画像（字段不固定，嵌套结构） | 频繁 ALTER TABLE，大量 NULL 列 | **文档模型** | +| 社交网络（朋友的朋友的朋友） | 多层 JOIN 性能指数级下降 | **图模型** | +| 监控指标（每秒百万条写入） | 写入瓶颈，历史数据膨胀 | **时序模型** | +| AI 语义搜索（"意思相近"的内容） | 无法表达语义相似度 | **向量模型** | + +::: info 💡 核心观点 +不是"替代"关系型，而是"补充"。大多数系统的核心业务仍然跑在 MySQL/PostgreSQL 上，但在特定场景引入专用数据模型，能获得数量级的性能提升。 +::: + +--- + +## 2. 文档模型（Document） + +### 2.1 什么是文档模型？ + +文档模型将数据存储为 **JSON/BSON 文档**，每条记录是一个自包含的文档，可以有不同的字段结构。 + +```json +{ + "_id": "user_1001", + "name": "张三", + "tags": ["VIP", "活跃"], + "address": { "city": "北京", "district": "朝阳区" }, + "orders": [ + { "id": "o1", "amount": 299 }, + { "id": "o2", "amount": 599 } + ] +} ``` -这看起来非常省事对吧？直接把这辈子有关张三的一切统统塞到他的这行里！ -但过了三个月，老板满怀希冀地找你说： -“咱们需要给买了三次以上的大客户发红包。” +**关键特点：** +- **无 Schema 约束**：不需要预定义表结构，字段随时增减 +- **嵌套结构**：地址、订单直接嵌在文档里，一次读取全部数据 +- **水平扩展**：天然适合分片（Sharding），轻松应对海量数据 -这下你直接傻眼了：这表不仅已经蔓延出一百多个 `order_n` 的臃肿字段，而且每一次为了查询订单，系统都要横跨几千条记录的一大长串烂摊子进行全盘扫除。 -这，就是没有良好**数据模型（Data Model）**直接硬造的典型**灾难和噩梦**。 +### 2.2 文档 vs 关系型 + +| 对比维度 | 关系型（MySQL） | 文档型（MongoDB） | +|----------|----------------|------------------| +| 数据结构 | 固定 Schema，ALTER TABLE 修改 | 灵活 Schema，随时加字段 | +| 嵌套数据 | 需要多表 JOIN | 直接嵌套在文档中 | +| 跨记录关联 | JOIN 很强 | 关联查询较弱 | +| 适合场景 | 结构稳定的业务数据 | 结构多变的内容数据 | + +### 2.3 典型场景 + +- **CMS 内容管理**：文章、评论、标签结构各异 +- **用户画像**：不同用户有不同的属性字段 +- **商品目录**：手机有"屏幕尺寸"，食品有"保质期"，字段完全不同 +- **配置中心**：各服务的配置结构不统一 + +::: warning ⚠️ 常见误区 +"MongoDB 不需要设计数据结构" —— 错！文档模型同样需要认真设计：嵌套层级不宜过深，频繁更新的子文档应该拆分为独立集合。 +::: --- -## 1. 实体与关系：万物皆有连接 +## 3. 图模型（Graph） -我们要建立一个清晰的秩序世界，在这个世界里，首先得有基本的主角和配角：我们称他们为**“实体(Entities)”**。 -它们就是现实世界被抽象到计算机中的那些主要对象。比如：用户、订单、商品。 +### 3.1 什么是图模型？ -紧接着最重要的部分来了——如何把这些零散的东西连接起来？ -你总不能让这些主角像孤岛一样吧？张三买了一部手机，这中间发生了一个奇妙的桥梁，这就是**"关系(Relationships)"**。 +图模型用 **节点（Node）** 和 **边（Edge）** 表达实体及其关系。每个节点是一个实体，每条边是一个关系，节点和边都可以携带属性。 -这套把实体及其关系用精美的符号画出来的世界地图，被称为 **ER 图（Entity-Relationship Diagram）**。 +``` +(张三) --[关注]--> (李四) --[关注]--> (王五) + | | + +--------[购买]----> (iPhone) <--[购买]--+ +``` - +### 3.2 图模型的杀手级能力：多跳查询 -### 1.1 世界上只有三种最基本的连接 +**场景**：在社交网络中找"朋友的朋友的朋友" -当我们把镜头死死盯在任意两个实体之间时，你会发现所有的连接无外乎可以提纯为下面三种形式： +关系型做法（3 层 JOIN）： +```sql +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 查询语言）： +```cypher +MATCH (me)-[:FOLLOWS*1..3]->(target) +WHERE me.name = '张三' +RETURN DISTINCT target.name +``` -- **一对一 (One-to-One, 1:1)**： - 这是非常罕见和亲密的。比如一个中国人唯一对应一张身份证。或者在系统里，一个账号唯一的绝密隐私档案。 -- **一对多 (One-to-Many, 1:N)**： - 这是我们构建系统打交道最多的一种形态。一个作者能写出几百篇文章，但这几百篇文章的创作者只能是这一个特定的作者。此时在表中增加的外键（FK）就像个锚点，把多的一方牢牢锚向了一的一方。 -- **多对多 (Many-to-Many, M:N)**： - 这就极其复杂了。一个学生能选五门不同的课，一门课可能坐着五十个不同的学生。想要理顺这个乱作一团的毛线团，我们就得硬生生塞进一张中间表（中间人）：比如“选课记录表”。 +关系型每多一跳，就多一次 JOIN，性能指数级下降。图数据库通过指针直接遍历关系，多跳查询性能几乎不变。 + +### 3.3 典型场景 + +- **社交网络**：好友推荐、共同关注、影响力传播 +- **知识图谱**：实体关系推理（"谁是谁的老师的学生"） +- **欺诈检测**：发现资金环路、关联账户网络 +- **推荐系统**：基于用户-商品-标签的关系图推荐 --- -## 2. 范式理论：从混乱到干净利落的切分 +## 4. 时序模型（Time-Series） -如果关系确定了，那我们就在表里面无限塞字段吧？ -绝不！在长达数十年的计算机演进中，顶级的数据库专家们制定了一个近乎严苛的出厂规范，用来防止表中出现垃圾一般的冗余或者逻辑漏洞，这套铁律就叫——**数据库范式 (Normalization)**。 +### 4.1 什么是时序模型？ - +时序模型以 **时间戳** 为主轴，专门优化"按时间顺序写入、按时间范围查询"的场景。 -- **第一范式 (1NF) ：不要大杂烩！** - 你不能在一个字段里塞进去“张三，北京，25岁”。每一列都必须劈到底、拆到最细的原子级别。 -- **第二范式 (2NF) ：消除附庸者的脚踏两只船** - 当主键是两个字段联合组成时，绝对不允许有的杂兵字段只去巴结其中一半的主键而跟另外一半毫无关联。每一列都得完全依附于整体的联合主导。 -- **第三范式 (3NF) ：不要越级传递依赖** - 这是至高原则。既然你是依附于学号的个人信息，那你就好好当附庸，不能再出现“学号决定学院编号，而学院编号又能决定学院电话”的荒谬级联。 +``` +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 +``` -严苛遵循到 3NF，你的数据将呈现出令人如痴如醉的干净：**没有任何一句废话重复两遍，每次修改信息绝不会拖泥带水！** +### 4.2 为什么不用 MySQL 存时序数据？ + +| 问题 | MySQL | 时序数据库（InfluxDB） | +|------|-------|----------------------| +| 写入速度 | 万级/秒 | **百万级/秒** | +| 历史数据 | 手动清理，表越来越大 | **自动过期策略**（TTL） | +| 聚合查询 | GROUP BY 慢 | **内置降采样**（5 秒 → 1 分钟均值） | +| 存储效率 | 通用存储，空间浪费 | **列式压缩**，节省 90% 空间 | + +### 4.3 典型场景 + +- **服务器监控**：CPU、内存、磁盘每秒采集 +- **IoT 传感器**：温度、湿度、GPS 轨迹 +- **金融行情**：股票价格、交易量的秒级数据 +- **日志分析**：应用日志的时间线聚合 --- -## 3. 反范式化：在刀尖上跳舞的设计哲学 +## 5. 向量模型（Vector） -等等，既然范式这么严谨完美。难道所有大厂、千万级并发的电商真的就在 3NF 的象牙塔里搭建一切吗？ +### 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% 相似 +``` -假设你想展现一个带商品名字和买家名字的最终订单页面。按照 3NF： -“天呐，我需要在一毫秒内把 订单表、用户表、商品表、库存表 进行足足三次的巨大内部 JOIN (狂暴连接计算) 才能凑齐这十几个字段去页面呈现！” -由于巨大的服务器开销，高并发下数据库瞬间融化。 +### 5.2 向量搜索 vs 关键词搜索 -所以，在极端讲究速度的现代互联网中，我们往往会采取一种逆天之举：**故意破坏范式（Denormalization），空间换时间**。 -通过在订单表里刻意“冗余”了一份本来只该出现在用户表里的买家姓名，虽然占据了一点点磁盘，但这换来了查询时雷霆般惊人的单表吞吐力。 +| 对比 | 关键词搜索（LIKE / 全文索引） | 向量搜索 | +|------|---------------------------|---------| +| 搜索方式 | 精确匹配字符串 | 语义相似度匹配 | +| "好吃的日料" | 只能匹配包含"日料"的文本 | 能找到"寿司""刺身""居酒屋" | +| 多语言 | 需要分别处理 | 跨语言语义理解 | +| 多模态 | 仅文本 | 文本、图片、音频统一检索 | -这就是架构师在系统设计时那最精妙的取舍。 +### 5.3 典型场景 + +- **RAG（检索增强生成）**：为 LLM 提供相关知识片段 +- **语义搜索**：理解用户意图而非关键词 +- **以图搜图**：上传一张图，找到视觉相似的图片 +- **推荐系统**：基于内容语义的相似推荐 + +::: tip 💡 向量数据库的选择 +- **独立向量数据库**：Pinecone、Milvus、Weaviate —— 专注向量检索，性能最优 +- **传统数据库扩展**：pgvector（PostgreSQL）、Atlas Vector Search（MongoDB）—— 减少架构复杂度 +- **内存向量库**：FAISS、Annoy —— 适合小规模、低延迟场景 +::: --- -## 4. 全景实战：拆解电商系统 +## 6. 选型决策：如何选择数据模型？ -理解了以上所有原理，不妨让我们戴上前人的结晶。看一看在现代的电商和社交系统背后，是如何用这些一块块小积木，搭建起了扛得住双十一每秒几十万张海量洪峰订单的巨大钢铁森林。 +| 你的数据长什么样？ | 推荐模型 | 代表产品 | +|-------------------|---------|---------| +| 结构固定，关系明确（订单、用户） | 关系型 | MySQL、PostgreSQL | +| 结构灵活，嵌套层级多（内容、配置） | 文档型 | MongoDB、DynamoDB | +| 实体之间关系复杂，需要多跳遍历 | 图 | Neo4j、Amazon Neptune | +| 按时间顺序写入，按时间范围查询 | 时序 | InfluxDB、TimescaleDB | +| 非结构化数据，需要语义相似度搜索 | 向量 | Pinecone、Milvus、pgvector | - +::: info 🎯 实战建议 +现代系统通常是**多模型混用**： +- **核心业务**用 PostgreSQL（关系型） +- **用户行为日志**用 InfluxDB（时序） +- **AI 知识库**用 Milvus + pgvector（向量） +- **推荐引擎**用 Neo4j（图） -### 4.1 直面反模式设计 +不要追求"一个数据库解决所有问题"，而是让每种数据找到最合适的家。 +::: -当然，在构建这些巨无霸的过程中。无数的新手总会栽进那些前辈踩烂了的巨幅陷阱中。当你在表里面用逗号狂拼接字段（所谓的 JSON 万金油），或者在一张巨表里面加到第 150 个字段时。 - -你必须警惕了，这是一个极度不详的征兆。 - - - -## 5. 总结：用数据模型构建千秋地基 - -万丈高楼平地起。我们在任何花里胡哨的前端页面、后端微服务设计之前。最朴素的那张在草稿纸上被反复涂改的实体关系图，往往决定了这个团队能不能挺过第三年的需求大爆炸。 - -- **用理清从属和多维关系（1:1, 1:N, M:N）的基座，框定业务的脉络。** -- **用严酷的三大范式的修剪，剃除无端的数据黑洞与混乱堆砌。** -- **用大巧不工的反范式策略平衡，抵御性能瓶颈这头怪兽。** - -所以，在下次打开代码编辑器兴奋地敲击之前，先买一张大大的白板。跟你的伙伴讨论出你们心中最干净的那个模型。因为只有拥有了强健的数据骨架，这头怪兽才能放肆奔跑。 +