現在我們來看數據訪問路徑，如果看Ceph的文件接口，自底層向上，經過了硬盤（塊）->文件->對象->文件的路徑；如果看RBD的塊存儲服務，則經過了硬盤（塊）->文件->對象->塊，也可能是硬盤（塊）->對象->塊的路徑；再看看對象接口（雖然用的不多），則是經過了硬盤（塊）->文件->對象或者硬盤（塊）->對象的路徑 。
雖說現在大家都這么隨便結合，但是這三種存儲本質上還是有不同的，我們回到計算機的基礎課程，從數據結構來看，這三種存儲有著根本不同 。塊存儲的數據結構是數組，而文件存儲是二叉樹（B,B-,B+,B*各種樹），對象存儲基本上都是哈希表 。
數組和二叉樹都是老生常談，沒有太多值得說的，而對象存儲使用的哈希表也就是常聽說的鍵值（KeyVaule型）存儲的核心數據結構，每個對象找一個UID（所謂的“鍵”KEY），算哈希值（所謂的“值Vaule”）以后和目標對應 。找了一個哈希表例子如下：
鍵值對應關系簡單粗暴，畢竟算個hash值是很快的，這種扁平化組織形式可以做得非常大，避免了二叉樹的深度，對于真·海量的數據存儲和大規模訪問都能給力支持 。所以不僅是對象存儲，很多NoSQL的分布式數據庫都會使用它 。
順便說一句，這類NoSQL的出現有點打破了數據庫和文件存儲的天然屏障，原本關系數據庫里面是不會存放太大的數據的，但是現在像MongoDB這種NoSQL都支持直接往里扔大個的“文檔”數據，所以從應用角度上，有時候會把對象存儲，分布式文件系統，分布式數據庫放到一個臺面上來比較，這才是混搭 。
當然實際上幾個開源對象存儲比如swift和ceph都是用的一致性哈希，進階版，最后變成了一個環，首首尾相接，避免了節點故障時大量數據遷移的尷尬 。
四、分布式存儲在塊存儲、文件存儲、對象存儲的應用成效
軟件定義分布式塊存儲還在發展階段，當前其在產品成熟度、高性能、高可靠、功能方面還是與傳統塊存儲有較大差距，國內軟件定義塊存儲廠商也在做這方面的完善和追趕 。
文件存儲也有其契合的應用場景，其使用簡單快捷，易于多主機共享，在要求帶寬，要IOPS和延遲不敏感，但是又需要經常進行數據改（在存儲上即時更改文件數據）的應用場景比較適合使用文件存儲 。
對象存儲因為架構設計的限制其適合應用數據場景應該是：只進行全讀和全寫的應用場景海量數據場景 。但需要經常進行數據改（在存儲上即時更改數據）的應用場景使用對象存儲就非常的太合適了 。
對象存儲可以用來替代NAS存儲的一些使用場景 ?，F在還有一種流行的做法就是用對象存儲來做數據歸檔和備份 。像優酷、愛奇藝上的視頻（電影視頻發布后一次寫入對象存儲后續不會有數據改操作的 。）或是微信上的圖片（圖片只有上傳寫入和刪除功能，你見騰訊啥時間讓你在線編輯照片了 。）這類應用就是對象存儲的最愛 。
總體是我個人認為分布式對象存儲時最為成熟的軟件定義分布式存儲類型，現在多家對象存儲廠商都支持多副本和EC校驗碼數據保護方式，通過EC校驗碼可以大幅提升有效可用容量做的類型傳統RAID存儲的容量使用率，大幅降低成本 。
推薦閱讀
- 在存儲器的層次結構里誰最快，誰最貴，誰最大？
- 防火墻是被動還是主動
- 社工行業有前景 市場前景
- idc,premier
- 蘋果電腦怎么開機？
- #2019新品發布會#與堅果的四年
- iPhone4怎么刷機？
- itunes怎么設置備份？
- ipad功能介紹。
- 蘋果6s現在多少錢