feat: chapter 8

docs/grokking/chapter-8.md

@@ -163,3 +163,32 @@ streamVideo(api_dev_key, video_id, offset, codec, resolution)
 
 ![图8-2](/grokking/f8-2.png)
 
+## 8. 元数据分片  
+由于每天会有大量新视频产生，同时我们的读取负载非常高，因此我们需要将数据分布到多台机器上，以高效地执行读写操作。以下是几种分片策略的讨论：  
+
+**基于用户ID的分片：**  
+我们可以尝试将特定用户的所有数据存储在一台服务器上。在存储时，可以将用户ID传递给哈希函数，由其将该用户映射到某个数据库服务器，然后在该服务器上存储该用户视频的所有元数据。在查询某个用户的视频时，可以通过哈希函数定位保存该用户数据的服务器，然后从中读取数据。  
+然而，这种方法存在以下问题：  
+1. 如果某个用户变得非常受欢迎，存储该用户数据的服务器可能会因大量查询而成为性能瓶颈，从而影响整个服务的性能。  
+2. 随着时间推移，一些用户可能会存储大量视频，而其他用户的存储量较少，这使得维持用户数据的均匀分布变得极具挑战性。  
+
+为解决上述问题，可以通过重新分区/重新分布数据或采用**一致性哈希**在服务器之间平衡负载。  
+
+**基于视频ID的分片：**  
+我们可以使用哈希函数将每个视频ID映射到一个随机服务器，并在该服务器上存储对应视频的元数据。要查询某个用户的视频，需要查询所有服务器，每台服务器返回一组视频，随后由中心化服务器对这些结果进行聚合和排序，再返回给用户。这种方法解决了热门用户的问题，但却将问题转移到热门视频上。  
+
+为了进一步提升性能，可以在数据库服务器前引入缓存来存储热门视频。  
+
+
+## 9. 视频去重  
+随着大量用户上传海量视频数据，我们的服务需要处理广泛的重复视频问题。这些重复视频可能在纵横比或编码上有所不同，可能包含叠加内容或额外边框，或者只是较长原始视频的片段。重复视频会在以下方面产生影响：  
+1. **数据存储：** 存储同一视频的多份副本会浪费存储空间。  
+2. **缓存效率：** 重复视频会占用缓存空间，从而降低缓存的利用率。  
+3. **网络使用：** 重复视频会增加需要传输到网络缓存系统的数据量。  
+4. **能耗：** 更多的存储需求、低效的缓存和高网络流量会导致能源浪费。  
+
+对于最终用户，这些低效表现为搜索结果中出现重复内容、更长的视频启动时间以及中断的流媒体播放。  
+
+从服务的角度看，尽早进行去重是更合理的选择。在用户上传视频时进行去重处理比事后处理更高效。**实时去重**可以节省大量资源，例如用于编码、传输和存储重复视频的资源。  
+
+当用户开始上传视频时，服务可以运行视频匹配算法（例如[Block Matching](https://en.wikipedia.org/wiki/Block-matching_algorithm)、[Phase Correlation](https://en.wikipedia.org/wiki/Phase_correlation)等）来检测重复内容。如果发现该视频已有副本，我们可以选择中止上传并使用现有副本，或者继续上传并使用新上传的视频（若其质量更高）。如果新上传的视频是现有视频的一部分或反之，我们可以智能地将视频划分为更小的块，仅上传缺失的部分。