使用 DynamoDB 零 ETL 整合和 OpenSearch Service 的最佳實務 - Amazon DynamoDB
組態可觀測性擴展

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

使用 DynamoDB 零 ETL 整合和 OpenSearch Service 的最佳實務

DynamoDB 具有與 Amazon OpenSearch Service 的 DynamoDB 零 ETL 整合。如需詳細資訊，請參閱適用於 OpenSearch Ingestion 的 DynamoDB 外掛程式和適用於 Amazon OpenSearch Service 的特定最佳實務。

組態

  • 只針對您要執行搜尋的資料編製索引。一律使用映射範本 (template_type: index_template 和 template_content) 和 include_keys 來實作此操作。

  • 監控日誌是否有與類型衝突相關的錯誤。OpenSearch Service 預期指定索引鍵的所有值都具有相同的類型。如果不相符，則會產生例外狀況。如果遇到這類錯誤，您可以新增處理器，以捕捉指定的索引鍵是否一律具有相同的值。

  • document_id 值通常使用 primary_key 中繼資料值。在 OpenSearch Service 中，文件 ID 等同於 DynamoDB 中的主索引鍵。使用主索引鍵可讓您輕鬆尋找文件，並確保更新一致複寫至其中，不會發生衝突。

    您可以使用協助程式函數 getMetadata 取得您的主索引鍵 (例如 document_id: "${getMetadata('primary_key')}")。如果您使用的是複合主鍵，協助程式函數會為您將它們串連在一起。

  • 一般而言，action 設定請使用 opensearch_action 中繼資料值。這將確保複寫更新時，OpenSearch Service 中的資料符合 DynamoDB 的最新狀態。

    您可以使用協助程式函數 getMetadata 取得您的主索引鍵 (例如 action: "${getMetadata('opensearch_action')}")。針對篩選等使用案例，您也可以透過 dynamodb_event_name 取得串流事件類型。不過，您通常不應該將其用於 action 設定。

可觀測性

  • 一律在 OpenSearch 接收器上使用無效字母佇列 (DLQ) 來處理捨棄的事件。DynamoDB 通常不如 OpenSearch Service 結構化，而且總是可能發生非預期的情況。透過無效字母佇列，您可以復原個別事件，甚至自動化復原程序。這可協助您避免需要重建整個索引。

  • 一律設定複寫延遲不超過預期數值的提醒。假設一分鐘提醒不會太吵，通常是安全的。根據寫入流量的尖峰程度，以及管道上的 OpenSearch Compute Unit (OCU) 設定，可能有所不同。

    如果您的複寫延遲超過 24 小時，串流會開始捨棄事件，除非從頭開始完整重建索引，否則會有準確性問題。

擴展

  • 針對管道使用自動擴展，以協助擴展或縮減 OCU，使其最適合工作負載。

  • 對於沒有自動擴展功能的已佈建輸送量資料表，建議您根據寫入容量單位 (WCU) 除以 1000 來設定 OCU。將最小值設定為低於該數量 1 個 OCU (但至少 1 個)，並將最大值設定為高於該數量至少 1 個 OCU。

    • 公式：

      OCU_minimum = GREATEST((table_WCU / 1000) - 1, 1)
OCU_maximum = (table_WCU / 1000) + 1

    • 範例：您的資料表已佈建 25000 WCU。管道的 OCU 應設定為最小值 24 (25000/1000 - 1)，最大值至少 26 (25000/1000 + 1)。

  • 對於具有自動擴展功能的已佈建輸送量資料表，建議根據您的最小和最大 WCU 除以 1000 來設定 OCU。將最小值設定為低於 DynamoDB 最小值 1 個 OCU，並將最大值設定為至少高於 DynamoDB 最大值 1 個 OCU。

    • 公式：

      OCU_minimum = GREATEST((table_minimum_WCU / 1000) - 1, 1)
OCU_maximum = (table_maximum_WCU / 1000) + 1

    • 範例：您的資料表具有自動擴展政策，最小值為 8000，最大值為 14000。您管道的 OCU 應設定為最小值 7 (8000/1000 - 1)，最大值 15 (14000/1000 + 1)。

  • 對於隨需輸送量資料表，建議您根據每秒寫入請求單位的典型尖峰和低谷值來設定 OCU。您可能需要針對較長的時段進行平均，具體取決於您可用的彙總。將最小值設定為低於 DynamoDB 最小值 1 個 OCU，並將最大值設定為至少高於 DynamoDB 最大值 1 個 OCU。

    • 公式：

      # Assuming we have writes aggregated at the minute level
OCU_minimum = GREATEST((min(table_writes_1min) / (60 * 1000)) - 1, 1)
OCU_maximum = (max(table_writes_1min) / (60 * 1000)) + 1

    • 範例：您的資料表的平均谷值為每秒 300 次寫入請求單位，平均峰值為 4300。管道的 OCU 應設定為最小值 1 (300/1000 - 1，但至少為 1)，最大值 5 (4300/1000 + 1)。

  • 遵循擴展目的地 OpenSearch Service 索引的最佳實務。如果您的索引規模不足，則會減慢從 DynamoDB 擷取的速度，並可能導致延遲。

注意

GREATEST 是 SQL 函數，給定一組引數後，會傳回具有最大值的引數。