我們所談?wù)摰摹拔谋尽贝髷?shù)據(jù),如日志或者從不同的來源(如網(wǎng)絡(luò)、信貸機構(gòu)、Facebook)收集的信息,它們都是高度可壓縮的。事實上,大多數(shù)數(shù)據(jù)倉庫產(chǎn)品都是基于column的壓縮,以達到較高的重復(fù)數(shù)據(jù)刪除比率和提高性能。畢竟,最快的I/O是你不必實現(xiàn)的I/O。
重復(fù)數(shù)據(jù)刪除數(shù)據(jù)的結(jié)果是提高緩存利用率,而降低磁盤I/O。重復(fù)數(shù)據(jù)刪除可用于任何規(guī)模的數(shù)據(jù);只是目前大多數(shù)重復(fù)數(shù)據(jù)刪除產(chǎn)品還不能處理大容量的數(shù)據(jù),但這并不意味著不能實現(xiàn)。
當(dāng)我們從整體存儲角度來考慮,而不僅僅是從專業(yè)數(shù)據(jù)庫的角度考慮時,Rob Peglar對于元數(shù)據(jù)的擔(dān)憂就是有道理的。但也有許多的解決方法。
微軟曾在名為“ChunkStash”的技術(shù)研究中提出了一種減少重復(fù)數(shù)據(jù)刪除對RAM需求的方法。這種方法在RAM中僅為每個記錄分配2個字節(jié)。
而復(fù)制節(jié)點之間的元數(shù)據(jù)問題可由初創(chuàng)廠商Scality提供的方法來解決,它使用DHT(Distributed Hash Tables)來處理元數(shù)據(jù)的分布。這與P2P(端對端)系統(tǒng)處理PB級規(guī)模數(shù)據(jù)所使用的技術(shù)是一樣的。
從性能的角度來看,Scality并沒有Isilon高效,但它提供了一種可能解決該問題的方法。
NetApp采用的方法和Isilon的方法一樣“高性能”,而且是以更加簡單的方式來解決這個問題,它并沒有重復(fù)刪除元數(shù)據(jù)的復(fù)制。重復(fù)數(shù)據(jù)刪除在單個節(jié)點上實現(xiàn),而集群更加智能于聚合同類型的文件。這對性能和重復(fù)數(shù)據(jù)刪除都更加有利。
而諸如Vertica和Greenplum的數(shù)據(jù)庫也得益于數(shù)據(jù)的位置。它們并不使用全局重復(fù)數(shù)據(jù)刪除,卻獲得了可觀的壓縮比。
由戴爾收購的壓縮/重復(fù)數(shù)據(jù)刪除廠商Ocarina曾展示過如何從意外的文件(比如圖像和視頻)獲得更好壓縮率的方法。該方法可以用于像石油和天然氣這樣的行業(yè),它們的數(shù)據(jù)曾長期被認為是不可能達到良好的壓縮率。
許多其他廠商處理數(shù)據(jù)的方法可能會獲得更高的壓縮率。來自IBM的Jesse Jonas曾介紹了如何堆積數(shù)據(jù)的方法,這是一種非常不錯的數(shù)據(jù)精簡算法。
壓縮和重復(fù)數(shù)據(jù)刪除將在大數(shù)據(jù)中起到舉足輕重的作用;這一切都將關(guān)于與經(jīng)濟。正如Steve Duplessie所指出的那樣,下一代存儲之爭將圍繞著經(jīng)濟所展開。如果你的系統(tǒng)相比競爭供應(yīng)商的系統(tǒng)需要更多數(shù)據(jù)級的存儲,那么你就難以去競爭。