亞馬遜雲存儲之S3(Simple Storage Service簡單存儲服務)

(轉 )

S3是Simple Storage Service的縮寫，即簡單存儲服務。亞馬遜的名詞縮寫也都遵循這個習慣，例如Elastic Compute Cloud縮寫為EC2等等。其他組織類似的命名有W3C，如果我們也follow這個習慣則IEEE會被寫為IE3，CCTV就是C2TV，好像有點羅嗦了。

S3說的玄乎一點可以叫雲存儲，通俗一點就是大網盤。其概念類似于分布式文家系統，同Google的GFS應該在一個層面。

S3的定義如下

Amazon S3 is a web service that enables you to store data in the cloud. You can then download the data or use the data with other AWS services, such as Amazon Elastic Cloud Computer (EC2).

看來除了做網盤隻用，S3存儲的資料還可以被其他的亞馬遜高層服務直接引用，這一點比國内的簡單的網盤提供商高不少，亞馬遜大網盤是其整體Solution中的有機組成部分。

基本概念

1。bucket – 類比于檔案系統的目錄

A bucket is a Container for objects stored in Amazon S3. Every object is contained in a bucket. For example, if the object named photos/puppy.jpg is stored in the johnsmith bucket, then it is addressable using the URL http://johnsmith.s3.amazonaws.com/photos/puppy.jpg

似乎目錄不能嵌套，也就是不能有子目錄，官方的說法是起到namespace的作用，是通路控制的基本機關，其實丫還是個目錄。

2。Object – 類比檔案系統的檔案

對象中帶有對象名名，對象屬性，對象本身最大5G，其實也還是個檔案。

目前object有Versioning的屬性（即對象不同曆史版本的cache概念），這個是檔案系統不具備的，在早期看到的S3資料中沒有這一概念，應該是演進的結果，其面對的應該是有版本控制的需求的使用者。

3。Keys – 類比檔案名

key的樣式也是URL，記住亞馬遜的服務都是使用Web Service或REST方式通路的。

例如，http://doc.s3.amazonaws.com/2006-03-01/AmazonS3.wsdl

其中‘doc’就是目錄名（桶名），”2006-03-01/AmazonS3.wsdl”是檔案名（對象名）。

如果引入了version則bucket + key + version唯一标示一個版本的檔案。

4。Versioning – 類比CVS中的一個版本

下面是一些實作原理的描述。

<圖檔缺失…>

同名檔案的寫入，并不覆寫已有檔案而是增加了一個最新的檔案版本。

同樣下面的删除也不真正删除，而是mark了删除标記。

<圖檔缺失…>

當最新版本mark為deleted之後，對該對象的get操作傳回404錯誤，除非明确指定一個曆史版本。

當然也可以指定版本永久删除其中一個拷貝。

5。Regions – 檔案存儲的地理位置

這個也是檔案系統中不存在的，就是不同的地理區域，使用者可以指定将檔案存在某個國家的伺服器。我個人認為，這不是一個很好的概念，作為雲的提供商，應該對于應用屏蔽這些部署細節。工程實作同技術理想還是有差距。目前其可以指定的server位置有美國、愛爾蘭、新加坡等地。

接口API

常用的API就是讀、寫、增、删、改、查等等。使用标準的SOAP和REST定義。

尤其一提的是對于對象的擷取，除了用http直接按照C/S方式擷取之外，亞馬遜支援BT協定，也就是說提供種子。從使用者角度想，亞馬遜會 charge更少的錢，但同時亞馬遜自身也會減負。bt下載下傳的速度就不太穩定了，基本取決于種子“品質”也就是取決于對檔案感興趣的人的多寡。例如命名為 “XX門”估計檔案下載下傳能夠快很多。

資料有什麼用

當資料上傳到aws雲之後，可以很多服務可以使用例如。

Amazon ElasticCompute Cloud

Amazon Elastic MapReduce

Amazon Import/Export等。

一點遺憾

沒有看到如何實作分布式檔案系統的資料，這是了解其Scale以及可靠性等的關鍵，或許亞馬遜沒有google大方，沒有提供類似GFS之類的底層機制實作文檔。

參考

http://aws.amazon.com/s3/#functionality

http://docs.amazonwebservices.com/AmazonS3/2006-03-01/

http://developer.amazonwebservices.com/connect/forum.jspa?forumID=24

http://www.kernelchina.org/content/%E4%BA%9A%E9%A9%AC%E9%80%8A%E4%BA%91%E5%AD%98%E5%82%A8%E4%B9%8Bs3simple-storage-service%E7%AE%80%E5%8D%95%E5%AD%98%E5%82%A8%E6%9C%8D%E5%8A%A1

三個理由告訴你對象存儲替換HDFS還不錯

原因一：對象存儲可提供更好的資料保護 雖然HDFS能夠利用内部的伺服器級存儲，它實際上是按照其标準的資料保護政策将所有資料做了三個副本。是以，盡管可以使用較便宜的伺服器内部的硬碟驅動器，它可能并不像最初希望的那樣經濟，因為容量需求要乘以3。

一種替代方案是使用基于對象的存儲系統，提供亞馬遜簡單存儲服務（S3）協定通路，這是Hadoop除了HDFS也同樣支援的。這些系統可以是純軟體，是以可以使用商用伺服器和伺服器級存儲。但不同于預設的HDFS，許多對象存儲系統都提供糾删編碼。這種資料保護機制類似于RAID但粒度更細，可以在對象或子對象的層面操作，把資料和奇偶校驗位分布到存儲叢集的各個節點上。其結果是，可以達到相似或更高水準的資料備援性，而隻需大約25％至30％的額外開銷。相比之下， HDFS的标準三副本配置下的額外容量開銷為200％。

原因二：HDFS會暴露主節點

HDFS具有一個主節點和一系列從節點。從節點處理資料并将結果發送給主節點。主節點還需要維護資料複制政策以及基本的叢集管理。如果主節點發生故障，叢集的其餘節點将不能被通路。 HDFS對主節點隻提供了有限的保護，是以企業需要采取特殊措施來實作主節點的高可用性。

如上所述，在對象存儲系統中，主節點與從節點都能受到相同的糾删編碼的資料保護。此外，由主節點維護的管理Hadoop叢集所需的所有中繼資料(metadata)都可以存儲在集中化的對象存儲系統中。這樣當主節點發生故障時，從節點或備用節點可以迅速變成為主節點。

原因三：HDFS不能進行單獨擴充

像任何其他架構一樣，Hadoop對計算和存儲容量也會有不同程度的需求。問題是，HDFS要求計算能力和存儲容量需要按比例進行擴充，這意味着你不能單獨對某一種資源進行擴充。

要說明這一點最常見的方式是當一個Hadoop架構的存儲容量用盡時，因為增加更多容量就意味着加入另一個裝滿硬碟的節點，這也增加了更多的計算能力。反之亦如此，作為Hadoop基礎設施，往往需要更多的處理能力，但存儲空間卻很充裕。大多數時候，當購置了一個新的伺服器以增加計算能力時，它也帶來了新的存儲空間。其結果是，Hadoop架構總是在某種資源上浪費金錢，而對另一種資源卻總是缺乏。

對象存儲允許容量和計算能力各自獨立地進行擴充。計算節點可以是1U或2U的機箱，通過固态存儲引導。對象存儲系統可以裝滿高容量驅動器，進而保持每GB成本最低。更重要的是，随着應用環境的變化，每一層都可以獨立擴充。

HDFS之于Hadoop的主要優點是低成本和高性能，這得益于資料存放于本地。而利用商業存儲硬體的對象存儲系統同樣可以提供類似的低成本，尤其是當采用糾删編碼來提高資料保護效率時更是如此。10 GbE的高速網絡現在已經很實惠，這些都使HDFS将資料和計算放在一起所帶來的性能優勢不複存在。對象存儲提供了一種更具成本效益，更可靠，而且性能至少跟HDFS相當的基礎架構，它理所當然應該成為一種可行的HDFS替代解決方案。