設定 DAX 叢集
DAX 叢集為受管型叢集，但仍可依應用程式需求調整其組態。由於 DAX 與 DynamoDB API 操作緊密整合，在整合應用程式時應考量以下面向。
DAX 定價
叢集成本取決於其已佈建節點的數量與大小。每個節點在叢集中執行的每小時均會產生費用。如需詳細資訊，請參閱 Amazon DynamoDB
快取命中不會產生 DynamoDB 成本，但仍會佔用 DAX 叢集資源。快取未命中會產生 DynamoDB 讀取成本，並消耗 DAX 資源。寫入操作會產生 DynamoDB 寫入成本，且會佔用 DAX 叢集資源以代理該寫入。
項目快取與查詢快取
DAX 維護項目快取與查詢快取。了解這些快取的差異有助於判斷它們為應用程式提供的效能與一致性特性。
| 快取特性 | 項目快取 | 查詢快取 |
|---|---|---|
|
用途 |
儲存 GetItem 與 BatchGetItem API 操作的結果。 |
|
|
存取類型 |
使用鍵值型存取。 當應用程式使用 |
使用參數式存取。 DAX 會快取 |
|
快取失效 |
在下列情況下，DAX 會自動將更新後的項目複寫至 DAX 叢集中各節點的項目快取。
|
查詢快取的失效管理比項目快取更具挑戰。項目更新可能無法直接對應至已快取的查詢或掃描。必須謹慎調整查詢快取的 TTL，以維持資料一致性。透過 DAX 或基礎資料表進行的寫入，不會反映於查詢快取中，直到 TTL 過期並由 DAX 對 DynamoDB 重新執行查詢。 |
|
全域次要索引 |
由於本機次要索引與全域次要索引不支援 GetItem API 操作，因此項目快取僅快取基礎資料表的讀取。 |
查詢快取會同時快取針對資料表與索引的查詢。 |
選擇快取的 TTL 設定
TTL 決定資料在變為過時前可儲存在快取中的時間長度。期間結束後，資料會於下次請求時自動更新。為 DAX 快取選擇合適的 TTL 設定需在應用程式效能最佳化與資料一致性間取得平衡。由於沒有適用於所有應用程式的通用 TTL 設定，最佳 TTL 應依應用程式的特性與需求而定。建議依本指南從保守的 TTL 設定起步。接著依應用程式效能資料與洞察逐步調整 TTL 設定。
DAX 會為項目快取維護一個最近最少使用 (LRU) 清單。LRU 清單會追蹤項目首次寫入或最近一次從快取讀取的時間。當 DAX 節點記憶體已滿時，DAX 會移出較舊項目 (無論是否過期)，以釋放空間存放新項目。LRU 演算法一律啟用，且無法由使用者設定。
若要設定適用於應用程式的 TTL 持續時間，請考量以下重點：
了解資料存取模式
-
大量讀取工作負載 – 對於讀取頻繁且資料更新較少的應用程式，建議設定較長的 TTL 持續時間，以降低快取未命中的次數。較長的 TTL 持續時間亦可減少對底層 DynamoDB 資料表的存取需求。
-
大量寫入工作負載 – 若應用程式頻繁更新且未經 DAX 寫入，應設定較短的 TTL 持續時間，以維持快取與資料庫一致性。較短的 TTL 持續時間亦可降低提供過時資料的風險。
評估應用程式效能需求
-
延遲敏感度 – 若應用程式重視延遲低於資料即時性，應設定較長的 TTL 持續時間。較長的 TTL 持續時間可最大化快取命中率，進而降低平均讀取延遲。
-
輸送量和可擴展性 – 較長的 TTL 持續時間可降低 DynamoDB 資料表負載，提升輸送量與可擴展性。然而，仍須在即時資料需求與上述因素之間取得平衡。
分析快取移出與記憶體使用量
-
快取記憶體限制 – 監控 DAX 叢集的記憶體使用量。較長的 TTL 持續時間可使快取儲存更多資料，可能導致達到記憶體上限並觸發 LRU 式移出。
使用監控指標調整 TTL
定期檢閱指標，例如快取命中與未命中次數，以及 CPU 與記憶體使用率。依據這些指標調整 TTL 設定，以取得效能與資料即時性間的最佳平衡。若快取未命中率高且記憶體使用率低，應延長 TTL 持續時間以提升快取命中率。
考量業務需求與合規要求
資料保留政策可能規定敏感或個人資訊可設定的 TTL 最長時限。
TTL 設為零時的快取行為
當 TTL 設為 0 時，項目快取與查詢快取會呈現以下行為：
-
項目快取 – 僅於發生 LRU 移出或寫入操作時，快取中的項目才會更新。
-
查詢快取 – 查詢回應不會被快取。
使用 DAX 叢集以快取多個資料表
若工作負載包含多個不需個別快取的小型 DynamoDB 資料表，可使用單一 DAX 叢集來快取這些資料表的請求。這讓 DAX 的使用更具彈性與效率，特別適用於需存取多個資料表並要求高效能讀取的應用程式。
與 DynamoDB 的資料平面 API 類似，DAX 請求需指定資料表名稱。若在同一個 DAX 叢集中使用多個資料表，無需額外設定。但必須確保叢集的安全權限允許存取所有快取資料表。
使用 DAX 搭配多個資料表時的考量事項
使用 DAX 搭配多個 DynamoDB 資料表時，應考量以下要點：
-
記憶體管理 – 使用 DAX 搭配多個資料表時，應評估工作資料集的總大小。資料集內所有資料表將共用所選節點類型的記憶體空間。
-
資源配置 – DAX 叢集的資源會由所有快取資料表共同使用。不過，高流量的資料表可能會迫使相鄰的小型資料表資料被移出。
-
規模經濟 – 將較小資源整合成較大的 DAX 叢集，以平衡流量並維持穩定模式。就 DAX 叢集的總讀取資源而言，配置三個以上節點較具成本效益。這同時能提升叢集中所有快取資料表的可用性。
DAX 與 DynamoDB 全域資料表中的資料複寫
DAX 是區域型服務，因此叢集僅能感知其 AWS 區域 內的流量。全域資料表在從其他區域複寫資料時，會繞過快取進行寫入。
較長的 TTL 持續時間可能使過時資料在次要區域保留時間長於主要區域。這可能導致次要區域的本機快取發生遺漏。
下圖顯示來源區域 A 內全域資料表層級的資料複寫。區域 B 的 DAX 叢集不會立即察覺來源區域 A 新複寫的資料。
DAX 區域可用性
並非所有支援 DynamoDB 資料表的區域都支援 DAX 叢集部署。若應用程式需透過 DAX 以達低讀取延遲，請先檢閱支援 DAX 的區域清單。接著，為 DynamoDB 資料表選擇適當的區域。
DAX 快取行為
DAX 會執行中繼資料快取與負快取。了解這些快取行為有助於您有效管理快取項目及負快取項目的屬性中繼資料。
-
中繼資料快取 – DAX 叢集會無限期保留快取項目屬性名稱的中繼資料。即使項目過期或被從快取中移出，該中繼資料仍會保留。
若應用程式使用無限制數量的屬性名稱，長期下來可能導致 DAX 叢集記憶體耗盡。此限制僅適用於頂層屬性名稱，不適用於巢狀屬性名稱。無限制屬性名稱的例子包括時間戳記、UUID 和工作階段 ID。雖然您可以將時間戳記和工作階段 ID 用作屬性值，但建議使用較短且可預測的屬性名稱。
-
負快取 – 當發生快取未命中，且從 DynamoDB 資料表讀取不到相符項目時，DAX 會在對應的項目或查詢快取中新增負快取項目。此項目會保留，直到快取 TTL 到期或發生寫入通過。DAX 會在後續請求中持續傳回此負快取項目。
若負快取行為不符合應用程式模式，當 DAX 傳回空結果時，直接讀取 DynamoDB 資料表。另建議設定較短的 TTL 快取時間，以避免快取中長期維持空結果，並提升與資料表的一致性。
