評估 DAX 是否適用於您的使用案例 - Amazon DynamoDB
選擇 DAX 的時機與原因何時不使用 DAX

評估 DAX 是否適用於您的使用案例

本節說明 DAX 的使用時機與原因。使用本指南可協助您判斷，整合 DAX 與 DynamoDB 是否有助滿足應用程式的工作負載模式、效能與資料一致性需求。本指南亦說明 DAX 不適用的情境，例如寫入密集的工作負載或低頻存取資料。

選擇 DAX 的時機與原因

您可在多種情境下考慮將 DAX 新增至應用程式堆疊。例如，可使用 DAX 降低 DynamoDB 讀取請求的整體延遲，或減少資料表中相同資料的重複讀取。以下列出可透過整合 DAX 與 DynamoDB 取得效益的典型情境：

  • 高效能需求

    • 低延遲讀取 – 若應用程式的最終一致讀取需達微秒級回應時間，建議考慮使用 DAX。DAX 也能顯著縮短存取常用資料的回應時間。

  • 讀取密集型工作負載

    • 讀取密集型應用程式 – 對於讀寫比高的應用程式 (例如 10:1 或以上)，DAX 可帶來更多快取命中並減少過時資料。這可減少對資料表的讀取次數。若應用程式以寫入為主，為避免從快取讀取過時資料，請確保為快取設定較低的 使用 DynamoDB 的存留時間 (TTL) 功能。

    • 快取常見查詢 – 若應用程式頻繁讀取相同資料 (如電子商務平台上的熱門商品)，DAX 可直接從快取回應這些請求。

  • 高載流量模式

    • 平滑資料表擴展 – DAX 有助於緩解突發流量高峰的影響。DAX 提供緩衝機制，可使 DynamoDB 資料表容量平順擴展，降低讀取限流風險。

    • 每項資料的較高讀取輸送量 – DynamoDB 會為每項資料配置獨立分割區。不過，當分割區達到 3,000 個讀取容量單位 (RCU) 時，會開始對項目的讀取進行限流。DAX 可讓單一項目的讀取擴展至超過 3,000 個 RCU。

  • 成本最佳化

    • 降低 DynamoDB 成本 – 從 DAX 讀取可減少送往 DynamoDB 資料表的讀取請求，直接降低成本。當快取命中率高時，資料表讀取成本的節省可能超過 DAX 叢集成本，實現整體成本降低。

  • 資料一致性需求

    • 最終一致性 – DAX 支援最終一致讀取。因此，DAX 適用於對即時一致性要求不高的使用案例。

    • 寫入快取 – 對 DAX 進行的寫入為寫入通過方式。當 DAX 確認項目已寫入 DynamoDB 後，會將該版本保留於項目快取中。此寫入通過機制有助於維持快取與資料庫間更高的資料一致性，但會消耗額外的 DAX 叢集資源。

何時不使用 DAX

雖然 DAX 功能強大，但並非適用於所有情境。以下列出不建議將 DAX 與 DynamoDB 整合的典型情境：

  • 寫入密集型工作負載 – DAX 主要優勢在於加速讀取，但寫入會消耗比讀取更多的 DAX 資源。若應用程式以寫入為主，DAX 帶來的效益可能有限。

  • 不常讀取資料 – 若應用程式不常存取資料，或需處理大量冷資料 (很少重複使用的資料)，可能會導致較低的 cache hit ratio。在此情況下，維護快取的額外負擔可能不足以抵銷效能提升的效益。

  • 大量讀取或寫入 – 如果您的應用程式執行的大量寫入操作多於個別寫入，應在 DAX 外部直接進行寫入。另外，針對大量讀取，應直接對 DynamoDB 資料表執行完整資料表掃描。

  • 高度一致性或交易需求 – DAX 會將高度一致性讀取及 TransactGetItems 呼叫傳送至 DynamoDB 資料表。這些讀取應繞過 DAX 叢集，以避免佔用叢集資源。以此方式讀取的項目不會被快取，因此將這類項目經由 DAX 路由沒有任何意義。

  • 效能需求適中的簡單應用程式 – 若應用程式能容忍直接連線至 DynamoDB 所造成的延遲，則無需額外導入 DAX 的複雜性與成本。DynamoDB 本身可處理高輸送量，並提供個位數毫秒級效能。

  • 超出金鑰值存取的複雜查詢需求 – DAX 已針對金鑰值存取模式進行最佳化。若應用程式需要具備複雜篩選的進階查詢功能，例如查詢或掃描操作，則 DAX 的快取效益可能有限。

    在此情況下，建議改用 Amazon ElastiCache (Redis OSS) 作為替代方案。ElastiCache (Redis OSS) 支援進階資料結構，例如清單、集合與雜湊。亦提供 pub/sub、地理空間索引及指令碼等功能。

  • 合規需求 – DAX 目前尚未具備與 DynamoDB 相同層級的合規認證。例如，DAX 尚未通過 SOC 認證。