針對安防行業(yè)的業(yè)務特性，云存儲的以下兩大技術方向需要重點突破：
1.高效元數(shù)據(jù)組織和框架構建，解決大規(guī)模集群管理和海量文件的問題。
整個分布式系統(tǒng)中需要管理的節(jié)點數(shù)成百上千臺，用戶的一個真實文件會被分布在多臺節(jié)點上，由多臺節(jié)點負責承載真實數(shù)據(jù)的寫入。在讀取時需要經過元數(shù)據(jù)管理服務器請求拿到數(shù)據(jù)位置信息，從而發(fā)起讀取。而針對元數(shù)據(jù)請求的性能是逐級遞歸還是一次訪問就能完成操作，是衡量整個系統(tǒng)性能的關鍵要素。
對于一個單獨的大文件，是否能充分發(fā)揮讀寫性能，涉及拆分粒度問題。元數(shù)據(jù)服務作為核心，需要能在支持上千的節(jié)點、上萬的客戶端請求完成高速并發(fā)處理，這在最基礎的協(xié)議框架和信令交互模型上就需要考慮齊全，通過超高協(xié)議序列化和反序列化性能、可擴展的協(xié)議設計、網(wǎng)絡框架模型、任務處理模型這些底層基礎件上一層層向上，在每個環(huán)節(jié)中都做到高效處理。一個合理元數(shù)的組織結構可以采用類型對象存儲的分桶方式，讓數(shù)據(jù)hash分布，實現(xiàn)文件的簡單高效管理，對于桶內數(shù)據(jù)不需要采用類似傳統(tǒng)目錄樹形式進行逐級的遍歷，僅需一次定位就可以完成操作。
對于文件的數(shù)據(jù)塊組織管理，一方面要控制較好的粒度實現(xiàn)IO能充分發(fā)揮多節(jié)點多磁盤的優(yōu)勢，另一方面需要降低元數(shù)據(jù)的管理壓力，提升管理的集群規(guī)模數(shù)和文件數(shù)量。在存儲節(jié)點上存在用戶的數(shù)據(jù)塊被切分成一段段落在各個磁盤內，系統(tǒng)長期運行或者重啟、掉電、字節(jié)跳變等，需要能夠將節(jié)點管理的數(shù)據(jù)塊和元數(shù)據(jù)中的數(shù)據(jù)塊進行比較，查出差異項完成修正，對于損壞數(shù)據(jù)提早觸發(fā)恢復，這就要求元數(shù)據(jù)在組織合理，能夠快速的查找到對應節(jié)點的元數(shù)據(jù)信息，并在比較處理過程中不影響其他的元數(shù)據(jù)實時訪問和新增。
2.明確的讀寫模型對提供業(yè)務使用語義，解決視頻和圖片不同寫入和讀取要求。
常見的讀寫并非提供一個接口就行，需要有明確的讀寫語義。比如文件系統(tǒng)提供的是文件操作語義，按open/write/read/close模式，并支持seek和修改、追加的語義；S3接口提供的是putObject/getObject接口，按照一次完成上傳，上傳后可以見的語義；HDFS提供的是類似文件系統(tǒng)的操作語義，但不支持修改。
對視頻而言，應該按照文件的語義但又無需支持追加和修改，僅需支持流式的寫入，并支持邊寫邊讀，避免業(yè)務層需要開大緩存或者將視頻文件緩存本地才能上傳。對于圖片寫入方式也是同理，也應支持文件流方式寫入。雖然看上去圖片可以一次寫入一張，但是現(xiàn)在的圖片高清化可以有1MB或者更大，僅通過設置緩存大小完成應用程序的一張圖寫入，會出現(xiàn)云存儲的客戶端內的內存占用過大或者寫入不夠平滑會存在一頓一頓的效果并引發(fā)緩存滿出現(xiàn)圖片丟失問題。在讀取上，對一張圖片內數(shù)據(jù)沒寫入完成無需可讀，但是整張寫入完成是要立即可讀。
再從文件名角度看，由于每張圖片對應一條前端的抓拍記錄，因此對圖片地址可以隨結構化記錄一起存儲，對于用戶來說無需關系圖片地址生成方式，這意味著圖片地址可以由系統(tǒng)返回進行生成。對于視頻流存儲后形成的錄像文件來說，使用方可以無需記錄每段錄像文件名，通過云存儲提供的指定文件名能力，按照自定義的業(yè)務邏輯生成文件名，后續(xù)按照規(guī)則進行查詢即可完成錄像列表或者指定錄像文件的回放。
