在泰國工做那一年，我對象可好了，固然，象對我也很好，O(∩_∩)O哈哈~數據庫
今天呢，我是來兌現我原來的承諾，和你們來解剖一下各大門派的對象（存儲），看看哪一個纔是你（非結構化數據）的夢中情人，嘿嘿。緩存
今天，咱們來說講歷史悠久的EMC家族的對象存儲ECS，這裏ECS可不是二傳手的意思，而是指Elastic Cloud Storage。
安全
爲何說ECS歷史悠久呢，由於EMC在2001年就推出了內容存儲Centera，後來在2008年推出Atmos，到2014年推出的ECS已是第三代對象存儲了。因爲2014年之後，S3已經成爲對象存儲的事實標準，所以，EMC從ECS才支持S3協議的。但因爲現網中有衆多的Centera和Atmos的用戶，所以，ECS被迫支持原來的不少API，能夠想象，ECS的歷史包袱仍是很重的。
微信
ECS的產品架構層次仍是比較清晰的，從上到下依次是：
架構
ECS門戶和供應服務- 基於Web的GUI，容許自我服務，自動化，報告和管理ECS節點。它還處理許可，身份驗證，多租戶和配置服務。app
數據服務- 支持對象，HDFS和NFSv3協議的服務，工具和API。負載均衡
存儲引擎- 負責數據存儲和檢索，管理事務，數據保護和複製。運維
Fabric - 提供羣集，運行情況，軟件和配置管理，升級功能和警報。異步
基礎架構- ECS的基本操做系統是SUSE Linux Enterprise Server 12或更高版本，用於交鑰匙設備或用於商用硬件的合格Linux風格操做系統。分佈式
硬件- 交鑰匙設備或合格的商品硬件。
在數據服務上，前面咱們講過，ECS除了支持S3外，還向下兼容CAS和Atmos，並且，也支持Swift。不過，若是是新用戶，確定只用S3，不會選擇那些過氣的協議了。還有，ECS也支持HDFS和NFS協議，這個咱們後面再講。
不過，ECS在對HDFS的支持這塊，沒有和其餘對象存儲同樣，採用社區的S3A協議，而是本身作了一個專用的ECS HDFS Client。
這樣的好處就是本身來實現HDFS語義對本身對象的訪問，通常都會比S3A有更好的性能和更多的功能。業界對象存儲採用專用HDFS Client來鏈接對象存儲除了EMC外，還有華爲和XSKY，也是這個思路。
因爲對象存儲大部分都具備多站點的能力，所以，Hadoop用戶通常採用ECS對象存儲來作災備，也能夠實現多個數據中心同時分析。
採用存算分離，好處不少，特別是EC（糾刪碼）在對象存儲裏面很是成熟，可是在Hadoop裏面算是比較新的特性，不多看到用戶在生產系統裏部署，主要是硬盤故障的時候重構時間太長，運維比較複製。生產系統用三副本，形成幾乎全部的Hadoop項目都面臨空間不足的問題，但若是一直擴容容量，則有HCI同樣的問題，計算也要跟着作無謂的擴容，形成資源的大量浪費。
ECS內置了對NFS協議的支持，而且支持8個站點的統一命名空間，支持全局鎖，支持NFS|HDFS|S3之間的互訪。
ECS的Chunk是固定的128M，管理的粒度有點大。咱們知道Ceph的缺省Chunk大小是4M。
ECS的數據管理採用B+樹，支持用戶自定義屬性反查，可是限制比較多，每一個桶只能有5個索引段，並且建立完成後就不能修改了。（原來的版本手冊寫了這些限制，但最近ECS今年又發佈了新版本，不知道是否仍是有這些限制，你們測試一下就知道了）。
因爲ECS不支持SSD作寫緩存，和其餘SDS很不同，它用內存作寫緩存。但因爲內存沒有掉電保護，所以，ECS須要和Oracle數據庫同樣，在迴應寫完成前，必須完成日誌的落盤。這種機制形成了數據雙寫，性能比較差。所以，EMC也打算在今年的新版本也要支持SSD作寫緩存了。
ECS的索引數據採用3副本的方式來保證其安全性。
但數據保存所有采用EC（不支持副本）。寫以前數據會壓縮，若是對象大約128MB（Chunk的大小），就直接EC。若是不是，就先寫三副本，而後異步作EC。這樣作的好處就是提升小文件的性能。
而讀嘛，接受讀請求的節點先找索引所在的節點，而後再找數據所在節點讀取數據，返回給host。所以，通常狀況，一個讀流程須要通過三個節點處理，IO訪問路徑長，請求訪問一個對象須要作屢次重定向磁盤訪問，雖然能夠藉助於緩存元數據改善，但大規模隨機訪問狀況下，緩存效果可能通常。
ECS還支持跨站點作EC，這種狀況雖然空間利用率上升了，但對站點的帶寬時延都有比較高的要求，特別是某個站點故障的狀況下。所以，國內我瞭解不多這樣的部署方式。
後來，EMC也認識到這樣的問題，在3.1版本推出了第三站點容災only特性，解決用戶想花比較少的錢實現三站點容災的問題。
ECS的數據複製雖然是異步的，可是元數據複製是同步的。這樣，從用戶角度看，數據是強一致的。但在這種方式若是主站點故障，仍是會丟數據的。
Box-Carting是ECS的小文件歸併功能，ECS在內存裏把小文件歸併爲2MB大小再落盤，提升寫性能。
至於本地數據保護，ECS只支持12+4和10+2兩種保護方式，靈活性比較差。
ECS也支持和IBM同樣的緊湊型EC，減小初始節點數。不過，ECS要求4節點起，而通常分佈式存儲都是三節點起。
因爲ECS支持跨站點EC，所以，站點越多，利用率反而越高，這和通常傳統存儲數據複製的弊端正好是反過來的。不過，前面也講過，中國好像這樣部署的企業客戶很少（公有云比較多）。
ECS的數據可用性只宣傳3個9，太實在了，實在是泥石界的一股清流啊。其餘的廠商巴不得都宣傳6個9以上。不過，可貴EMC不怕友商拿來控標的嗎？O(∩_∩)O哈哈~
ECS的組件都是封裝成容器，採用容器的方式部署。
ECS雖然支持純SDS的方式，但銷售更喜歡推廣一體機，這樣銷售額比較大啦。ECS沒有內置負載均衡功能，並且5節點起步，價格有點小貴。
ECS在擴容這塊特性不是太豐富，重平衡的時間可能比較長。
咱們看到，ECS今年有兩個小版本，在3.3支持SSD作Cache等重要特性，3.4支持新硬件。我前面的分析都是基於去年的版本，新版本我尚未拿到太多資料。
從長遠來講，ECS將來會支持全閃，支持混合雲等特性。
ECS都是Gartner和IDC相關象限的領導者。
Gartner對ECS的UI和容器架構比較欣賞，但仍是指出一些問題。
在產品關鍵能力得分上，只有管理能力作到了業界最佳。
總體來講，我感受ECS功能仍是比較豐富的，好比在跨站點EC和數據強一致這塊作了很多工做，可是，因爲國外廠商通常把對象存儲定位在保存溫冷數據上，其對性能不夠重視。好比ECS剛剛纔支持SSD作Cache，小文件歸併策略太簡單了，不支持副本作數據保護，不支持整池擴容和重構QoS等。
好了，我今天就和你們分享一下個人ECS學習筆記。再次聲明一下，全部的資料都是我在6月份我在美國期間，從網上收集相關素材學習概括出來的，全部的觀點僅表明我我的觀點，其中確定有不少錯誤的地方，歡迎你們指正。
若是你們這樣的分享對你們有用，我打算下一篇寫IBM COS。之後我每寫完一篇，就發起一個調查，看看你們是否找到了本身理想的對象，^_^
若是你們以爲ECS不夠理想，具體哪些方面知足不了你的要求呢？歡迎在留言裏留言。惋惜微信的投票只能作選擇題，不能作填空題，哎。
好了，今天就簡單解剖到這裏。若是你們還有須要當面和我探討的，我將在12月4日的中國存儲峯會等候你們。4日下午有一個容器存儲的分論壇，我有一個關於容器存儲接口歷史演進的演講，歡迎你們來捧場。
你們能夠掃描上面的二維碼參會，如今會議日程已經出來了。
本文分享自微信公衆號 - 高端存儲知識（High-end_Storage）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。