【IT168 应用】随着视频监控图像越来越清晰，存储时间越来越长，存储的可靠性要求越来越高，视频数据的存储也从数字硬盘录像机(DVR)，逐步转向专业的IPSAN专业存储设备，尤其在园区监控中表现更加明显。

　　但是，园区监控中不但要做到园区安防监控，还要对生产业务进行监控。传统监控中，媒体服务器文件存储模式已经不能很好的解决新的存储业务的需求，比如媒体服务器的"哑铃"效应问题，生产监控应急的快速检索和历史录像回放问题等。

　　上述问题的解决需要重新思考监控中的存储模式的选择，打破传统监控中媒体流的文件存储模式。

　　媒体流的文件存储

　　传统的监控采用将流数据组成一个个文件进行存储，所有历史图像回放都是通过播放存储下来的视频文件完成，文件形成期间，管理人员无法读取该文件，比如很多"DVR/DVS+流媒体服务器"方式的监控应用中，采用每半小时形成一个视频文件的方式对监控图像进行存储，这就意味着在当前时刻以前半小时以内的历史图像是无法调用。

　　在紧急事件发生时，人们希望能够尽快看到历史图像，甚至要求可以随时回放。这就要求数据流形成文件的时间间隔尽可能短，但这样又会给系统造成巨大的性能压力。如以5分钟形成一个视频文件，每个监控点一天就将产生近300个文件，如果每个监控点的历史图像要存储30天，就意味着每个监控点需要产生近9000个文件，对于一个1000路的大规模监控系统，将需要处理900万个文件，系统必然不堪重任。

　　对此，业界早在几年前就开始尝试新的数据管理方式，希望能够提高监控存储的数据管理效率，满足监控大规模应用的需求。其中，"块存储"就是比较有特点的一种，这种方式采用"时间索引+块数据"的专用数据结构，抛弃了传统的文件系统，提高了监控数据的管理效率。

　　媒体服务器的性能瓶颈及可靠性

　　传统模式中，当需要实现集中存储或支持多人同时看一个监控点时，中间通过媒体服务器进行转存或复制。这种方式下，媒体服务器需将媒体流转换为文件进行存储，前端的大量的媒体流数据都经过媒体服务器转存到后端的存储设备中。服务器的处理性能，带宽等都容易成为性能瓶颈，整个系统的性能分布成哑铃状，也增加了故障点，媒体服务器的故障会影响到整个系统的监控存储业务。

　　媒体服务器文件存储模式

　　实际上，在很多大规模监控方案中，为了解决媒体服务器性能瓶颈的问题，一般会采用服务器群的方式完成。但又带来新的问题，如多个服务器之间如何进行负载分担?某个服务器故障之后，系统如何将数据流量切换至其他服务器?这些服务器如何管理?如何共享一个存储空间?等等，解决这些问题需要一个非常优秀的集群管理系统，增加系统复杂性的同时，还需要一笔不菲的预算，更遗憾的是，目前业界还没有一个集群管理系统可以很好的解决该问题。

　　因此，前端设备到IP SAN的端到端直存就是一种很好的解决办法。在存储方式上，"数据块直存"的数据管理方式抛弃了媒体服务器，在IP网络的基础上，在编码设备中集成了iSCSI模块，使得编码设备可以基于iSCSI的协议端到端的把录像数据写入IP SAN存储设备中。

　　监控录像的检索效率

　　传统监控中，对于媒体流的文件存储模式，在录像检索时首先要根据摄像头、检索的时间查找到对应的文件，然后再进一步定位具体的时间点，从该时间点回放录像。历史数据检索的最小单位是文件，颗粒度太大，精确度低。

　　文件系统本来是为随机读写的数据管理应用设计的，检索效率较低，一个含几百万个文件的系统的检索效率很难想象。所以，当系统规模扩大后，传统数字监控方案的效率下降很快。

　　在"块直存"的系统中，"块"存储可以理解成自定义的一种文件系统，在裸盘上进行数据读写;时间作为每个数据单元的索引，并且把索引和数据单元保存在一个完全独立的逻辑存储空间上。录像的索引和数据形成独立的、完整的数据结构，这种数据结构完全由自己管理，不再由操作系统和文件管理。通过时间索引+块数据存储这种组合，在录像检索上，可以基于时间进行检索，可以快速定位到任意时间的录像，检索效率大幅度提高。在检索的颗粒度上，也不再受文件大小的限制，可以实现秒级的连续检索。