feat: chapter 8

docs/grokking/chapter-8.md

@@ -107,3 +107,59 @@ streamVideo(api_dev_key, video_id, offset, codec, resolution)
 6. **视频元数据存储**：一个元数据库，用于存储关于视频的所有信息，如标题、系统中的文件路径、上传用户、总观看次数、点赞、点踩等。同时，也用于存储所有视频评论。
 
 ![图8-1](/grokking/f8-1.png)
+
+## 6. 数据库模式
+
+**视频元数据存储 - MySQL**  
+视频的元数据可以存储在SQL数据库中，需要为每个视频存储以下信息：  
+- `VideoID`：视频唯一标识符  
+- `Title`：视频标题  
+- `Description`：视频描述  
+- `Size`：视频文件大小  
+- `Thumbnail`：缩略图路径  
+- `Uploader/User`：上传者/用户  
+- `Total number of likes`：总点赞数  
+- `Total number of dislikes`：总点踩数  
+- `Total number of views`：总观看次数  
+
+每条视频评论需要存储以下信息：  
+- `CommentID`：评论唯一标识符  
+- `VideoID`：关联的视频标识符  
+- `UserID`：发表评论的用户标识符  
+- `Comment`：评论内容  
+- `TimeOfCreation`：评论创建时间  
+
+**用户数据存储 - MySQL**  
+需要存储以下用户信息：  
+- `UserID`：用户唯一标识符  
+- `Name`：用户名  
+- `Email`：电子邮件  
+- `Address`：地址  
+- `Age`：年龄  
+- `Registration details`：注册信息等  
+
+## 7. 详细组件设计
+
+该服务以读操作为主，因此我们将专注于构建一个能够快速检索视频的系统。预计读写比为200:1，这意味着每上传一个视频，会有200次视频观看。  
+
+**视频存储在哪里？**  
+视频可以存储在分布式文件存储系统中，例如 HDFS 或 GlusterFS。  
+
+**如何高效管理读流量？**  
+需要将读流量与写流量分离。由于每个视频会有多份副本，可以将读流量分布到不同的服务器上。对于元数据，可以使用主从配置，写操作会首先写入主节点，然后同步到所有从节点。这种配置可能导致数据短暂的不一致，例如，当新增视频时，其元数据会先插入主节点，在同步到从节点之前，从节点无法看到该数据，因此会向用户返回过时结果。然而，这种不一致性是可以接受的，因为它持续时间很短，用户将在几毫秒后看到新视频。  
+
+**缩略图存储在哪里？**  
+缩略图数量远多于视频。如果假设每个视频有五张缩略图，则需要一个非常高效的存储系统来处理巨大的读流量。在决定使用哪种存储系统存储缩略图之前，需要考虑以下两点：  
+1. 缩略图是小文件，每个文件最大约为 5KB。  
+2. 缩略图的读流量远高于视频。用户一次只观看一个视频，但可能会查看包含其他视频的 20 张缩略图的页面。  
+
+如果将所有缩略图存储在磁盘上，由于文件数量庞大，读取这些文件需要频繁进行磁盘寻道操作，这是非常低效的，会导致更高的延迟。  
+
+Bigtable 是一个合理的选择，因为它将多个文件合并为一个块存储在磁盘上，在读取少量数据时非常高效。这两个特点正好满足我们的服务需求。将热门缩略图缓存起来也能帮助减少延迟。由于缩略图文件体积较小，可以轻松在内存中缓存大量此类文件。  
+
+**视频上传**：由于视频可能非常大，如果上传过程中连接中断，系统应支持从断点继续上传。  
+
+**视频编码**：新上传的视频会存储在服务器上，同时添加一个新任务到处理队列，将视频编码为多种格式。编码完成后，上传者会收到通知，视频即可用于观看或分享。
+
+![图8-2](/grokking/f8-2.png)
+