监控专用对象存储的畅想

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

 

写了《让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记录，存储硬件在故障恢复后也不要着急立刻释放过期数据。

 

后记

 

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

 

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