监控专用对象存储的畅想

为什么要设计监控型对象存储

 

写了《让PB级存储不再神秘》以后,我很久没聊过对象存储。我不想涉密去关注具体厂商的技术底实现,但会考虑通用技术可行性,做一个监控型对象存储的技术畅想。

 

每天都有用监控抓小偷的新闻,监控行业的价值已经得到社会认可和买单;监控视频是最容易实现PB级文件容量和百亿级文件数量的场景,摄像头数量越来越多、清晰度越来越高,而文件管理、存储和分析的压力也越来越大。

 

监控厂商自己做的堆盘式存储是个临时应急性方案,而且客户要求开放式管理监控视频,中立又可靠的对象存储方案是最佳选择。

 

最近几年IT行业并没有核心技术飞跃,我们能做的都是优化选型,过去针对http访问场景的优化选型,现在要做的是贴合监控场景的优化选型。

 

从客户访问和内部实现的角度,本文分为“访问界面”“读写代理”“元数据设计”“存储实现”四部分。

 

访问界面

 

这里指的是应用程序访问界面,而不是自然人访问界面。访问界面有四个问题:

 

要不要存储系统直接支持RTMP?直播和存储技术跨度太大,且监控厂商已经有方案,低优先级处理该功能。

 

要不要提供文件系统级访问接口?优先要求监控厂商使用存储SDK读写和管理监控数据,但可以考虑开发只支持明确路径文件的写入和读取、不支持文件的管理和遍历的伪文件系统驱动,这样才不会给元数据服务造成负担。

 

要不要贴合业务做URL规范?默认对象存储文件的URL是http://单一域名/key值,可以考虑在域名和Key值中贴合监控业务逻辑,让监控和非监控应用都可以快速定位和读取文件。比如说这个URL样例结构,http://region01.{7/14/31}day.local/{date}/{time}/{camera_id}.MP4,只要监控厂商把文件存成通用存储格式,记录好摄像头id的位置,客户完全可以自主读取监控文件给各种视频分析程序。从存储开发的角度,这种URL也为后台做文件生命周期管理、读取文件预判都做了很好需求疏导。

 

要不要约束文件为固定大小?监控摄像头发RTMP流到监控厂商的服务器以后,会由监控厂商自己切成类似于HLS的小文件。如果存储SDK做好文件切分工作,比如说将原始文件都切分成4M的碎片,或者客户直接要求监控厂商原始文件就是4M,对于读写代理的并发和缓存、元数据的设计、存储落盘的优化都有极大助力。

 

读写代理

 

访问代理就是客户端程序访问到的API,在这一层对访问需求进行过滤和缓存。

 

访问代理要不要做读缓存和写缓冲?访问代理做读缓存是有必要的,因为监控类场景不存在重名文件,而同一个文件会多次反复读取。访问代理肯定是群集式或者SDK控制,看客户端是随机分配还是会话保持策略,我们再去决定是做本地缓存还是共享式缓存池。至于做不做写缓冲,这就是写入性能、业务连续性、数据可靠性的零和博弈,没有标准答案。

 

访问代理要不要预缓存?默认的对象存储并不关注客户业务,但如果url可以规范化,我们是能推测出客户下一阶段大概率访问哪个文件的,数据预取可以极大的提高客户体验。

 

访问代理的读写权限优化控制。访问代理可以继续基于标准token验证机制,也可以简化为基于IP地址进行读写权限控制。访问代理可以预判读写请求是否合法,比如说读取明显已经超时的数据,或者时差严重时写入文件,这些都可以在访问代理层面直接拒绝。

 

元数据设计

 

元数据的优化压力不大,因为在应用场景和访问代理层面已经给元数据做足够减负。

 

元数据内容一般包括:filename、filesize、createtime、hash、filehandle、Mimetype,理论上来说除了Filename和Filehandle,其他属性都可以压缩和放弃,但放弃这些属性对元数据服务的性能提升不大,反倒是丧失了很多debug便利性。

 

通用场景的对象存储对Filehandle是一条递归记录还是多条并行记录、一层文件记录还是Trunk+文件记录,原始文件记录还是纠删码记录的选型研究很谨慎。而监控存储场景下写多读少、文件体积较小、文件可以预取、定期批量删除,做选型的难度会比通用存储小很多,场景简单也很容易做性能压测。

 

从系统架构上来看,元数据数据库可以“均匀的”分库读写,对回看读库可以接受1s以上的延迟,几乎没有汇总管理和筛选类需求,其数据库优化压力非常小。

 

存储池实现

 

存储池实现部分都是硬碰硬的干货了,科普文章只能谈三个问题的选型。

 

新手厂商可以技术降级,直接做本机RAID而不是做分布式存储。监控存储毕竟可靠性要求低,坏服务器又不是丢失数据,厂商的驻场工程师勤快可靠一些,功能可用性也能到99.9%,数据可靠性也能到99.99%。

 

如果厂商用纠删码要不要加前置写缓冲池,而且选用纠删码会提高存储节点的计算压力,CPU内存也要多花钱,好在可以约束监控文件的大小和写入频率,最后需要厂商详细给客户算一算,纠删码方案的整体TCO成本是否最合理。如果客户需求要上多机房容灾,这是双机房同步或者三机房纠删码技术PK的好战场了。

 

对于这种滚动删除文件的场景,建议要定期作废存储单元而非逐个删除存储文件。这就要求同一时间的存储文件尽量在同一个Trunk、PG、单款硬盘、硬盘组上,分块越小越细则IO分布更均匀,分块越大则磁头的开销越低。

 

BTW:元数据可以延迟删除FileHandle记录,存储硬件在故障恢复后也不要着急立刻释放过期数据。

 

后记

 

写这篇文章是我用半天时间做的脑力锻炼,也是给朋友们展示一种引导客户需求的可能性。

 

但写这篇文章的过程中,我更想明白了一个道理,能读懂我每一条技术顾虑的人绝对不是个纯粹的产品经理,请大家期待我的下一篇文章《为什么企业级工业级软件难寻产品经理》。

 

收藏 评论(1)
分享到:
共1条回复 最后由代开深圳票 回复于2019-08-06 22:33
#2 代开深圳票 回复于2019-08-06

棒棒哒

0