talentyiyy的专栏

项目做到这个位置，总结下前面碰到的一些问题及debug的一些技巧思路是必须的。因为有的问题本身比较诡异，不是马上就定位出来了。这其中不仅与你自己写的code 有关系，也与组件的运作流程及组件间的相互配合有关系。当然有的组件，如果你没有很深入的使用他，不知道其中的坑，但是这并不影响debug 的思路。我们的目标很简单，要的不是这个问题答案是什么，而是遇到这个问题是如何解决的，需要记录的是过程方法，当然结果也是重要的，为你以后的软件职业生涯，说大点其实是一种思维模式奠定一些无形的基础。

对本系统而言，核心就三个：1）有序管理所有video资源，并进行封装 2）有序管理所有连接资源，包括 vector db connection，cache connection，filesystem connection，websocket connection，3）封装核心服务，包括video资源预处理，query service，analysis service等。

一方面，你不能保证不同用户上传的相同video，他们的video name 具有一致性。但这个唯一性时假的，我们只能从video 内容上来保证video 的唯一性，并通过 uuid 等手段来对上传的video name 进行二次转换，保证video name 的唯一性。但是这里有个问题，为了效率，你不可能将一个长达几十分钟或几小时的video用MD5进行计算，因为这本身就是耗时的，如果你这样做了，等于缓存的时间也没节约多少，相当于你变相需要打开video 本身，虽然解析过程可能不需要那么繁琐。

中我们处理了外部并发的一致性问题，主要是反馈在多用户搜索的过程中，解决出现的查询混乱问题，从本质上来说，如果你只是想想，问题可能就不应该出现，因为web socket 在进行 b/s 交互时，你稍微懂点原理，都应该明白通道是独立的，数据不应该发生混乱的现象。但是发生前，如果query 比较多，将会使得 remove cache 的动作滞后，时间一长，造成系统资源在某时刻的飙升，这是你无法接受的。当cache 在此过程中发生删除时，query 单例，如果存在，稳住acquire ，不删除。

但是这里注意，一旦搜索完成，你应该释放这个数组中的这个state数据，因为它已经没有用了，你如果一直不放，就会有问题，越存越多，造成memory浪费。作为一个剖析与完整实现商用视频搜索的系统，为了讲清楚里面所有的实现细节及蕴含的编程思想，及发现的问题与如何解决，每一节都只会有一个重点，我不太喜欢贪多，一篇文章彻底讲清楚一个问题就好，关键是要能完全明白其中的运作及处理原理，方法及如何落地实现。

所以在前端显示搜索进度是有必要的，特别是在server硬件资源相对不足，又或者视频存储量很大的时候，让用户了解到此时搜索的进度，告诉他系统并不是没结果返回，而是正在处理事非常有必要的。除了告诉他总进度，最好还能告诉他此时系统为他的查询在做什么事情，让他清楚的知道：1）哪怕结果没有立即返回，但是系统不是无响应。2）系统正在做的事情 3）根据进度条看到可能还要多少时间完成query。今天我们聚焦这个问题，看看如何一步一步落地

搜索阶段的cache技术，其实本质上vector db 外围来做已经不太合适，原因细想下，也比较简单，在视频搜索中，搜索的内容是以 向量化 内容为主，说直白点就是高维数组。这种方法可以显著减少加载完成后首次查询/搜索的延迟，但会增加数据加载过程中的磁盘I/O和CPU使用率，因为需要同时处理数据的加载和缓存的更新。不同索引类型占用的空间大小不同，例如 IVFLAT 索引的数据量基本等同于原始向量的总数据量，而 SQ8 索引的数据量大约是原始向量总数据量的 30% 左右。去详细理解，里面我说的比较清楚了。

实际上任何系统UI的优化分为两部分，一部分是与后端上层service无关的部分，即仅仅是UI的优化，另一部分是使用的优化，实际上又分为两部分，一部分是根据户习惯的改进优化，这部分可能和后台service有关系，也可能与后台没有关系，我们假定与后台service相关的部分，放在这一部分描述，而与后台无关的纯UI改进放在前一部分。另外一部分就是UI 结构功能的优化，往往会讲操作化繁为简，毕竟大家都是追求 ‘Simple is beauty’ 准则哪里都适用。

已经设计并实现了基于视频的查询，这种前期较完善的设计机制结合了向量数据库本身的特点与系统的并发性，同时兼顾了并在向量collection设计阶段尽量减少冗余，达到标准的范式设计的目标。但作为一款完整商用落地的视频搜索系统，可能还需要借助语义文本一起辅助完成最终的搜索。在视频内容搜索的基础上加入视频描述的搜索，并实现最终的排序输出才能是一个完美的视频搜索。

作为商用落地系统，我们当然希望搜索视频的关联度或者说准确性与我们希望查询的视频相关度越高越好。为此，除了在query 层面上优化，我们还需要注重我们的输入。那么如何才能更好的对视频进行预处理以及为更好的查询奠定基础，是我们需要优化的一个重要方向。这里涉及到视频特征的提取以及视频比对的算法。本节主要聚焦在优化视频的特征提取上，分析下这部分的内容。

在设计的时候，这一点也是不可忽视的，我们好不容易构造了一个商用搜索视频系统，不能在根据path 寻找加载视频上出问题，当然视频的备份与容灾也是一个健壮的商用系统必须要考虑的范畴。还有一点就是数据的分权分域问题，也还是商用系统必须考虑的，不同权限的人能访问到的数据权限是不一样的。另外，我们可以设置 video bucket 的权限，以及bucket 的大小，这为以后视频数据的分权分域奠定了较好的基础，这也是 一般 os 的文件体系架构难以企及的地方。上面一个千万不要删除，那是milvus 的log数据。

比如在定义视频相似度时，如何衡量多个视频之间的相似度？如何能通过语义拆分及内容，对视频进行综合排序？如何找到相似视频的关键位置等都是search，query 需要解决的问题，同时随着视频的长度不一样等问题，如何更好的找到满足要求的视频，这是商用视频系统必须要解决的问题

在商用时，你需要考虑数据在预处理阶段的可持续性，以及为后续录入数据系统，包括query可能涉及的一些效能问题都不得不提前考虑一部分，毕竟对video数据的预处理会在很大程度上左右数据结构的设计，同时数据结构的设计更会影响之后的query 等上层使用逻辑。video的基本信息包括了 video的id ，path，filename，description。前面提了，两个collection，一个存储video 的基本信息，包括 video的id ，path，filename，description。

网上也给出了一些解决方案，在我看来只能是一个示意吧，离商业落地还有很长的路要走，不够robust，如果你认真思考了之后，其实在真正落地的时，会有诸多问题，包括整体结构设计不strong带来的录入，搜索效率问题，数据量大了之后的管理问题，以及搜索精度，准确度问题等。如果你选择milvus作为向量数据库进行存储，有的问题是可以在milvus 提供的内部特性框架下解决的，有的是向量数据库本身无法解决的，需要在顶层设计时，就需要考虑清楚的，毕竟还是那句话，应用场景决定了你要有怎样的顶层设计与架构。

通过1-5 我们已经搭建好完整的后台功能，service，及准备与UI 交互的路由及接口。下面就是UI 部分的搭建。直接采用jinja2的语法将数组传给前端即可。注意jinja2在前端不适合非常复杂的逻辑运算，因为理论上复杂的逻辑运算应该已经在后端完成，前端只是做一些非常简单的展示，循环遍历 输出等工作。

之前的 1-5 重点在介绍系统的实现架构，录入数据的组织形式，存储模式，search 方式，以及后期算法等。现在来看，基本的后端实现我们都具备了，当然后期还会带着各位进一步优化，但从数据结构及录入与query的体现架构来看，系统运作经过前期纯后台测试，还是很不错的。这里的设计核心思想与MVC很类似，现在的软件设计概念层出不穷，后来又搞了一个mvvc，其实最基本的核心思想都大同小异，model，view ，controler。而上面还有UI部分的 controler，那是与页面接壤的service 部分。