應用的角度聊過了，咱們再看看這三種存儲的一些技術細節，首先看看在系統層級的分佈。
咱們從底層往上看，最底層就是硬盤，多個硬盤能夠作成RAID組，不管是單個硬盤仍是RAID組，均可以作成PV，多個PV物理卷捏在一塊兒構成VG卷組，這就作成一塊大蛋糕了。接下來，能夠從蛋糕上切下不少塊LV邏輯卷，這就到了存儲用戶最熟悉的卷這層。到這一層爲止，數據一直都是以Block塊的形式存在的，這時候提供出來的服務就是塊存儲服務。你能夠經過FC協議或者iSCSI協議對卷訪問，映射到主機端本地，成爲一個裸設備。在主機端能夠直接在上面安裝數據庫，也能夠格式化成文件系統後交給應用程序使用，這時候就是一個標準的SAN存儲設備的訪問模式，網絡間傳送的是塊。
若是不急着訪問，也能夠在本地作文件系統，以後以NFS/CIFS協議掛載，映射到本地目錄，直接以文件形式訪問，這就成了NAS訪問的模式，在網絡間傳送的是文件。
若是不走NAS，在本地文件系統上面部署OSD服務端，把整個設備作成一個OSD，這樣的節點多來幾個，再加上必要的MDS節點，互聯網另外一端的應用程序再經過HTTP協議直接進行訪問，這就變成了對象存儲的訪問模式。固然對象存儲一般不須要專業的存儲設備，前面那些LV/VG/PV層也能夠通通不要，直接在硬盤上作本地文件系統，以後再作成OSD，這種纔是對象存儲的標準模式，對象存儲的硬件設備一般就用大盤位的服務器。
從系統層級上來講，這三種存儲是按照塊->文件->對象逐級向上的。文件必定是基於塊上面去作，不論是遠端仍是本地。而對象存儲的底層或者說後端存儲一般是基於一個本地文件系統（XFS/Ext4..）。這樣作是比較合理順暢的架構。可是你們想法不少，還有各類特異的產品出現，咱們逐個來看看：
對象存儲除了基於文件，能夠直接基於塊，可是作這個實現的不多，畢竟你仍是得把文件系統的活給幹了，本身實現一套元數據管理，也挺麻煩的，目前我只看到Nutanix宣稱支持。另外對象存儲還能基於對象存儲，這就有點尷尬了，就是轉一下，何須呢？可是這都不算最奇怪的，最奇怪的是把對象存儲放在最底層，那就是這兩年大紅的Ceph。
Ceph是個開源的分佈式存儲，相信相似的架構圖你們都見過，我把底層細節也畫出來，方便分析。
底層是RADOS，這是個標準的對象存儲。以RADOS爲基礎，Ceph 可以提供文件，塊和對象三種存儲服務。其中經過RBD提供出來的塊存儲是比較有價值的地方，畢竟由於市面上開源的分佈式塊存儲少見嘛（之前卻是有個sheepdog，可是如今不當紅了）。固然它也經過CephFS模塊和相應的私有Client提供了文件服務，這也是不少人認爲Ceph是個文件系統的緣由。另外它本身原生的對象存儲能夠經過RadosGW存儲網關模塊向外提供對象存儲服務，而且和對象存儲的事實標準Amazon S3以及Swift兼容。因此能看出來這實際上是個大一統解決方案，啥都齊全。
上面講的你們或多或少都有所瞭解，但底層的RADOS的細節可能會忽略，RADOS也是個標準對象存儲，裏面也有MDS的元數據管理和OSD的數據存儲，而OSD自己是能夠基於一個本地文件系統的，好比XFS/EXT4/Brtfs。在早期版本，你在部署Ceph的時候，是否是要給OSD建立數據目錄啊？這一步其實就已經在本地文件系統上作操做了（如今的版本Ceph能夠直接使用硬盤）。
如今咱們來看數據訪問路徑，若是看Ceph的文件接口，自底層向上，通過了硬盤（塊）->文件->對象->文件的路徑；若是看RBD的塊存儲服務，則通過了硬盤（塊）->文件->對象->塊，也多是硬盤（塊）->對象->塊的路徑；再看看對象接口（雖然用的很少），則是通過了硬盤（塊）->文件->對象或者硬盤（塊）->對象的路徑。
是否是各類組合差很少齊全了？若是你以爲只有Ceph一個這麼玩，再給你介紹另外一個狠角色，老牌的開源分佈式文件系統GlusterFS最近也宣佈要支持對象存儲。它打算使用swift的上層PUT、GET等接口，支持對象存儲。這是文件存儲去兼容對象存儲。對象存儲Swift也沒閒着，有人在研究Swift和hadoop的兼容性，要知道MapReduce標準是用原生的HDFS作存儲的，這至關是對象存儲去兼容文件存儲，看來混搭真是潮流啊。
雖然說如今你們都這麼隨便結合，可是這三種存儲本質上仍是有不一樣的，咱們回到計算機的基礎課程，從數據結構來看，這三種存儲有着根本不一樣。塊存儲的數據結構是數組，而文件存儲是二叉樹（B,B-,B+,B*各類樹），對象存儲基本上都是哈希表。
數組和二叉樹都是老生常談，沒有太多值得說的，而對象存儲使用的哈希表也就是常據說的鍵值（KeyVaule型）存儲的核心數據結構，每一個對象找一個UID（所謂的「鍵」KEY），算哈希值（所謂的「值Vaule」）之後和目標對應。找了一個哈希表例子以下：
| 關鍵字 | 內部編碼 | 內部編碼的平方值 | H(k)關鍵字的哈希地址 |
| KEYA | 11050201 | 122157778355001 | 778 |
| KYAB | 11250102 | 126564795010404 | 795 |
| AKEY | 01110525 | 001233265775625 | 265 |
| BKEY | 02110525 | 004454315775625 | 315 |
鍵值對應關係簡單粗暴，畢竟算個hash值是很快的，這種扁平化組織形式能夠作得很是大，避免了二叉樹的深度，對於真.海量的數據存儲和大規模訪問都能給力支持。因此不只是對象存儲，不少NoSQL的分佈式數據庫都會使用它，好比Redis，MongoDB，Cassandra 還有Dynamo等等。順便說一句，這類NoSQL的出現有點打破了數據庫和文件存儲的自然屏障，本來關係數據庫裏面是不會存放太大的數據的，可是如今像MongoDB這種NoSQL都支持直接往裏扔大個的「文檔」數據，因此從應用角度上，有時候會把對象存儲，分佈式文件系統，分佈式數據庫放到一個檯面上來比較，這纔是混搭。
固然實際上幾個開源對象存儲好比swift和ceph都是用的一致性哈希，進階版，最後變成了一個環，首首尾相接，避免了節點故障時大量數據遷移的尷尬，這個幾年前寫Swift的時候就提過。這裏再也不深刻細節。