全部產品
Search
文件中心

:OSS效能與擴充性最佳實務

更新時間:Feb 28, 2024

如果您在上傳大量檔案(Object)時,在命名上使用了順序首碼(如時間戳記或字母順序),可能會出現大量檔案索引集中儲存於儲存空間(Bucket)中的某個特定分區的情況。此時如果您的請求次數過多,會導致請求速率下降。出現此類問題時,建議您為檔案名稱增加隨機首碼。

背景資訊

OSS按照檔案名稱UTF-8編碼的順序對使用者資料進行自動分區,從而能夠處理海量檔案並承載高速率的客戶請求。但是,OSS限制了在順序讀寫入模式下,每秒請求數QPS的值為2,000。如果您在上傳大量檔案時,在命名上使用了順序首碼(如時間戳記或字母順序),可能會導致大量檔案索引集中儲存於某個特定分區。關於單個帳號QPS的更多資訊,請參見使用限制

例如,當您的請求速率超過2000次/秒時(下載、上傳、刪除、拷貝、擷取中繼資料資訊等操作算1次操作,大量刪除N個檔案、列舉N個檔案等操作算N次操作),會帶來如下後果:

  • 該分區成為熱點分區,導致分區的I/O能力被耗盡,或被系統自動限制請求速率。
  • 熱點分區的存在會觸發系統進行持續的分區資料再均衡,這個過程可能會延長請求處理時間。
    說明 分區資料再均衡是依賴於對當前系統狀態、處理能力等資訊做各種智能分析後進行的,並不是某個固定的拆分規則。所以分區資料再均衡後,使用了順序首碼的檔案可能還會處於高熱點的分區當中。

為解決以上問題,您可以通過將檔案名稱的順序首碼改為隨機性首碼,這樣檔案索引(以及I/O負載)就會均勻地分布在多個分區。

解決方案

以下提供了兩個將順序首碼改為隨機性首碼的方法。

  • 向檔案名稱添加十六進位雜湊首碼

    如果您使用日期與客戶ID組建檔案名,則會包含順序時間戳記首碼:

    sample-bucket-01/2017-11-11/customer-1/file1
    sample-bucket-01/2017-11-11/customer-2/file2
    sample-bucket-01/2017-11-11/customer-3/file3
    ...
    sample-bucket-01/2017-11-12/customer-2/file4
    sample-bucket-01/2017-11-12/customer-5/file5
    sample-bucket-01/2017-11-12/customer-7/file6
    ...

    針對這種情況,您可以對客戶ID計算雜湊(即MD5),並取若干字元的雜湊首碼作為檔案名稱的首碼。假如取4個字元的雜湊首碼,結果如下:

    sample-bucket-01/9b11/2017-11-11/customer-1/file1
    sample-bucket-01/9fc2/2017-11-11/customer-2/file2
    sample-bucket-01/d1b3/2017-11-11/customer-3/file3
    ...
    sample-bucket-01/9fc2/2017-11-12/customer-2/file4
    sample-bucket-01/f1ed/2017-11-12/customer-5/file5
    sample-bucket-01/0ddc/2017-11-12/customer-7/file6
    ...

    加入4個字元組成的十六進位雜湊作為首碼,則每個字元有0~9以及a~f共16種取值,4個字元共有16 4=65536種可能的字元組合。那麼在儲存系統中,這些資料理論上會被持續劃分至最多65536個分區,以每個分區操作2000次/秒的效能瓶頸標準,再結合您業務的請求速率,可以評估hash桶的個數是否合適。

    如果您想要列出檔案名稱中帶有特定日期的檔案,例如列出sample-bucket-01裡帶有2017-11-11的檔案,您只要對sample-bucket-01進行列舉(即通過多次調用ListObject介面,分批次地獲得sample-bucket-01下的所有檔案),然後合并帶有該日期的檔案即可。

  • 反轉檔案名稱

    如果您使用了毫秒精度的Unix時間戳記組建檔案名,同樣屬於順序首碼:

    sample-bucket-02/1513160001245.log
    sample-bucket-02/1513160001722.log
    sample-bucket-02/1513160001836.log
    sample-bucket-02/1513160001956.log
    ...
    sample-bucket-02/1513160002153.log
    sample-bucket-02/1513160002556.log
    sample-bucket-02/1513160002859.log
    ...

    這種情況可以考慮通過反轉時間戳記首碼來避免檔案名稱包含順序首碼,反轉後結果如下:

    sample-bucket-02/5421000613151.log
    sample-bucket-02/2271000613151.log
    sample-bucket-02/6381000613151.log
    sample-bucket-02/6591000613151.log
    ...
    sample-bucket-02/3512000613151.log
    sample-bucket-02/6552000613151.log
    sample-bucket-02/9582000613151.log
    ...

    由於檔案名稱中的前3位元字代表毫秒時間,會有1000種取值。而第4位元字,每1秒鐘就會改變一次。同理第5位元字每10秒鐘就會改變一次。以此類推,反轉檔案名稱後,極大地增強了首碼的隨機性,從而將負載壓力均勻地分攤在各個分區上,避免出現效能瓶頸。