最佳化 S3 Express One Zone 效能的最佳實務 - Amazon Simple Storage Service
目錄儲存貯體的運作方式最佳實務效能故障診斷目錄儲存貯體操作和目錄互動範例

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

最佳化 S3 Express One Zone 效能的最佳實務

建置從 Amazon S3 Express One Zone 上傳和擷取物件的應用程式時，請依照我們的最佳實務指導方針來最佳化效能。若要使用 S3 Express One Zone 儲存類別，您必須建立 S3 目錄儲存貯體。S3 Express One Zone 儲存類別不支援搭配 S3 一般用途儲存貯體使用。

如需所有其他 Amazon S3 儲存類別和 S3 一般用途儲存貯體的效能指導方針，請參閱 最佳實務設計模式：最佳化 Amazon S3 效能。

為了在大規模工作負載中使用 S3 Express One Zone 儲存類別和目錄儲存貯體獲得最佳效能和可擴展性，請務必了解目錄儲存貯體的運作方式與一般用途儲存貯體不同。然後，我們提供最佳實務，讓您的應用程式與目錄儲存貯體的運作方式保持一致。

目錄儲存貯體的運作方式

Amazon S3 Express One Zone 儲存類別可支援每個目錄儲存貯體高達 2，000，000 GET 和每秒高達 200，000 PUT 交易 (TPS) 的工作負載。使用 S3 Express One Zone，資料會存放在可用區域的 S3 目錄儲存貯體中。目錄儲存貯體中的物件可在階層式命名空間內存取，類似於檔案系統，與具有一般命名空間的 S3 一般用途儲存貯體相反。與一般用途儲存貯體不同的是，目錄儲存貯體是以階層方式將索引鍵組織成目錄，而非字首。字首是物件索引鍵名稱開頭的字元字串。您可以使用字首來整理資料，並管理一般用途儲存貯體中的平面物件儲存架構。如需詳細資訊，請參閱使用字首整理物件。

在目錄儲存貯體中，物件會在階層式命名空間中使用斜線 (/) 做為唯一支援的分隔符號。當您使用 等金鑰上傳物件時dir1/dir2/file1.txt， 目錄和 dir1/ dir2/ 會自動由 Amazon S3 建立和管理。目錄會在 PutObject或 CreateMultiPartUpload操作期間建立，並在 DeleteObject或 AbortMultiPartUpload操作之後變成空白時自動移除。目錄中的物件和子目錄數量沒有上限。

物件上傳到目錄儲存貯體時建立的目錄可以立即擴展，以減少 HTTP 503 (Slow Down)錯誤的機會。這種自動擴展可讓您的應用程式視需要在目錄內和目錄之間平行處理讀取和寫入請求。對於 S3 Express One Zone，個別目錄旨在支援目錄儲存貯體的最大請求速率。您不需要隨機化金鑰字首來獲得最佳效能，因為系統會自動分配物件以均勻的負載分佈，但因此，金鑰不會以文字方式存放在目錄儲存貯體中。這與 S3 一般用途儲存貯體相反，因為在語義上更接近的金鑰更有可能共置在相同的伺服器上。

如需目錄儲存貯體操作和目錄互動範例的詳細資訊，請參閱 目錄儲存貯體操作和目錄互動範例。

最佳實務

遵循最佳實務來最佳化目錄儲存貯體效能，並協助您的工作負載隨時間擴展。

使用包含許多項目的目錄 （物件或子目錄）

目錄儲存貯體預設為所有工作負載提供高效能。若要在某些操作中進一步最佳化效能，將更多項目 （即物件或子目錄） 合併到目錄中會導致更低的延遲和更高的請求率：

  • 變更 API 操作，例如 PutObject、 DeleteObjectCreateMultiPartUpload和 AbortMultiPartUpload，在使用包含數千個項目的較少、更密集的目錄，而非大量較小的目錄實作時，可達到最佳效能。

  • ListObjectsV2 當需要周遊較少的目錄以填入結果頁面時， 操作效能會更好。

請勿在字首中使用熵

在 Amazon S3 操作中，熵是指字首命名中的隨機性，可協助跨儲存分割區平均分配工作負載。不過，由於目錄儲存貯體會在內部管理負載分佈，因此不建議在字首中使用熵來獲得最佳效能。這是因為對於目錄儲存貯體，如果不重複使用已建立的目錄，熵可能會導致請求變慢。

等金鑰模式最終$HASH/directory/object可能會建立許多中繼目錄。在下列範例中，所有 job-1 都是不同的目錄，因為其父系不同。目錄會稀疏且變動，而清單請求會較慢。在此範例中，有 12 個中繼目錄都有單一項目。

s3://my-bucket/0cc175b9c0f1b6a831c399e269772661/job-1/file1
  
s3://my-bucket/92eb5ffee6ae2fec3ad71c777531578f/job-1/file2
  
s3://my-bucket/4a8a08f09d37b73795649038408b5f33/job-1/file3
  
s3://my-bucket/8277e0910d750195b448797616e091ad/job-1/file4
  
s3://my-bucket/e1671797c52e15f763380b45e841ec32/job-1/file5
  
s3://my-bucket/8fa14cdd754f91cc6554c9e71929cce7/job-1/file6

相反地，為了獲得更好的效能，我們可以移除$HASH元件並允許 job-1成為單一目錄，從而改善目錄的密度。在下列範例中，與上一個範例相比，具有 6 個項目的單一中繼目錄可以獲得更好的效能。

s3://my-bucket/job-1/file1
  
s3://my-bucket/job-1/file2
  
s3://my-bucket/job-1/file3
  
s3://my-bucket/job-1/file4
  
s3://my-bucket/job-1/file5
  
s3://my-bucket/job-1/file6

發生此效能優勢是因為當最初建立物件金鑰且其金鑰名稱包含目錄時，會自動為物件建立目錄。後續物件上傳到同一個目錄時，就不需要建立目錄，這樣可以減少物件上傳至現有目錄的延遲。

如果您不需要在ListObjectsV2呼叫期間對物件進行邏輯分組的能力，請使用分隔符號 / 以外的分隔符號來分隔金鑰的部分

由於/分隔符號是專門針對目錄儲存貯體處理，因此應該刻意使用。雖然目錄儲存貯體不會以詞典方式排序物件，但目錄中的物件仍會在ListObjectsV2輸出中分組在一起。如果您不需要此功能，您可以將 / 取代為另一個字元做為分隔符號，以免造成中繼目錄的建立。

例如，假設下列金鑰處於YYYY/MM/DD/HH/字首模式

s3://my-bucket/2024/04/00/01/file1
  
s3://my-bucket/2024/04/00/02/file2
  
s3://my-bucket/2024/04/00/03/file3
  
s3://my-bucket/2024/04/01/01/file4
  
s3://my-bucket/2024/04/01/02/file5
  
s3://my-bucket/2024/04/01/03/file6

如果您不需要在ListObjectsV2結果中按小時或天數分組物件，但需要按月分組物件，則 的下列金鑰模式YYYY/MM/DD-HH-將大幅減少目錄，並提高ListObjectsV2操作的效能。

s3://my-bucket/2024/04/00-01-file1
  
s3://my-bucket/2024/04/00-01-file2
  
s3://my-bucket/2024/04/00-01-file3
  
s3://my-bucket/2024/04/01-02-file4
  
s3://my-bucket/2024/04/01-02-file5
  
s3://my-bucket/2024/04/01-02-file6

盡可能使用分隔清單操作

沒有 的ListObjectsV2請求會delimiter執行所有目錄的深度優先遞迴周遊。具有 的ListObjectsV2請求只會delimiter擷取 prefix 參數所指定目錄中的項目，從而減少請求延遲並增加每秒的彙總金鑰。對於目錄儲存貯體，請盡可能使用分隔清單操作。分隔清單會導致存取目錄的次數減少，這會導致每秒更多金鑰和較低的請求延遲。

例如，針對目錄儲存貯體中的下列目錄和物件：

s3://my-bucket/2024/04/12-01-file1
  
s3://my-bucket/2024/04/12-01-file2
  
...
  
s3://my-bucket/2024/05/12-01-file1
  
s3://my-bucket/2024/05/12-01-file2
  
...
  
s3://my-bucket/2024/06/12-01-file1
  
s3://my-bucket/2024/06/12-01-file2
  
...
  
s3://my-bucket/2024/07/12-01-file1
  
s3://my-bucket/2024/07/12-01-file2
  
...

為了獲得更好的ListObjectsV2效能，如果您應用程式的邏輯允許，請使用分隔清單列出子目錄和物件。例如，您可以針對分隔清單操作執行下列命令，

aws s3api list-objects-v2 --bucket my-bucket --prefix '2024/' --delimiter '/'

輸出是子目錄的清單。

{
    "CommonPrefixes": [
        {
            "Prefix": "2024/04/"
        },
        {
            "Prefix": "2024/05/"
        },
        {
            "Prefix": "2024/06/"
        },
        {
            "Prefix": "2024/07/"
        }
    ]
}

若要列出具有更佳效能的每個子目錄，您可以執行如下範例的命令：

命令：

aws s3api list-objects-v2 --bucket my-bucket --prefix '2024/04' --delimiter '/'

輸出：

{
    "Contents": [
        {
            "Key": "2024/04/12-01-file1"
        },
        {
            "Key": "2024/04/12-01-file2"
        }
    ]
}

將 S3 Express One Zone 儲存與您的 運算資源共置

使用 S3 Express One Zone，每個目錄儲存貯體都位於您在建立儲存貯體時選取的單一可用區域中。您可以透過在運算工作負載或資源所在位置的可用區域中建立新的目錄儲存貯體來著手進行。然後就能立即開始非常低延遲的讀取和寫入。目錄儲存貯體是一種 S3 儲存貯體，您可以在其中選擇 中的可用區域 AWS 區域 ，以減少運算和儲存之間的延遲。

如果您跨可用區域存取目錄儲存貯體，您可能會遇到稍微增加的延遲。為了達到最佳效能，建議您盡可能從位於相同可用區域中的 Amazon Elastic Container Service、Amazon Elastic Kubernetes Service 和 Amazon Elastic Compute Cloud 執行個體存取目錄儲存貯體。

使用並行連線，以超過 1MB 的物件達到高輸送量

您可以向目錄儲存貯體發出多個並行請求，以將請求分散到不同的連線上來獲得最大可存取頻寬，藉此達到最佳效能。與一般用途儲存貯體一樣，S3 Express One Zone 對您的目錄儲存貯體的連線數目沒有任何限制。當同一目錄發生大量並行寫入時，個別目錄可以水平和自動擴展效能。

目錄儲存貯體的個別 TCP 連線在每秒可上傳或下載的位元組數上具有固定的上限。當物件變大時，請求時間會由位元組串流主導，而不是交易處理。若要使用多個連線平行處理大型物件的上傳或下載，您可以減少end-to-end延遲。如果使用 Java 2.x SDK，您應該考慮使用 S3 Transfer Manager，這將利用效能改進，例如分段上傳 API 操作和位元組範圍擷取，以平行存取資料。

使用閘道 VPC 端點

閘道端點提供從 VPC 到目錄儲存貯體的直接連線，而不需要網際網路閘道或 VPC 的 NAT 裝置。若要減少封包在網路上花費的時間，您應該使用目錄儲存貯體的閘道 VPC 端點來設定 VPC。如需詳細資訊，請參閱目錄儲存貯體的網路。

使用工作階段身分驗證，並在工作階段字符有效時重複使用它們

目錄儲存貯體提供工作階段字符身分驗證機制，以減少效能敏感 API 操作的延遲。您可以對 進行單一呼叫CreateSession，以取得工作階段字符，然後在接下來 5 分鐘內對所有請求有效。若要在 API 呼叫中取得最低延遲，請務必取得工作階段字符，並在重新整理字符之前的整個生命週期內重複使用該字符。

如果您使用 AWS SDKs，軟體SDKs會自動處理工作階段字符重新整理，以避免工作階段過期時服務中斷。我們建議您使用 AWS SDKs來啟動和管理對 CreateSession API 操作的請求。

如需 CreateSession 的相關資訊，請參閱 使用 CreateSession 授權區域端點 API 操作。

使用 CRT 型用戶端

AWS Common Runtime (CRT) 是一組以 C 撰寫的模組化、高效能和高效程式庫，旨在做為 AWS SDKs 的基礎。CRT 提供更高的輸送量、增強的連線管理，以及更快的啟動時間。CRT 可透過 Go 以外的所有 AWS SDKs 使用。

如需如何為所使用的 SDK 設定 CRT 的詳細資訊，請參閱AWS 通用執行期 (CRT) 程式庫、使用 AWS 通用執行期加速 Amazon S3 輸送量、在適用於 Java 的 AWS SDK 2.x 中介紹 CRT 型 S3 用戶端和 S3 Transfer Manager、使用適用於 Amazon S3 操作的 S3CrtClient，以及設定 AWS CRT 型 HTTP 用戶端。

使用最新版本的 AWS SDKs

AWS SDKs 為許多最佳化 Amazon S3 效能的建議準則提供內建支援。SDKs提供更簡單的 API，可從應用程式內利用 Amazon S3，並定期更新以遵循最新的最佳實務。例如，SDKs會在 HTTP 503錯誤後自動重試請求，並處理慢速連線回應。

如果使用 Java 2.x SDK，您應該考慮使用 S3 Transfer Manager，它會自動水平擴展連線，以適時使用位元組範圍請求實現每秒數千個請求。位元組範圍請求可以改善效能，因為您可以使用 S3 的並行連線，從相同物件中擷取不同的位元組範圍。與單一整個物件請求相比，這可協助您實現更高的彙總傳輸量。因此，請務必使用最新版本的 AWS SDKs來取得最新的效能最佳化功能。

效能故障診斷

您是否正在為延遲敏感的應用程式設定重試請求？

S3 Express One Zone 專為提供一致的高效能水準而打造，無需額外調整。但是，設定有利的逾時值和重試次數，可進一步協助實現一致的延遲和效能。 AWS SDKs 具有可設定的逾時和重試值，您可以根據特定應用程式的公差進行調整。

您是否使用 AWS 通用執行期 (CRT) 程式庫和最佳的 Amazon EC2 執行個體類型？

執行大量讀取和寫入操作的應用程式，可能會比未執行這些操作的應用程式需要更多的記憶體或運算能力。為要求高效能的工作負載啟動 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體時，請選擇符合應用程式所需資源量的執行個體類型。S3 Express One Zone 高效能儲存最適合搭配較大和較新的執行個體類型，這些類型具備更大量的系統記憶體，以及更強大的 CPU 和 GPU，可充分利用效能更高的儲存。我們也建議使用最新版本的 CRT 啟用 AWS SDKs，這可以更好地平行加速讀取和寫入請求。

您是否使用 AWS SDKs進行工作階段型身分驗證？

透過 Amazon S3，您也可以遵循 AWS SDKs 的相同最佳實務，在使用 HTTP REST API 請求時最佳化效能。不過，透過 S3 Express One Zone 所使用的工作階段型授權和身分驗證機制，我們強烈建議您使用 AWS SDKs來管理 CreateSession及其受管工作階段字符。使用 CreateSession API 操作， AWS SDKs 會自動代表您建立和重新整理權杖。使用 CreateSession可節省對 AWS Identity and Access Management (IAM) 的每次請求往返延遲，以授權每個請求。

目錄儲存貯體操作和目錄互動範例

以下顯示目錄儲存貯體如何運作的三個範例。

範例 1：對目錄儲存貯體的 S3 PutObject請求如何與目錄互動

  1. 在空儲存貯體中PUT(<bucket>, "documents/reports/quarterly.txt")執行操作時，會建立儲存貯體根documents/目錄中的目錄、documents/建立 reports/ 中的目錄，以及reports/建立 quarterly.txt中的物件。針對此操作，除了 物件之外，還會建立兩個目錄。

    圖表顯示 的 PUT 操作之後的目錄結構 documents/reports/quarterly.txt

  2. 然後，PUT(<bucket>, "documents/logs/application.txt")執行另一個操作時，目錄documents/已存在、 logs/中的目錄documents/不存在且已建立，並logs/建立 application.txt中的物件。針對此操作，除了 物件之外，還只建立一個目錄。

    圖表顯示 的 PUT 操作之後的目錄結構 documents/logs/application.txt

  3. 最後，執行PUT(<bucket>, "documents/readme.txt")操作時，根documents/目錄中的目錄已存在並readme.txt建立 物件。對於此操作，不會建立目錄。

    圖表顯示 的 PUT 操作之後的目錄結構 documents/readme.txt

範例 2：對目錄儲存貯體的 S3 ListObjectsV2請求如何與目錄互動

對於未指定分隔符號的 S3 ListObjectsV2請求，會以深度優先的方式周遊儲存貯體。輸出會以一致順序傳回。不過，雖然此順序在請求之間保持不變，但順序不是詞典。對於在上一個範例中建立的儲存貯體和目錄：

  1. 執行 LIST(<bucket>) 時，documents/會輸入 目錄並開始周遊。

  2. logs/ 輸入子目錄，並開始周遊。

  3. 您可以在 application.txt中找到 物件logs/。

  4. 內沒有其他項目logs/。清單操作會從 結束logs/，然後documents/再次進入。

  5. documents/ 目錄會繼續周遊，並readme.txt找到 物件。

  6. documents/ 目錄會繼續周遊，並reports/輸入子目錄，然後開始周遊。

  7. 物件quarterly.txt可在 中找到reports/。

  8. 內沒有其他項目reports/。清單從 結束reports/，然後documents/再次進入。

  9. 內不存在任何項目，documents/清單會傳回。

在此範例中， logs/ 是在 之前排序readme.txtreadme.txt，而在 之前排序reports/。

範例 3：對目錄儲存貯體的 S3 DeleteObject請求如何與目錄互動

顯示 DELETE 操作之前初始目錄結構的圖表

  1. 在該相同的儲存貯體中，DELETE(<bucket>, "documents/reports/quarterly.txt")執行操作時，會quarterly.txt刪除物件，將目錄保留reports/空白，並導致立即刪除。documents/ 目錄不是空的，因為它內同時有目錄logs/和物件readme.txt，因此不會刪除它。對於此操作，只會刪除一個物件和一個目錄。

    顯示 DELETE 操作後目錄結構的圖表 documents/reports/quarterly.txt

  2. DELETE(<bucket>, "documents/readme.txt") 執行操作時，會readme.txt刪除物件。 documents/ 仍然不是空的，因為它包含目錄 logs/，因此不會刪除它。對於此操作，不會刪除任何目錄，只會刪除物件。

    顯示 DELETE 操作後目錄結構的圖表 documents/readme.txt

  3. 最後，DELETE(<bucket>, "documents/logs/application.txt")執行操作時， application.txt 會刪除，並保留logs/空白並導致立即刪除。這會保留documents/空白，並立即將其刪除。對於此操作，會刪除兩個目錄和一個物件。儲存貯體現在為空。

    顯示 DELETE 操作後目錄結構的圖表 documents/logs/application.txt