有評論表示， 物件存儲是一個相對新的市場部分， 目前繼續穩步增長， 並有更多值得採用的理由。
對於不瞭解的人來說， 物件存儲用於保存大量的非結構化資料， 其中每個“物件”本質上是沒有特定格式的檔(也稱為二進位檔案)。 物件存儲可以保存任何類型的資料， 從人類可讀的小目的檔到媒體(音訊和視頻)或其他行業特定的格式(石油和天然氣， 醫學成像等)。
與傳統存儲相比， 使用物件存儲的好處是多方面的。 基於塊的系統(例如光纖通道和iSCSI)不能很好地向外擴展， 並且對存儲的資料沒有真正的理解。
物件存儲進一步進行並刪除檔夾層次結構。 物件存儲有通常可高度搜索的可擴展中繼資料。 在規模方面， 物件存儲可以增長到多個(即使不是幾百個)PB， 通常對資料地理沒有限制。 物件存儲的使用正在企業中被採用， 因為平臺提供了優於傳統形式的存儲優點。 基於塊的存儲陣列不能很好地進行擴展， 並且具有大量的HDD和SSD資料保護(例如RAID)問題。
基於檔的系統受到檔案系統本身可擴展性的限制，
對於尋求採用物件存儲的IT組織來說， 最大的挑戰是選擇如何使用平臺以及如何評估供應商的產品。 物件存儲使用基於Web的協定， 因此需要一定程度的編碼才能使用。 這正在發生改變， 我們將在後面進行討論。
從特性的角度來看， 物件存儲有許多方面使得一個平臺比另一個平臺更合適。 在本文的剩餘部分， 我們將從識別、分類和描述方面對適合IT組織的物件存儲平臺進行尋找。
可擴展性 - 大和小
如已經討論的，
對象大小。 物件存儲如何處理小和大物件?如何處理小物件?
容量限制。 容量是否有真正的限制? 容量增長是否需要添加更多的硬體或軟體節點? 我可以簡單地擴展存儲嗎?
分層和緩存。 物件存儲如何管理資料分層?隨著容量的增長， 自然地大量資料將是非活動的， 並且提供了存檔到更廉價的媒介的機會。 在這一點上， 分層成為一個關鍵的能力。 快閃記憶體介質還可用於在用作緩存或分層時提高性能。
中繼資料管理。
對象訪問。 隨著物件存儲的增長， 任何單獨物件的存取時間是否增加(希望不是所有)?
最後一點對於構建可以並行地提供對許多物件存儲/檢索請求的訪問的物件存儲(例如用作CDN網路的後端系統)特別重要。 增加物件存儲中的物件數量， 而不應顯著增加檢索時間， 或更重要的是“到第一個位元組的時間”， 這是從接收點開始將物件流回請求者所花費的時間請求。
當然， 我們不應該忘記物件存儲可能啟動時需要的規模很小， 不需要具有幾百TB或PB級的初始佔用。 具有小型入門級功能的能力， 有助於減少物件存儲採用的進入障礙，
資料保護
資料保護的概念涵蓋了物件存儲中的許多方面。 與傳統的“主”存儲相比， 物件存儲可能用於長期保留資料， 因此資料持久性成為一個重要因素。 我們可以將持久性視為需要確保由於一系列錯誤(包括硬體讀取失敗和資料損壞)而對正在存儲的資料不發生邏輯損壞。
與四分之一個世紀前使用的設備相比， 現代硬碟驅動器非常可靠。 儘管如此， 驅動器仍然遭受讀取錯誤和其他的瞬態問題。 物件存儲應該執行一系列磁片管理功能， 包括資料清理、CRC檢查和損壞或不一致資料的重建。 這些幕後工作表示， 在需要長期保留至關重要的情況下保持資料健康的過程。
第二個要考慮的是硬體故障保護。大多數現代存儲陣列實現RAID(廉價磁片冗餘陣列)作為從硬體故障導致的丟失中恢復資料的方法，隨著資料量開始上升，RAID存在可擴展性問題。存儲供應商已實現雙重甚至三重同位，以防止大型硬碟容量的多個驅動器故障。但是，延長的驅動器重建時間使得RAID對於物件存儲中的大量資料不切實際。
替代方案是使用擦除編碼方案來保護資料。擦除編碼描述了將資料劃分和變換為多個冗餘片段的過程，其中恢復原始資訊所需為最小計數。例如，編碼方案可以將資料翻譯成12個，重建原始資料所需為任意8個。這12個可以分佈在多個驅動器，伺服器/節點或甚至地理上以提供高彈性。在12/8方案中，跨越三個位置的分佈資料意味著可以容忍任何一個位置的丟失。
物件存儲應根據客戶需要提供具有可變保護值的擦除編碼。由於擦除編碼具有能夠顯著的處理開銷，因此RAID還可以用於保護較小的物件並改善訪問性能。如果資料在地理上分佈的情況下，重建對網路的影響變得重要。因此，擦除編碼系統的具體實現(以及在WAN上檢索資料的需要)將直接影響恢復時間和客戶SLA(服務水準協定)。當本地LAN延遲較高時，也會發生此問題 - 任何基於分散式網路的恢復將始終受到網路性能的影響。快速恢復非常重要，因為不受保護的資料需要快速重新保護，以避免潛在的資料丟失。
搜索、索引和中繼資料
在物件存儲中搜索和檢索資料的能力是最關鍵的要求之一。與結構化資料(如資料庫和檔案系統)相比，物件存儲將資料保存在平面層次結構中，只有少量的邏輯或物理分隔(例如存儲桶或池)。這意味著存儲的每個物件都需要有大量的資訊，以便於資料檢索。
物件存儲通常使用兩種方法之一存儲資料;最終使用者設置物件的名稱(可能看起來像標準檔案名)，或者使用系統生成的物件ID(OID)存儲和訪問物件。 OID通常是字元和數位的長字串，由物件存儲庫本身隨機生成。
在使用OID的情況下，中繼資料是關鍵的。 物件存儲使用者還可以維護物件ID及其使用的單獨資料庫。中繼資料提供關於物件本身(系統中繼資料)的資訊，例如物件大小、存取權限、創建物件的使用者等。使用者中繼資料擴展每個物件存儲的資訊，並且是用於傳遞搜索和索引能力的應用程式特定資訊。
中繼資料搜索的性能應該獨立於存儲在物件存儲本身中的資料量。這是管理可擴展性的關鍵要求。
性能
在我們對需求的討論中，性能是實現可擴展性、資料保護和搜索的主題。當物件存儲首次開發時，性能的想法不是一個關鍵考慮，因為許多物件存儲只是用作長期存檔或備份存儲庫。越來越多的物件平臺被用於更活躍的資料，作為活動存檔或用於媒體和其他流式內容的存儲庫。
結果是需要物件存儲平臺提供高輸送量、線性擴展性能和處理高水準的併發請求。在將物件平臺用作CDN(內容交付網路)或其他軟體即服務(SaaS)解決方案的後備存儲時，併發性的需要尤為重要。併發意味著能夠同時傳輸許多物件，並能夠每秒處理大量的單獨請求。在度量方面，典型的測量基於IOPS(每秒I / O)和輸送量(MB/sec or GB/sec)。
安全
與任何資料存儲一樣，安全是一個關鍵特性。在物件存儲中，安全特性涵蓋了許多方面。
由於資料量可能保留在物件存儲中，多租戶變得非常重要。業務使用者(組織中的單獨部門或單獨的組織)希望知道他們的資料與其他人的訪問隔離。這意味著具有單獨的安全憑證，並為每個客戶或物件提供加密金鑰。
物件存儲通常通過在對物件存儲本身的HTTP調用上提供的認證金鑰來提供對資料的訪問。這些金鑰是憑據，而不是典型的使用者/密碼組合，因為資料可以通過公共互聯網傳遞。管理憑證的更廣泛的任務是身份管理功能的一部分，也可以集成到標準平臺，如LDAP和Microsoft Active Directory。
將通過存取控制清單分配對單個物件或存儲的訪問，這些清單確定對資料的單個或組級訪問。許多物件存儲將允許通過用於存儲和檢索資料的相同的基於Web的REST介面來設置和管理存取控制。
除了管理身份之外，必須通過資料加密提供安全性，無論是在飛行還是在休息。通常，使用TLS(例如HTTPS)在協議級實現飛行中保護。休息時，應對資料進行加密，以防止在物理伺服器級別或驅動器/設備級別直接訪問。加密的具體點或實現可以取決於最終用戶想要如何管理加密金鑰。資料可以在添加到物件存儲之前或同時進行加密。
合規性和審計
合規性是資料安全的另一個方面，重點是滿足特定受控行業（如醫療保健和金融）中保留資料的監管要求。 通常，相容系統需要能夠提供資料的不可變性，提供物件版本控制（因此可以跟蹤改變），實現物件鎖定或WORM（一次讀取多次），再次用於不可變資料。與塊和基於檔的系統相比，大多數物件程式庫不更新資料。這提供了一定程度的控制，符合合規性的要求。
審計對合規性進行了補充，提供了一個顯示資料如何存儲在物件存儲系統中的跟蹤。審計跟蹤還可以提供附加資訊，例如層之間的資料移轉，內容的校驗和驗證（以確保沒有篡改）以及對單個資料物件或桶的所有訪問。
部署模型
物件存儲已經走向軟體定義存儲或SDS的前沿。 大型橫向擴展部署的性質意味著物件程式庫與商品硬體和供應商提供的軟體的成本模型能夠進行很好地協作。 因此，我們看到許多基於軟體的物件存儲的實現。
使用商品硬體，當然不適合所有要求。許多潛在客戶可能不願或無法管理採購和構建定制物件存儲解決方案的過程，而寧願從供應商處獲取組合的硬體和軟體解決方案。在這種情況下，供應商需要提供設備以滿足客戶的需求，可能與已經在客戶的資料中心中的伺服器和存儲供應商進行了合作。為什麼？ 因為支援模型，內部技能和部署藍圖需要基於首選的硬體供應商。為了最大的靈活性，供應商可能提供三種選擇：
僅軟體 - 作為VSA（虛擬存放裝置）或本地部署到硬體上。
設備 - 專用硬體設備，構建為白盒或與主要硬體提供商之一所進行配合使用。
雲 - 作為公共雲中的實例部署。 對於每個選項，客戶應該期望完全的互通性和一致的管理介面。
協定支援和標準
初始物件存儲基於HTTP（S）協定，使用基於REST的API調用來存儲和檢索資料。HTTP的使用是靈活的，因為可以從網路上的任何地方（局部或廣域）訪問資料，然而，與訪問存儲在橫向擴展檔案系統中的資料相比，應用程式必須被編碼以使用物件存儲。 因此，供應商已開始向其產品添加NFS和SMB支援，允許通過標準的基於檔的協定存儲和檢索資料。為了完全支持向外擴展功能，支持應包括並行檔案系統。
擴展協定支援意味著可以輕鬆地移植或修改現有應用程式，以便為其資料使用物件存儲。還值得考慮的是，與橫向擴展檔存儲相比，通過使用類比檔存儲的物件存儲提供的體系結構之間的差異。 底層資料不是使用基於inode和目錄的結構存儲的，因此系統崩潰後FSCK（檔案系統掃描）的概念不適用。與傳統檔案系統相比，這對支援檔案系統的物件存儲的可擴展性和性能有很大的影響。
協定支援還需要擴展到實際採用的情況或行業標準。對於物件存儲，這意味著使用S3和Swift，這兩個已經獲得廣泛流行的"標準"。亞馬遜早在2006年就發佈了S3（簡單存儲服務）平臺進入物件市場，使得S3 API成為許多供應商選擇遵循的標準，因為它已經成熟和全面。Swift從OpenStack專案的物件存儲元件中進行開發。
擁有權總成本
沒有對價格和TCO的討論，物件存儲的摘要是完不完整的。 最明顯的許可模式是基於容量的模式 - 向平臺添加更多可用或原始容量，並以實際增量支付更多許可證。供應商還可以選擇為每個節點收費，這意味著最終使用者需要確保他們部署的硬體提供盡可能大的容量。
還有一個按功能收費的選項，雖然一些供應商將看到創建一個全面的收費結構，包括所有功能選項的機會。從終端使用者的角度來看，這顯然更具競爭力，但是隱藏的額外成本可能是一個問題。
計算TCO提出了一個關於物件存儲平臺效率的有趣問題。 橫向擴展節點設計採用計算，系統記憶體和磁片或快閃記憶體存儲來提供一定量的使用者容量。當構建白盒硬體時，軟體的效率與構建解決方案的成本直接相關。到目前為止，沒有實際的基準來比較物件存儲的效率，這仍然是一個需要一些發展的領域。
結論
我們強調了物件存儲的九個關鍵特性。供應商將以補充其產品架構的方式實現這些功能。在決定哪些平臺是您的業務中使用的平臺時，其中一些關鍵功能的評級將高於其他平臺。 這裡列出的清單沒有特定的順序。 然而，作為一個潛在客戶，目標應該是通過這個清單，確定那些重要的功能，值得投入更多的調查。
第二個要考慮的是硬體故障保護。大多數現代存儲陣列實現RAID(廉價磁片冗餘陣列)作為從硬體故障導致的丟失中恢復資料的方法，隨著資料量開始上升，RAID存在可擴展性問題。存儲供應商已實現雙重甚至三重同位，以防止大型硬碟容量的多個驅動器故障。但是，延長的驅動器重建時間使得RAID對於物件存儲中的大量資料不切實際。
替代方案是使用擦除編碼方案來保護資料。擦除編碼描述了將資料劃分和變換為多個冗餘片段的過程，其中恢復原始資訊所需為最小計數。例如，編碼方案可以將資料翻譯成12個，重建原始資料所需為任意8個。這12個可以分佈在多個驅動器，伺服器/節點或甚至地理上以提供高彈性。在12/8方案中，跨越三個位置的分佈資料意味著可以容忍任何一個位置的丟失。
物件存儲應根據客戶需要提供具有可變保護值的擦除編碼。由於擦除編碼具有能夠顯著的處理開銷，因此RAID還可以用於保護較小的物件並改善訪問性能。如果資料在地理上分佈的情況下，重建對網路的影響變得重要。因此，擦除編碼系統的具體實現(以及在WAN上檢索資料的需要)將直接影響恢復時間和客戶SLA(服務水準協定)。當本地LAN延遲較高時，也會發生此問題 - 任何基於分散式網路的恢復將始終受到網路性能的影響。快速恢復非常重要，因為不受保護的資料需要快速重新保護，以避免潛在的資料丟失。
搜索、索引和中繼資料
在物件存儲中搜索和檢索資料的能力是最關鍵的要求之一。與結構化資料(如資料庫和檔案系統)相比，物件存儲將資料保存在平面層次結構中，只有少量的邏輯或物理分隔(例如存儲桶或池)。這意味著存儲的每個物件都需要有大量的資訊，以便於資料檢索。
物件存儲通常使用兩種方法之一存儲資料;最終使用者設置物件的名稱(可能看起來像標準檔案名)，或者使用系統生成的物件ID(OID)存儲和訪問物件。 OID通常是字元和數位的長字串，由物件存儲庫本身隨機生成。
在使用OID的情況下，中繼資料是關鍵的。 物件存儲使用者還可以維護物件ID及其使用的單獨資料庫。中繼資料提供關於物件本身(系統中繼資料)的資訊，例如物件大小、存取權限、創建物件的使用者等。使用者中繼資料擴展每個物件存儲的資訊，並且是用於傳遞搜索和索引能力的應用程式特定資訊。
中繼資料搜索的性能應該獨立於存儲在物件存儲本身中的資料量。這是管理可擴展性的關鍵要求。
性能
在我們對需求的討論中，性能是實現可擴展性、資料保護和搜索的主題。當物件存儲首次開發時，性能的想法不是一個關鍵考慮，因為許多物件存儲只是用作長期存檔或備份存儲庫。越來越多的物件平臺被用於更活躍的資料，作為活動存檔或用於媒體和其他流式內容的存儲庫。
結果是需要物件存儲平臺提供高輸送量、線性擴展性能和處理高水準的併發請求。在將物件平臺用作CDN(內容交付網路)或其他軟體即服務(SaaS)解決方案的後備存儲時，併發性的需要尤為重要。併發意味著能夠同時傳輸許多物件，並能夠每秒處理大量的單獨請求。在度量方面，典型的測量基於IOPS(每秒I / O)和輸送量(MB/sec or GB/sec)。
安全
與任何資料存儲一樣，安全是一個關鍵特性。在物件存儲中，安全特性涵蓋了許多方面。
由於資料量可能保留在物件存儲中，多租戶變得非常重要。業務使用者(組織中的單獨部門或單獨的組織)希望知道他們的資料與其他人的訪問隔離。這意味著具有單獨的安全憑證，並為每個客戶或物件提供加密金鑰。
物件存儲通常通過在對物件存儲本身的HTTP調用上提供的認證金鑰來提供對資料的訪問。這些金鑰是憑據，而不是典型的使用者/密碼組合，因為資料可以通過公共互聯網傳遞。管理憑證的更廣泛的任務是身份管理功能的一部分，也可以集成到標準平臺，如LDAP和Microsoft Active Directory。
將通過存取控制清單分配對單個物件或存儲的訪問，這些清單確定對資料的單個或組級訪問。許多物件存儲將允許通過用於存儲和檢索資料的相同的基於Web的REST介面來設置和管理存取控制。
除了管理身份之外，必須通過資料加密提供安全性，無論是在飛行還是在休息。通常，使用TLS(例如HTTPS)在協議級實現飛行中保護。休息時，應對資料進行加密，以防止在物理伺服器級別或驅動器/設備級別直接訪問。加密的具體點或實現可以取決於最終用戶想要如何管理加密金鑰。資料可以在添加到物件存儲之前或同時進行加密。
合規性和審計
合規性是資料安全的另一個方面，重點是滿足特定受控行業（如醫療保健和金融）中保留資料的監管要求。 通常，相容系統需要能夠提供資料的不可變性，提供物件版本控制（因此可以跟蹤改變），實現物件鎖定或WORM（一次讀取多次），再次用於不可變資料。與塊和基於檔的系統相比，大多數物件程式庫不更新資料。這提供了一定程度的控制，符合合規性的要求。
審計對合規性進行了補充，提供了一個顯示資料如何存儲在物件存儲系統中的跟蹤。審計跟蹤還可以提供附加資訊，例如層之間的資料移轉，內容的校驗和驗證（以確保沒有篡改）以及對單個資料物件或桶的所有訪問。
部署模型
物件存儲已經走向軟體定義存儲或SDS的前沿。 大型橫向擴展部署的性質意味著物件程式庫與商品硬體和供應商提供的軟體的成本模型能夠進行很好地協作。 因此，我們看到許多基於軟體的物件存儲的實現。
使用商品硬體，當然不適合所有要求。許多潛在客戶可能不願或無法管理採購和構建定制物件存儲解決方案的過程，而寧願從供應商處獲取組合的硬體和軟體解決方案。在這種情況下，供應商需要提供設備以滿足客戶的需求，可能與已經在客戶的資料中心中的伺服器和存儲供應商進行了合作。為什麼？ 因為支援模型，內部技能和部署藍圖需要基於首選的硬體供應商。為了最大的靈活性，供應商可能提供三種選擇：
僅軟體 - 作為VSA（虛擬存放裝置）或本地部署到硬體上。
設備 - 專用硬體設備，構建為白盒或與主要硬體提供商之一所進行配合使用。
雲 - 作為公共雲中的實例部署。 對於每個選項，客戶應該期望完全的互通性和一致的管理介面。
協定支援和標準
初始物件存儲基於HTTP（S）協定，使用基於REST的API調用來存儲和檢索資料。HTTP的使用是靈活的，因為可以從網路上的任何地方（局部或廣域）訪問資料，然而，與訪問存儲在橫向擴展檔案系統中的資料相比，應用程式必須被編碼以使用物件存儲。 因此，供應商已開始向其產品添加NFS和SMB支援，允許通過標準的基於檔的協定存儲和檢索資料。為了完全支持向外擴展功能，支持應包括並行檔案系統。
擴展協定支援意味著可以輕鬆地移植或修改現有應用程式，以便為其資料使用物件存儲。還值得考慮的是，與橫向擴展檔存儲相比，通過使用類比檔存儲的物件存儲提供的體系結構之間的差異。 底層資料不是使用基於inode和目錄的結構存儲的，因此系統崩潰後FSCK（檔案系統掃描）的概念不適用。與傳統檔案系統相比，這對支援檔案系統的物件存儲的可擴展性和性能有很大的影響。
協定支援還需要擴展到實際採用的情況或行業標準。對於物件存儲，這意味著使用S3和Swift，這兩個已經獲得廣泛流行的"標準"。亞馬遜早在2006年就發佈了S3（簡單存儲服務）平臺進入物件市場，使得S3 API成為許多供應商選擇遵循的標準，因為它已經成熟和全面。Swift從OpenStack專案的物件存儲元件中進行開發。
擁有權總成本
沒有對價格和TCO的討論，物件存儲的摘要是完不完整的。 最明顯的許可模式是基於容量的模式 - 向平臺添加更多可用或原始容量，並以實際增量支付更多許可證。供應商還可以選擇為每個節點收費，這意味著最終使用者需要確保他們部署的硬體提供盡可能大的容量。
還有一個按功能收費的選項，雖然一些供應商將看到創建一個全面的收費結構，包括所有功能選項的機會。從終端使用者的角度來看，這顯然更具競爭力，但是隱藏的額外成本可能是一個問題。
計算TCO提出了一個關於物件存儲平臺效率的有趣問題。 橫向擴展節點設計採用計算，系統記憶體和磁片或快閃記憶體存儲來提供一定量的使用者容量。當構建白盒硬體時，軟體的效率與構建解決方案的成本直接相關。到目前為止，沒有實際的基準來比較物件存儲的效率，這仍然是一個需要一些發展的領域。
結論
我們強調了物件存儲的九個關鍵特性。供應商將以補充其產品架構的方式實現這些功能。在決定哪些平臺是您的業務中使用的平臺時，其中一些關鍵功能的評級將高於其他平臺。 這裡列出的清單沒有特定的順序。 然而，作為一個潛在客戶，目標應該是通過這個清單，確定那些重要的功能，值得投入更多的調查。