Treasure Data 用 AWS S3的方法
(blog.gslin.org)
kaif
積分 0
aws s3的consistency一直是問題，但即使如此，其他家/各種山寨還是追不到他的車尾燈呀。
IngramChen
積分 2
其實我覺得 gcloud storagr 還不錯。上傳後自動就有 cdn 效果，不用再掛 cloud front。然後新的 nearline 功能也是狂打 glacier 臉...
nearline真的打到aws說不出話來；cdn我是視為google bundle一起賣而已，不算是技術上的優勢。或是有什麼aws辦不到的特異功能？
IngramChen
積分 0
直接內建 cdn 就是上傳 url 等同於下載 url，這樣程式會好處理的多，不用轉來轉去的。我覺得這個功能很殺。
qrtt1
積分 2
車尾燈這回事很難說的。
就像每個人的審美觀不同，而對一個產品的喜好程度會有落差。目前 AWS 流量的價格（特別是亞洲）是線上前 3 名較貴的，而 S3 的儲存費也略貴於其他，而在台灣實際的下載品質很能不是最優的（以公司服務的 log 來說）。
如果看重的是他豐富而完整的 feature，那麼他無疑是領先的。若是單看這個服務的主要「被使用」用途：提供下載服務。在台灣這神奇的網路環境下，即使外掛了 CloudFront 要叫他第一，實在是說不出口啊。
狀態一致性的問題是分散式系統都要面對的，不過在面對之前可以先想一下「這件事對我們的產品來說，重不重要」。
如果開發者真的在意要花多久時間達到一致，那就得乖乖的 log 並觀察問題是否會影響他們的產品。並且運用一下該產品提供的特性，與調整設計來避開一些問題。
以我在開發上多採用只有新增，沒有 update 來利用 S3 非 us-east-1 提供新 object 的 read-after-write 特性，就能避開最終一致性，但在實際的實作上仍會在「重要的」情況，多加幾次 HTTP HEAD 檢查一下有沒有 object。
PS. signed url 就不能打 HTTP HEAD，用 HTTP GET 取代.
kaif
積分 0
是的，CAP需要trade off。以主要object storage廠商來說，aws覺得scale最重要，consist請client自己想辦法；azure blob storage就覺得consist超級重要，所以就作成strong consistent。
read-after-write算是很大的改善，但這篇主要是在complain list object的問題啦
btw, 我映像中signed url 可以head捏～～我記錯了嗎！！
qrtt1
積分 0
可以做個小實驗，弄個 signed url 出來，再對它做 HTTP HEAD:
qty:~ qrtt1$ curl -v -I -X HEAD 'https://s3-ap-southeast-1.amazonaws.com/qty.tmp/e9e3acb6029562f3d69f095261927974.tgz?X-Amz-Date=20150330T204136Z&X-Amz-Expires=300&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Signature=d4414cbefd5bd56849c72eb48cd1afc8a99c5ac44aa9d31f91f1a0199fd2e22d&X-Amz-Credential=ASIAJSCVIGYRJA5YJNBA/20150330/ap-southeast-1/s3/aws4_request&X-Amz-SignedHeaders=Host&x-amz-security-token=AQoDYXdzEE4agAIuZA1qmnpim80oIvcP0N7h78BrNwItM9vkB2Xbez6S1zoxTDHMs1FFh%2B5Hl86JctsglYJj3wYn75i0XM8c15xdMoa53Eax7khC1jFUHR9aaEVj0TNLRdsYKxf53SacgwNE8SHERy1mN2gBgYOjNRJGnSgFJtvQpb9Qd553NnGjJTJjaI2w1TpQ8/zeDWHbzxY8J7RsdfOy0j81GHfiz/lX%2BMXHGKNlVxd1%2BdkTR31sve09RvnUqmsFNC4VaAcpOPQngyiEJTZRGSRa3/eT7hdlSNkdx40Zz02qoRfryrypx7sYxEi1ka7KTxQw5wND9lfZDK70ijPglOZ1q55Fc48oINfp5qgF'
* Hostname was NOT found in DNS cache
* Trying 54.231.241.112...
* Connected to s3-ap-southeast-1.amazonaws.com (54.231.241.112) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
* Server certificate: *.s3-ap-southeast-1.amazonaws.com
* Server certificate: VeriSign Class 3 Secure Server CA - G3
* Server certificate: VeriSign Class 3 Public Primary Certification Authority - G5
> HEAD /qty.tmp/e9e3acb6029562f3d69f095261927974.tgz?X-Amz-Date=20150330T204136Z&X-Amz-Expires=300&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Signature=d4414cbefd5bd56849c72eb48cd1afc8a99c5ac44aa9d31f91f1a0199fd2e22d&X-Amz-Credential=ASIAJSCVIGYRJA5YJNBA/20150330/ap-southeast-1/s3/aws4_request&X-Amz-SignedHeaders=Host&x-amz-security-token=AQoDYXdzEE4agAIuZA1qmnpim80oIvcP0N7h78BrNwItM9vkB2Xbez6S1zoxTDHMs1FFh%2B5Hl86JctsglYJj3wYn75i0XM8c15xdMoa53Eax7khC1jFUHR9aaEVj0TNLRdsYKxf53SacgwNE8SHERy1mN2gBgYOjNRJGnSgFJtvQpb9Qd553NnGjJTJjaI2w1TpQ8/zeDWHbzxY8J7RsdfOy0j81GHfiz/lX%2BMXHGKNlVxd1%2BdkTR31sve09RvnUqmsFNC4VaAcpOPQngyiEJTZRGSRa3/eT7hdlSNkdx40Zz02qoRfryrypx7sYxEi1ka7KTxQw5wND9lfZDK70ijPglOZ1q55Fc48oINfp5qgF HTTP/1.1
> User-Agent: curl/7.37.1
> Host: s3-ap-southeast-1.amazonaws.com
> Accept: */*
>
< HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
< x-amz-request-id: 41201436C5FA04B9
x-amz-request-id: 41201436C5FA04B9
< x-amz-id-2: lyx9cRmrFkr3MbeBzIMKBoOXlQNWoIaUSuTVWnIO23ecE+mWgp1IL3EGwSCZbOqRNu3Y+4+RYVM=
x-amz-id-2: lyx9cRmrFkr3MbeBzIMKBoOXlQNWoIaUSuTVWnIO23ecE+mWgp1IL3EGwSCZbOqRNu3Y+4+RYVM=
< Content-Type: application/xml
Content-Type: application/xml
< Transfer-Encoding: chunked
Transfer-Encoding: chunked
< Date: Mon, 30 Mar 2015 20:49:55 GMT
Date: Mon, 30 Mar 2015 20:49:55 GMT
* Server AmazonS3 is not blacklisted
< Server: AmazonS3
Server: AmazonS3
<
* Connection #0 to host s3-ap-southeast-1.amazonaws.com left intact
實驗結果就是不行，那麼這是為什麼呢？回頭翻手冊就會明白了。 因為 signed url 是連 HTTP 的 Method 一起進去的1，而 signed url 是對 HTTP GET 的動作做 signed url，所以換成用 HEAD 時，比對的資訊就會是錯誤的（簡單說，它在 server side 無法 reproduce 你的計算結果）。
不過 List 難用大家都知道啦，我們都會放個主要的 key 在 db 上，另外以這組 key 的 listing 清單另外放 cassandra 上，算是二層 map 的查詢的做法 (二個 O(1) 就找到資料嚕)，要等 list 不知等到何年何月了。
「signed url 是連 HTTP 的 Method 一起進去的」是正確的，但「 signed url 是對 HTTP GET 的動作做 signed url」應該是有誤的。
AWS的文件1 是以GET為範例，但spec. 上沒有限制只能用GET。故若以HEAD header去sign，再發HEAD request，應該是ok的。
不過我有注意到妳的測試是用v4 signing，這我沒用過，或許以上的說法只在v2有效也說不定～