對象存儲的一點點思考

      對象存儲，一般地，我們認為是指對于給定的唯一的key，擷取對應的value。這其實是一種map的資料結構，它僅僅是根據提供的key這單一因素擷取指定的value。這裡的map指帶的是路由的map，非本地基于記憶體的資料映射，因為路由經常是分布式系統需要重要考慮的因素，也是影響性能的重要因素。對象存儲一般用來存儲小檔案，其大小一般在KB～20MB之間（KB～10MB），如果從終端使用者的角度看待對象存儲，那麼這個key就是一個filepath（檔案系統中的稱謂）或者存儲系統中的url，而value就是檔案内容。從這個角度來講，對象存儲系統就是實作了檔案URL到檔案内容的CURD服務。

      在具體實作時，根據不同的限制條件或者限制，可能具有不同的實作設計。在此，先不評頭論足，僅僅橫向記錄下可用的選擇，以及對其設計進行抽象總結，進而以幫助分析其“秋色如何”。

      為了表述嚴謹，我們将真正擷取到存儲資料實體位址之前的路由過程稱之map的過程。

      有的設計中，在擷取到value之前，需要1次或者多次用到遞進式map方能擷取到需要的value，而多次遞進式map可能會有多次網絡鍊路請求。比如HDFS，檔案的key為HDFS://filepath，在擷取檔案内容時，需要map[filepath]  -> [blocks: dns]，進而定位到存儲資料的實體，擷取value，即檔案内容。在比如HBase，tableName+rawkey就是記錄的url，而擷取rawkey對應的内容，或者一行記錄，需要至多經過3次遞進式map+1次HDFSmap，map[tableName, raowKey]->root table -> meta table -> region server ， 再經過map[HFile]->[HDFS blocks, dns], 定位到具體的存儲資料的實體（這裡是datanode）即可擷取資料。

     有的設計中，在擷取value時，僅需要0次map就可以定位到存儲資料的實體，目前為止，這種設計的尋址方式是基于計算，而非查詢。比如Ceph，在擷取到整個CRUSH map後，僅僅通過一緻性算法計算便可得到存儲資料的位址，進而就可以擷取資料本身。這裡的key一般是指object_id，而object_id可由bucket + filepath + sharding/stripping組合而成。在比如Redis，對于給定的key，可以通過一緻性hash算法計算出記錄對應的redis執行個體位址。

      有的設計中，在借鑒前兩種設計的基礎上，進行自己的擴充設計。典型的設計方式是，在擷取底層存儲資料中繼資料時，采用前面兩種設計中的一種，而擷取真正的value時進行另外的設計。比如采用HBase作為使用者檔案到底層存儲系統的key的映射，而key是由底層存儲系統産生的，它具有唯一性。這樣key的設計就比較靈活，可以是一個64位的串，可以是一個128位的串，也可以是資料庫的primaryid，當然也可以是md5串，這取決于如何設計key到存儲實體的映射以及實體如何管理衆多的對象。在這種設計方式中，key到存儲實體dn的擷取有兩種方法，一是通過查詢，一是通過計算。

     以上設計，暫不進行“華山論劍”，但是其分析的過程，就映射着各自不同的特點。接下來，從整體上，基于另外一個角度，談一談自己的思考。在此談論的對象存儲設計思路都是基于一對一查詢，即使用者提供某種形式的url，擷取相關内容，而對于多條件查詢并未涉及。

    一對一的key到value的查詢一般應用于一次僅處理一個對象的系統或者一次處理多個确定對象的系統。比如對于靜态網頁，網頁中嵌入的多張靜态圖檔，或者新聞報道中嵌入的多張圖檔等等。這種應用非常常見，也确實是對象存儲系統的用武之地。但是最近幾年機器學習或者深度學習技術如火如荼，基于标記的資料擷取作為訓練樣本可能更加具有意義，而這離不開多條件查詢機制。比如擷取大量标記為人群活動、像素大小在800*800、生活在北京的圖檔作為AI算法的訓練樣本。這對對象存儲系統有了更高的要求。 關于這部分的對象存儲設計，因今日天色已晚，待日後補充

201811102340pm 記 北京 西壩河 周六 雙11前夕