Cloud Storage (GCS)
通常在上傳 GCS 時，若是遇到大檔案，通常會使用 parallel 的方式 去做上傳。簡單來說就是呼叫一個 api ，然後由 api 幫你去做切檔、上傳、上傳後組合的動作這樣～ （但這不是今天要講的主題ＸＤ）
針對大量細碎的小檔案 上傳 GCS 時，有可能會出現一個稱為 sequential naming bottleneck 的已知狀況。
這狀況會導致 GCS 的上傳效能大大的降低！
GCS 在上傳時，由於底層運作方式會根據檔名去做 shard，因此如果是一些很相近的檔名，且幾乎是流水號的方式去命名的資料，就會遇到這樣問題/狀況～
即使檔案很小，但由於還是都把資料塞進同一個儲存空間(shard)(可以簡單理解為這樣)，因此該儲存空間就會變得很忙碌，進而影響整體的效能。
建議處理方式
如果是檔名很相近的檔案們，就盡量不要用流水號或 timestamp 的方式去命名，加點 hash 或 uuid 的方式都很好，至少會是亂碼，不會是連續性的數字。另外，檔案怎麼放，也是可以避免這樣的效能瓶頸的唷～
想知道更詳盡的資訊，可以參考[1][2]。
那多大的量可以稱為大量呢？
GCP文件裡[3]指出， 通常
- 寫入時，每秒 1000 個物件。此處的寫入，指的是上傳跟刪除。
- 讀取時，每秒 5000 個物件。
就算大量！不過這是軟上限可調整的～
調整的方式除了透過 support 以外
還可以透過學習（？）的方式自動擴展（？？？？）
文件[4]裡提到，可以打到接近上述 1000 or 5000 的上限，然後打一陣子後，再試試看超過上限的打打看ＸＤＤＤＤ
這部分我真的沒試過ＸＤＤＤＤＤ 但文件讀起來就是這樣的港覺啊啊啊啊啊啊
有玩過的捧油們，歡迎試過後再跟我說[1] https://cloud.google.com/blog/products/gcp/optimizing-your-cloud-storage-performance-google-cloud-performance-atlas
[2] https://cloud.google.com/storage/docs/request-rate#naming-convention
[3] https://cloud.google.com/storage/docs/request-rate#auto-scaling
[4] https://cloud.google.com/storage/docs/request-rate#ramp-up
S3
至於 S3 ，看起來是沒有所謂的 sequential naming bottleneck 的名詞ＸＤ
不過，文件[11]中有提到
For example, your application can achieve at least 3,500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requests per second per partitioned prefix
又，S3 也是個 blob storage ，因此理應 S3 也是使用 shard 的～
因此，這種因為檔名太相近造成塞進同一個 shard 造成效能低落的狀況，也會出現在 AWS。
看起來在 AWSprefix 就是 shard 的方式
什麼是 prefix ? 在 S3 裡面，我的理解就是 bucket 後，檔名前的這串文字（可以來[12]看更細唷ＸＤ）
例如：有一個 bucket name=doc123，在裡面的 abc/def folder 中放了一個 xyz.txt 的檔
這個檔案的全路徑就會是 s3://doc123/abc/def/xyz.txt
那對我來說 prefix 就是 /abc/def 這樣
所以嚴格說來，跟 GCS 遇到的 sequential naming bottleneck 狀況是一樣的
建議處理方式
如同[11]裡面的 sample 提到的 每個prefix 每秒可以獲得
- 可接收 3500 新增修改的 request
- 讀取 5500 個 request
所以，如果要提升 bottleneck 那就多加 prefix 就好啊ＸＤ
因此，如果有超級大量的細碎檔案要上傳的需求，可能就要仔細思考 prefix 的長相～ 因為會跟你的 S3 的效能有關係！
[11] https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html
[12] https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#jobprefix
以上為學習心得，有問題歡迎討論 ，有錯也不吝指正：）