swift能幹什麼，不能幹什麼及相關概念

1.swift 是什麼？
OpenStackObject Storage (Swift) 是開源的，用來建立可擴展的、冗餘的、對象存儲（引擎）。 swift使用標準化的服務器存儲 PB 級可用數據。但它並非文件系統 (file system) ，實時的數據存儲系統(real-timedata storage system) 。 swift 看起來更像是一個長期的存儲系統 (long term storage system) ，爲了得到、調用、更新一些靜態的永久性的數據。好比說，適合存儲一些類型的數據：虛擬機鏡像，圖片存儲，郵件存儲，文檔的備份。沒有「單點」或者主控結點 (master point of control) ， swift看起來具備更強的擴展性、冗餘和持久性。

2.swift 能作什麼?

長於存儲非結構化數據，大、小文件性能聽說都很好（目前沒有測試數據， adrian otto 說測試過10 億個 1byte 數據）。


3.swift 不能作什麼?

• Objects must be <5GB ： swift 1.2 以後已經對 object 的大小不作限制
• Not a Filesystem ：不是文件系統。 swift 使用 REST API ，而不是使用傳統意義上的文件操做命令， open(), read(), write(), seek(), 和 close() 等。
• No File Locking ：乾脆不支持「文件鎖」。其實在 swift 中，「鎖」的概念是沒有必要的。
• No Directory Hierarchies ：沒有文件目錄結構。 swift 能夠模擬目錄結構，但沒有必要
• Not a Database ：不是數據庫。 swift 使用 account-container-object 的概念存儲 object ，能夠列表出指定 container 中的 object ，不支持 server 端的查詢和處理操做。

----------------------------------------------------------------------------------------------------------------------------------------------------

Account

出於訪問安全性考慮，使用Swift系統，每一個用戶必須有一個帳號（Account）。只有經過Swift驗證的帳號才能訪問Swift系統中的數據。提供帳號驗證的節點被稱爲Account Server。Swift中由Swauth提供帳號權限認證服務。用戶經過帳號驗證後將得到一個驗證字符串（authentication token.），後續的每次數據訪問操做都須要傳遞這個字符串。

Container

Swift中的container能夠類比Windows操做系統中的文件夾或者Unix類操做系統中的目錄，用於組織管理數據，所不一樣的是container不能嵌套。數據都以Object的形式存放在container中


Swift有以下幾個特性：
一、極高的數據持久性，上面已經提到了。
二、各個存儲的節點徹底對等，是對稱的系統架構。
三、由於是對稱的系統架構，擴容的時候只需簡單的增長機器，擴展性很好。
四、不存在單節點故障，前面提到由於各個節點徹底對等，沒有所謂的「主從」結構。

存儲在Swift裏面的數據有好幾個備份，並且各個節點之間是平等的關係，沒有「主節點」這個概念，所以任意一個節點出現故障時，數據並不會丟失（注意，這裏是任意一個節點出現故障）。而與它造成對比的是Hadoop的HDFS。

HDFS有一個元數據存儲節點，保存在HDFS集羣中的全部文件都會在元數據存儲節點上保留一份元數據，元數據記錄了每一個文件的一些必要的信息，例如文件大小，屬於哪一個用戶，更新的時間，存儲在HDFS哪臺數據服務器上等等，感受這個元數據的概念有點相似Linux中文件的inode信息。HDFS的缺點是一旦元數據服務器掛掉，那麼整個HDFS集羣就玩完了。固然，這只是我對HDFS一點淺顯的認識，真正的部署的時候確定還有不少保護措施，HDFS的健壯性是很好的。

回到Swift上，Swift的元數據存儲是徹底均勻隨機分佈的，而且與對象文件存儲同樣，元數據也會存儲多份。


不管是HDFS也好，Swift也好，必須面對的一個問題就是如何保持數據的一致性。 由於一個文件並非只保存一份的，在Swift中默認要保存3個副本，當更新的時候這3個文件要同時更新，當其中一個文件損壞時必須能迅速的複製一份完整的文件來替換。

Swift有3個服務來解決這個問題：Auditor、Updater和Replicator。 Auditor運行在每一個Swift服務器的後臺持續地掃描磁盤來檢測數據的完整性。若是發現數據損壞，Auditor就會將該文件移動到隔離區域，而後由Replicator負責用一個無缺的拷貝來替代該數據。若是更新失敗，該次更新在本地文件系統上會被加入隊列，而後Updaters會繼續處理這些失敗了的更新工做。

--------------------------------------------------------------------------------------------------------------------------------------------------

剛纔提到過，Swift沒有元數據服務器，也就是說，不會特地爲每個文件生成一個相似inode的東西，而且保存在特定的一個服務器上，這一點與HDFS有很大的不一樣。那麼剩下最後一個問題：Client要存儲一個文件，用什麼策略決定存在哪臺Storage Node上呢？（爲了更好的表示，咱們能夠看下圖以下圖所示，圖1爲Swift架構，圖2爲對象存儲）


<ignore_js_op> 

圖1Swift部分架構

<ignore_js_op> 


圖2對象存儲


能夠看出，在對象存儲中，存儲的不只是數據，還有與豐富的數據相關的屬性信息。系統會給每個對象分配一個惟一的ID。對象自己是平等的，全部的ID都屬於一個平坦的地址空間，而並不是文件系統那樣的樹狀邏輯結構。

這種存儲結構帶來的好處是能夠實現數據的智能化管理，由於對象自己包含了元數據信息，甚至更多的屬性，咱們能夠根據這些信息對對象進行高效的管理。例如咱們能夠制定這樣的存儲策略，若是對象中包含priority:high，這樣的屬性，咱們就對文件作比日常文件多的備份次數。

平坦地址空間的設計使得訪問對象只經過一個惟一的ID標識便可，不須要複雜的路徑結構。

所以，能夠知道Swift中沒有「路徑」這個概念，因此也沒有有所謂的「文件夾」這樣的概念。

如今，咱們有了對象的ID了，那麼如何根據這個ID把對象存在合適的Storage Node呢？

在解決這個問題時，要注意幾個約束條件：

一、能快速的作一個決策，到底存在哪一個Node上。
解決這個問題，咱們的第一反應應該是根據ID作一個Hash，不錯，Swift確實是這麼作的。

二、Swift裏面存儲着成千上萬，甚至上億個 Object，當咱們往集羣中增長Storage Node的時候，最好不影響已有的數據。
對於固定數量的Storage Node，使用普通的取模Hash法應該是又快又好的，當時當Node的數量會變更時，這種簡單的Hash就不行了，由於這時全部對象的Hash值都會改變，這對於存儲了上億個對象的Swift來講是至關可怕的。

解決的方法是使用「一致性Hash法」。

一致性哈希算法的基本實現原理是將機器節點和key（在本文裏就是對象的ID）值都按照同樣的hash算法映射到一個0~2^32的圓環上。當有一個寫入緩存的請求到來時，計算Key值k對應的哈希值Hash(k)，若是該值正好對應以前某個機器節點的Hash值，則直接寫入該機器節點，若是沒有對應的機器節點，則順時針查找下一個節點，進行寫入，若是超過2^32還沒找到對應節點，則從0開始查找(由於是環狀結構)。



<ignore_js_op> 


通過一致性哈希算法散列以後，當有新的機器加入時，將隻影響一臺機器的存儲狀況，例如新加入的節點H的散列在B與C之間，則原先由C處理的一些數據可能將移至H處理，而其餘全部節點的處理狀況都將保持不變，所以表現出很好的單調性。而若是刪除一臺機器，例如刪除C節點，此時原來由C處理的數據將移至D節點，而其它節點的處理狀況仍然不變。而因爲在機器節點散列和緩衝內容散列時都採用了同一種散列算法，所以也很好得下降了分散性和負載。而經過引入虛擬節點的方式，也大大提升了平衡性。

 

上面提到了什麼是結構化數據，什麼是非結構化數據，這裏補充一下：

結構化數據

簡單來講就是數據庫。結合到典型場景中更容易理解，好比企業ERP、財務系統；醫療HIS數據庫；教育一卡通；政府行政審批；其餘核心數據庫等。這些應用須要哪些存儲方案呢？基本包括高速存儲應用需求、數據備份需求、數據共享需求以及數據容災需求。

非結構化數據

包括視頻、音頻、圖片、圖像、文檔、文本等形式。具體到典型案例中，像是醫療影像系統、教育視頻點播、視頻監控、國土GIS、設計院、文件服務器（PDM/FTP）、媒體資源管理等具體應用，這些行業對於存儲需求包括數據存儲、數據備份以及數據共享等。

半結構化數據

包括郵件、HTML、報表、資源庫等等，典型場景如郵件系統、WEB集羣、教學資源庫、數據挖掘系統、檔案系統等等。這些應用對於數據存儲、數據備份、數據共享以及數據歸檔 等基本存儲需求。