本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
評估 DAX是否適合您的使用案例
本節說明使用 的時間和原因DAX。使用此指南可協助您判斷DAX與 DynamoDB 整合是否有利於應用程式的工作負載模式、效能需求和資料一致性需求。它還涵蓋DAX可能不適合的案例，例如寫入量高的工作負載和不常存取的資料。
選擇的時間和原因 DAX
您可以考慮在幾個案例中DAX新增至應用程式堆疊。例如，使用 DAX 來降低 DynamoDB 讀取請求的整體延遲，或將資料表中相同資料的重複讀取降至最低。下列清單顯示您可以利用DAX與 DynamoDB 整合的案例範例：
-
高效能需求
-
低延遲讀取 – DAX 如果您的應用程式需要以微秒為單位的回應時間，以便最終一致讀取，您應該考慮使用 。DAX 也可以大幅縮短存取經常讀取資料的回應時間。
-
-
讀取密集型工作負載
-
讀取密集型應用程式 – 對於高 read-to-write比率的應用程式，例如 10：1 或更高，DAX會導致更多快取命中和更少的過時資料。這可減少對資料表的讀取。若要避免在應用程式寫入密集時從快取讀取過時的資料，請務必在 DynamoDB 中使用存留時間 （TTL）為快取設定較低的值。
-
快取常見查詢 – 如果您的應用程式經常讀取相同的資料，例如電子商務平台上的熱門產品， DAX可以直接從其快取提供這些請求。
-
-
繁忙流量模式
-
更順暢的資料表擴展 – DAX有助於平穩化流量飆升的影響。DAX 提供緩衝，可正常擴展 DynamoDB 資料表容量，進而降低讀取限流的風險。
-
每個項目的讀取輸送量更高 – DynamoDB 會為每個項目配置個別分割區。不過，當項目達到 3，000 個讀取容量單位 （） 時，分割區會開始調節項目的讀取。RCUDAX 可讓您將單一項目的讀取量擴展至超過 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 資料表執行完整資料表掃描。
-
強大的一致性或交易需求 – 將強烈的一致性讀取和TransactGetItems呼叫DAX傳遞至 DynamoDB 資料表。您應該在DAX叢集周圍進行這些讀取，以避免使用叢集資源。以這種方式讀取的項目不會快取；因此，透過 路由此類項目DAX沒有用途。
-
具有適度效能需求的簡單應用程式 – 對於具有適度效能需求和直接 DynamoDB 延遲容差的應用程式，DAX可能不需要新增的複雜性和成本。DynamoDB 本身可處理高輸送量並提供單位數毫秒效能。
-
金鑰值存取以外的複雜查詢需求 – DAX 已針對金鑰值存取模式進行最佳化。如果您的應用程式需要具有複雜篩選的複雜查詢功能，例如查詢和掃描操作，DAX快取利益可能會受到限制。
在這些情況下，請使用 Amazon ElastiCache （RedisOSS） 作為替代方案。 ElastiCache （Redis OSS） 支援進階資料結構，例如清單、集和雜湊。它還提供功能，例如 pub/sub、地理空間索引和指令碼。
-
合規要求 – 目前DAX不提供與 DynamoDB 相同的合規認證。例如， DAX 尚未取得 SOC 認證。
