2017-04-05 66 views
13

將文件上傳到Google雲端存儲時,會有一個自定義數據字段metadataGoogle雲端存儲中的元數據值的長度是否有限制?

Google's example是相當短的:

var metadata = { 
    contentType: 'application/x-font-ttf', 
    metadata: { 
    my: 'custom', 
    properties: 'go here' 
    } 
}; 

file.setMetadata(metadata, function(err, apiResponse) {}); 

是否有GCS有多大允許的元數據對象最大,我應該要存儲的焦油和zip文件,或幾百KB體現在那裏?

+0

您可以嘗試,但是無論如何,元數據存儲都會以正常速率進行計數和計費。 –

+0

關鍵是要在那裏放置一些東西,讓我知道我是否需要3Gig文件... – Paul

+0

這是無證的,只有誰試過或工程師知道。你爲什麼不嘗試在其中放入3GB? –

回答

9

使用下面的命令來上傳元數據集在GCS:

$ echo '{"metadata": {"large": "' > body ; tr -dC '[:print:]' < /dev/urandom | tr -d '\\"' | head -c SIZE_OF_METADATA_IN_BYTES >> body ; echo '"}}' >> body; curl -H "Authorization: Bearer $(gcloud auth print-access-token)" -X PATCH -H "Content-type: application/json" -d @body -o return_body https://www.googleapis.com/storage/v1/b/manifest-geode-357/o/empty 

我發現上面2097KB頭中的服務回報「HTTP 413請求太大」和元數據未設置。低於該水平時,按預期設定。如果我使用更多的可壓縮輸入(例如yes的輸出),我可以獲得更多的數據,但截止點具有相同的內容長度值(這是壓縮後)。正如2097KB == 2MiB幾乎完全一樣,我期望真正的限制是整個HTTP請求必須適合2MiB。


但是布蘭登的評論是正確的:這是不適合的原因,整個目錄一個好主意:

  1. 這將導致你消耗更多的帶寬(與相關的性能和成本損失)
  2. 您不會節省任何存儲成本(因爲元數據仍然收取費用)。
  3. 它依賴於未經記錄的行爲,Google可能會對其進行更改,恕不另行通知。
  4. 與真實對象數據不同,上傳時不存在可恢復的行爲,所以錯誤對您造成更大的影響。
  5. 在上傳過程中沒有校驗和來驗證完整性。
  6. 很可能許多客戶端庫將元數據存儲在內存中而不是磁盤上或保留多個副本,因此您更有可能在應用程序中看到內存壓力。

只需將清單存儲在單獨的對象中即可解決所有這些問題。您可以將清單的位置位置存儲在元數據中,並獲得這兩個選項的好處。

+0

字母「ABC」一遍又一遍地重複將gzip相當好。 1MB的「ABC」通過gzip變成只有1KB。如果數據更隨機一些,會發生什麼? – Paul

+0

使用'tr -dC'[:print:]' David

+0

這對我來說已經夠用了。儘管如此,賞金卻被其他人放置。 – Paul

相關問題