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

# 評估 DAX 是否適用於您的使用案例
<a name="evaluate-dax-suitability"></a>

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

**Topics**
+ [選擇 DAX 的時機與原因](#choose-dax)
+ [何時不使用 DAX](#dax-unsuitable-scenarios)

## 選擇 DAX 的時機與原因
<a name="choose-dax"></a>

您可在多種情境下考慮將 DAX 新增至應用程式堆疊。例如，可使用 DAX 降低 DynamoDB 讀取請求的整體延遲，或減少資料表中相同資料的重複讀取。以下列出可透過整合 DAX 與 DynamoDB 取得效益的典型情境：
+ **高效能需求**
  + **低延遲讀取** – 若應用程式的最終一致讀取需達微秒級回應時間，建議考慮使用 DAX。DAX 也能顯著縮短存取常用資料的回應時間。
+ **讀取密集型工作負載**
  + **讀取密集型應用程式** – 對於讀寫比高的應用程式 (例如 10:1 或以上)，DAX 可帶來更多快取命中並減少過時資料。這可減少對資料表的讀取次數。若應用程式以寫入為主，為避免從快取讀取過時資料，請確保為快取設定較低的 [使用 DynamoDB 的存留時間 (TTL) 功能](TTL.md)。
  + **快取常見查詢** – 若應用程式頻繁讀取相同資料 (如電子商務平台上的熱門商品)，DAX 可直接從快取回應這些請求。
+ **高載流量模式**
  + **平滑資料表擴展** – DAX 有助於緩解突發流量高峰的影響。DAX 提供緩衝機制，可使 DynamoDB 資料表容量平順擴展，降低讀取限流風險。
  + **每項資料的較高讀取輸送量** – DynamoDB 會為每項資料配置獨立分割區。不過，當分割區達到 3,000 個[讀取容量單位](provisioned-capacity-mode.md#read-write-capacity-units) (RCU) 時，會開始對項目的讀取進行限流。DAX 可讓單一項目的讀取擴展至超過 3,000 個 RCU。
+ **成本最佳化**
  + **降低 DynamoDB 成本** – 從 DAX 讀取可減少送往 DynamoDB 資料表的讀取請求，直接降低成本。當快取命中率高時，資料表讀取成本的節省可能超過 DAX 叢集成本，實現整體成本降低。
+ **資料一致性需求**
  + **最終一致性** – DAX 支援最終一致讀取。因此，DAX 適用於對即時一致性要求不高的使用案例。
  + **寫入快取** – 對 DAX 進行的寫入為[寫入通過](DAX.consistency.md)方式。當 DAX 確認項目已寫入 DynamoDB 後，會將該版本保留於項目快取中。此寫入通過機制有助於維持快取與資料庫間更高的資料一致性，但會消耗額外的 DAX 叢集資源。

## 何時不使用 DAX
<a name="dax-unsuitable-scenarios"></a>

雖然 DAX 功能強大，但並非適用於所有情境。以下列出不建議將 DAX 與 DynamoDB 整合的典型情境：
+ **寫入密集型工作負載** – DAX 主要優勢在於加速讀取，但寫入會消耗比讀取更多的 DAX 資源。若應用程式以寫入為主，DAX 帶來的效益可能有限。
+ **不常讀取資料** – 若應用程式不常存取資料，或需處理大量冷資料 (很少重複使用的資料)，可能會導致較低的 [cache hit ratio](pres-guide-monitor-dax.md#cachehitratio)。在此情況下，維護快取的額外負擔可能不足以抵銷效能提升的效益。
+ **大量讀取或寫入** – 如果您的應用程式執行的大量寫入操作多於個別寫入，應在 DAX 外部直接進行寫入。另外，針對大量讀取，應直接對 DynamoDB 資料表執行完整資料表掃描。
+ **高度一致性或交易需求** – DAX 會將高度一致性讀取及 [TransactGetItems](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactGetItems.html) 呼叫傳送至 DynamoDB 資料表。這些讀取應繞過 DAX 叢集，以避免佔用叢集資源。以此方式讀取的項目不會被快取，因此將這類項目經由 DAX 路由沒有任何意義。
+ **效能需求適中的簡單應用程式** – 若應用程式能容忍直接連線至 DynamoDB 所造成的延遲，則無需額外導入 DAX 的複雜性與成本。DynamoDB 本身可處理高輸送量，並提供個位數毫秒級效能。
+ **超出金鑰值存取的複雜查詢需求** – DAX 已針對金鑰值存取模式進行最佳化。若應用程式需要具備複雜篩選的進階查詢功能，例如[查詢](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Query.html)或[掃描](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Scan.html)操作，則 DAX 的快取效益可能有限。

  在此情況下，建議改用 [Amazon ElastiCache (Redis OSS)](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) 作為替代方案。ElastiCache (Redis OSS) 支援進階資料結構，例如清單、集合與雜湊。亦提供 pub/sub、地理空間索引及指令碼等功能。
+ **合規需求** – DAX 目前尚未具備與 DynamoDB 相同層級的合規認證。例如，DAX 尚未通過 SOC 認證。