OpenStack Swift Large Object Support

swift默認下支持上傳的文件5G，當遇到大文件的時候該如何處理呢？Large Object Support幫助咱們解決這個問題，一樣翻譯自官方文檔。

Large Object Support

概述

Swift在單一對象上傳時有大小的限制；默認下是5GB。然而，如今一個單一對象的大小事實上市沒有如今的通用分割的概念。分割上傳的大對象，當下載的時候 一個特殊的manifest文件被建立，發送全部的片斷連結稱一個單獨的對象。這一樣提供了更快的上傳速度在儘量的並行上傳片斷。

使用swift來分割對象

最快的方式試試這個特性是使用swift工具包括在python-swiftclinet庫。當切分一個大文件時，你可使用-S參數來指定分割的大小，例如：swift upload test_container -S 1073741824 large_file
這將會分割large_file稱1G大小的片斷，而後並行的上傳那些片斷。一旦全部的片斷上傳成功，swift將建立manifest文件爲了這些片斷能夠做爲總體被下載。

因此如今，下面的swift 命令將下載整個大對象：swift download test_container large_file
swift 使用嚴格的公約對於他的分割對象支持。在上面的例子將會上傳全部的片斷到第二個名爲test_container_segments容器。這些片斷將會命名如:
large_file/1290206778.25/21474836480/00000000, large_file/1290206778.25/21474836480/00000001, etc.

使用單獨的容器最好的益處就是主容器的表不會被全部的片斷的名字污染。使用格式爲<name>/<timestamp>/<size>/<segment>的片斷名字的緣由是爲了上傳一個新的有相同名字的文件時不會重寫第一次的內容直到mainfest 文件被上傳的那一刻。

swift將會幫你管理這些片斷文件，刪除舊的片斷在刪除和重寫等。你能夠重寫這個行爲用--leave-segments參數若是須要；這個頗有用若是你想要有多個版本的相同的大對象可用。

Direct API 直接API

你也可使用片斷和manifest目錄經過HTTP請求。你能夠只是上傳片斷，manifest文件只是一個0位的文件有一個額外的X-Object-Manifest頭。

全部的對象片斷須要在同一個容器，有個通用的對象前綴名字，它們的名字安裝它們連結的順序排序。它們不須要和manifest文件在同一個容器。這和上面swift中同樣有助於保持容器列表的安靜。

manifest文件僅是一個帶有額外X-Objetc-Manifest的0字節文件： <container>/<prefix> 頭部,<container>是對象片斷所在的容器，<prefix>是全部片斷通用的前綴。

最好的是先上傳全部的片斷而後建立或更新manifest。在整個方式下，整個對象是不可下載的直到上傳完成。因此，你能夠上傳一個新的組段到第二個位置，而後更新manifest去指出整個新的位置。在上傳新片斷期間，起初的manifest會一直可用來下載第一組片斷。

這有一個使用curl對微小的1字節片斷的例子：

# First, upload the segments
curl -X PUT -H 'X-Auth-Token: <token>' \
    http://<storage_url>/container/myobject/1 --data-binary '1'
curl -X PUT -H 'X-Auth-Token: <token>' \
    http://<storage_url>/container/myobject/2 --data-binary '2'
curl -X PUT -H 'X-Auth-Token: <token>' \
    http://<storage_url>/container/myobject/3 --data-binary '3'

# Next, create the manifest file
curl -X PUT -H 'X-Auth-Token: <token>' \
    -H 'X-Object-Manifest: container/myobject/' \
    http://<storage_url>/container/myobject --data-binary ''

# And now we can download the segments as a single object
curl -H 'X-Auth-Token: <token>' \
    http://<storage_url>/container/myobject

其餘的注意事項
1.帶有GET或HEAD的manifest文件，X-Object-Manifest:<container>/<prefix>頭，將會返回連結的對象爲了你能夠看到他們的片斷是從哪裏來的。
2.Content-Length對GET或HEAD的響應在manifest文件將動態的會合計全部的在<container>/<prefix>列表裏片斷，所以，上傳額外的片斷在manifest被穿件後將引發連結的對象變的更大；這不須要去從新建立manifest文件。
3.Content-Type對於GET或者HEAD的響應在manifest文件和Content-Tpye在PUT請求時設置的同樣，建立manifest。你能夠很簡單的改變Content-Tpye經過從新發送PUT。
4.ETag對於GET或HEAD的響應在manifest文件 <container>/<prefix>所列的連結的每一個片斷的ETags的字符串的MD5的值得動態總和。在swift中Etag經常是對象內容的MD5值得總和，適用於每個獨立的片斷。可是，他不能生產這樣的ETag在manifest本身。因此這個方法被選擇來至少提供改變的檢測。

注意：若是若是你使用容器的同步特性你須要確保你的manifest文件和你的片斷文件是同步是否它們在不停的容器中。

History
大對象支持在這個實現以前有過多個版本。

在swift限制對象的大小的最重要的驅使是維護環中虛節點的平衡。爲了維護一個甚至磁盤的分佈使用貫穿集羣的明顯的存儲模式是簡單的把大對象分紅較小的片斷，能夠再讀的時候粘合在一塊兒。

在引入大對象支持以前，一些應用已經能夠拆分它們的上傳成片斷，再組裝它們在客戶端這邊在檢索單個部分。這項設計被容許客戶能夠支持備份和歸檔龐大的數據集，可是也頻繁的改善性能或者減小因爲網絡中斷引發的錯誤。這個辦法的主要缺陷是原始的分區方案須要正確的再組裝這個對象，對於一些場景來講是不切實際的，就像CDN源。

爲了清除進入客戶想要存對象大於5G幣的市場的障礙，首先咱們原型化徹底透明的支持上傳大對象。一個徹底原型化的實現支持一個更大的最大值經過自動的拆分對象稱片斷在上傳到代理，沒有改變客戶的API。全部的片斷徹底的隱藏在客戶的API。

這個解決方案致使了一些具備挑戰性的失敗條件到集羣，不提供可與任何的參數作並行上傳，沒有從失敗中恢復的基礎。這種透明化的實現被認爲太複雜了對於收益。

當前的"user manifest"設計被選擇是爲了提供一個透明的下載大對象到客戶端，一直提供上傳客戶一個乾淨的API來支持分段的上傳。

另外一種「顯示」user manifest方法被討論，須要一種預約義的格式的片斷列表來「完成」分段式的上傳。同時這或許會提供一些潛在的優點，它決定推送一個額外的負載到客戶端，這種其中奶的行爲限制了應該採用更簡單「API」的支持(本質上就是'X-Object-Manifest'頭的格式)

在開發期間咱們注意到，這種基於路徑前綴的「隱式」user manifest方法可能會被最終的容器列表一致性窗口所影響，理論上會引發一個GET在manifest對象返回一個無效的整個的對象在短時間以內。事實上你未必會遭遇這個情形除非你運行了很是高併發的上傳在一個小的運行object-updaters或container-replicators的測試環境。

像全部的swift，大對象支持這個特性會繼續的去提高和改變，在以後的時間。