Amazon DynamoDB 的常見問答集

問：什麼是 Amazon DynamoDB？

Amazon DynamoDB 是全受管 NoSQL 資料庫服務，可提供快速且可預期的效能及無縫的可擴展性。使用 DynamoDB，客戶可以將操作和擴展分散式資料庫的管理重擔交給 AWS，而無須擔心硬體佈建、設定和組態、輸送容量規劃、複寫、軟體修補或叢集擴展等問題。

問：Amazon DynamoDB 可為我管理哪些項目？

Amazon DynamoDB 消除了影響資料庫擴展的主要絆腳石之一，也就是資料庫軟體的管理與執行資料庫所需的硬體佈建。您可在短短幾分鐘之內部署非關聯式資料庫。DynamoDB 會自動擴展輸送容量以符合工作負載需求，並隨著表格大小的成長分割和重新分割資料。此外，DynamoDB 還可在 AWS 區域的三個設施上同步複製資料，提供高可用性和資料耐久性。

問：讀取一致性是什麼意思？為什麼需要注意？

Amazon DynamoDB 將每個表格儲存在分散於各地的三個副本，以實現高可用性和資料耐久性。讀取一致性是指某個資料項目的成功寫入或更新會在何時、以何種方式反映在該資料項目的後續讀取操作中。DynamoDB 所提供的邏輯讓您能夠針對應用程式中的每次讀取請求，指定您需要的一致性特徵。

問：Amazon DynamoDB 的一致性模式是什麼？

使用者從 Amazon DynamoDB 讀取資料時，可以指定最終一致性讀取或是強制一致性讀取：

• 最終一致性讀取 (預設) – 最終一致性選項可以最大程度提高讀取輸送量。但是，最終一致讀取可能不會反映最近完成的寫入操作結果。所有資料副本的一致性通常可在一秒鐘之內完成。稍待一下再讀取，就應該會傳回更新後的資料。
• 強制一致性讀取 – 除了提供最終一致性外，如果您的應用程式或應用程式的某個元素需要，Amazon DynamoDB 還提供您請求強制一致性讀取的彈性和控制能力。強制一致性讀取傳回的結果可反映在讀取前收到成功回應的所有寫入。

問：DynamoDB 是否支援就地不可部分完成更新？

Amazon DynamoDB 支援快速就地更新。您可以使用單一 API 呼叫，遞增或遞減行中的某個數值屬性。同樣地，您也能自動新增或移除設定、清單或映射。如需不可部分完成更新的詳細資訊，請參閱原子計數器。

問：為什麼 Amazon DynamoDB 建置在固態硬碟上？

Amazon DynamoDB 完全在固態硬碟 (SSD) 上執行。SSD 有助於 AWS 實現設計目標，在可預測的低延遲回應時間之內存放和存取任何規模的資料。SSD 的高 I/O (每秒讀取次數和每秒寫入次數很高) 效能可以讓我們以更經濟實惠的方式處理大規模請求工作負載，並將這種成本效益以較低的請求定價提供給客戶。

問：DynamoDB 的儲存成本似乎很高。這是一種合乎成本效益的服務嗎？

和任何其他產品一樣，我們建議 Amazon DynamoDB 的潛在客戶考慮解決方案的整體成本，而不要只侷限於單一定價方式。處理資料庫工作負載的總成本受到兩個因素的影響：請求流量要求和儲存的資料量。大部分資料庫工作負載的特點是，存放的每 GB 資料都需要很高的 I/O (每秒讀取次數和每秒寫入次數很高)。DynamoDB 建置在 SSD 磁碟機上；相較於傳統硬碟機而言，存放每 GB 資料的成本較高，但也讓我們能夠提供非常低的請求成本。根據我們在典型資料庫工作負載方面的經驗，使用 SSD DynamoDB 的總費用一般會比使用傳統硬碟機的關聯式資料庫或非關聯式資料庫的費用還低。如果您需要存放大量不常存取的資料，DynamoDB 可能並不適合您。針對此類使用案例，我們建議您使用 Amazon S3。

您也須注意，儲存成本會反映將每個資料項目的多個副本存放於同一 AWS 區域中多個設施的成本。

問：DynamoDB 是否僅適用於大型應用程式？

否。Amazon DynamoDB 提供無縫的擴展能力，可在應用程式需求增加時自動擴展。如果您在任何規模都需要快速且可預測的效能，則 DynamoDB 可能是您的理想之選。

問：如何開始使用 Amazon DynamoDB？

按一下 "Sign Up" 以立即開始使用 Amazon DynamoDB。然後，您可以使用 AWS 管理主控台或 Amazon DynamoDB API，開始與 Amazon DynamoDB 進行互動。如果您有使用 AWS 管理主控台，可以使用 Amazon DynamoDB 建立表格，只需按幾下即可開始體驗。

問：DynamoDB 支援哪種類型的查詢功能？

Amazon DynamoDB 支援使用使用者定義的主索引鍵來執行 GET/PUT 操作。主索引鍵是表格項目唯一的必要屬性，可唯一識別每個項目。您在建立表格時會指定主索引鍵。除此之外，DynamoDB 還透過使用全域次要索引和本機次要索引，讓您根據非主索引鍵屬性進行查詢，以提供靈活的查詢服務。

主索引鍵可以是單一屬性分區索引鍵或複合的分區排序索引鍵。例如，單一屬性的分區主索引鍵可以是 "UserID"。這使您能夠快速讀取和寫入與特定使用者 ID 關聯的項目資料。

複合的分區排序索引鍵是做為分區索引鍵元素和排序索引鍵元素來編製索引。這個複合鍵可保持第一個元素值和第二個元素值之間的層次結構。例如，複合的分區排序索引鍵可能是 "UserID" (分區) 和 "時間戳記" (排序) 的組合。保持分區索引鍵元素不變，您可以在排序索引鍵元素中搜尋以擷取項目。這讓您可以使用 Query API 執行一些操作，例如，在一個時間戳記範圍中擷取單一 UserID 的所有項目。

如需全域次要索引及其查詢能力的詳細資訊，請參閱常見問答集中的次要索引部分。

 

問：如何使用 Amazon DynamoDB 更新和查詢資料項目？

使用 AWS 管理主控台或 CreateTable API 建立表格之後，您可以使用 PutItem 或 BatchWriteItem API 插入項目。然後，您可以使用 GetItem、BatchGetItem 或 Query API (如果複合主索引鍵已啟用，且正在表格中使用) 擷取新增到表格中的項目。

問：Amazon DynamoDB 是否支援條件式運算？

是，您可以指定一個條件，必須達到該條件才能對項目執行放置、更新或刪除操作。如需執行條件式運算，您可以定義透過以下內容建置的 ConditionExpression：

• 布林值函式：ATTRIBUTE_EXIST、CONTAINS 和 BEGINS_WITH
• 比較運算子：=、<>、<、>、<=、>=、BETWEEN 和 IN
• 邏輯運算子：NOT、AND 和 OR。 

您可以建置一個由多個條件子句 (包括巢狀子句) 組合而成，且不拘形式的條件式表達式。使用者可以透過條件式運算在 DynamoDB 上實作開放式並行控制系統。如需條件式運算的詳細資訊，請參閱我們的文件。

問：索引鍵條件是否支援表達式？

是，您可將表達式指定為 Query 查詢 API 呼叫的一部分，以使用 KeyConditionExpression 參數根據表格上的主索引鍵篩選結果。

問：分區和分區排序索引鍵是否支援表達式？

是，您可以為分區和分區排序索引鍵使用表達式。如需適用於分區和分區排序索引鍵之表達式的詳細資訊，請參閱文件頁面。

問：Amazon DynamoDB 是否支援遞增或遞減操作？

是，Amazon DynamoDB 允許在純量值執行不可部分完成的遞增和遞減操作。

問：在 Amazon RDS 或 Amazon EC2 上，何時該使用 Amazon DynamoDB，何時又該使用關聯式資料庫引擎？

目前的 Web 應用程式會產生和消耗大量資料。例如，某個線上遊戲剛推出時可能只有幾千個使用者，資料庫工作負載很小，每秒進行 10 次寫入和 50 次讀取操作。然而，如果遊戲變得熱門，則可能快速發展到數百萬個使用者，讀寫操作次數達到每秒數萬次甚至每秒數十萬次。每天可能產生數 TB 甚至更多資料。利用 Amazon DynamoDB 開發應用程式，您能夠從較小規模開始，隨著要求的提高而增加表格的請求容量，且不用停機。您只需為所佈建的請求容量支付低廉的費用，並且讓 Amazon DynamoDB 在足夠的伺服器容量上執行資料和流量分割工作，以滿足您的需求。Amazon DynamoDB 會處理好資料庫管理的工作，而您只需要儲存和請求資料即可。自動複寫和容錯移轉功能可提供內建容錯能力、高可用性和資料耐久性。Amazon DynamoDB 能確保您的資料庫全受管並可隨著應用程式要求的提高而擴展，讓您高枕無憂。

儘管 Amazon DynamoDB 解決了資料庫可擴展性、管理、效能以及可靠性等核心問題，但是與任何 NoSQL 一樣，資料模型必須專門針對應用程式所需的存取模式而設計。換言之，在 DynamoDB 上執行臨機查詢可能效率不高。請參閱設計指南，了解如何從任何關聯式資料庫有效地遷移到 DynamoDB。如果您的工作負載需要此功能，或希望與現有關聯式引擎相容，則可能需要在 Amazon RDS 或 Amazon EC2 上執行關聯式引擎。雖然關聯式資料庫提供穩健的特性和功能，但要在單一關聯式資料庫執行個體的基礎上擴展工作負載是非常複雜的，而且需要大量的時間和專業知識。因此，如果您預計會有新應用程式的擴展要求，而且不需要使用關聯式功能，則 Amazon DynamoDB 可能是您的最佳選擇。

問：Amazon DynamoDB 與 Amazon SimpleDB 有何區別？

我該用哪一個？兩種服務都屬於非關聯式資料庫，所以都不需要資料庫管理工作。Amazon DynamoDB 專注在提供可無縫擴展、快速且可預測的效能。其在固態硬碟 (SSD) 上執行以提供低延遲的回應時間，而且特定表格的請求容量或儲存大小不受限制。這是因為 Amazon DynamoDB 會自動在足夠數量的伺服器上對您的資料和工作負載進行分割，以滿足您的擴展要求。相較之下，Amazon SimpleDB 中的表格受到 10 GB 的嚴格儲存限制，能達到的請求容量也受到限制 (通常低於每秒 25 次寫入操作)；如果需要額外擴展，您還要負責管理在額外的 SimpleDB 表格進行分割和重新分割。雖然 SimpleDB 受到擴展限制，但相當適合需要靈活查詢的較小工作負載。Amazon SimpleDB 會自動編製所有項目屬性的索引，因而支援靈活查詢，但這會影響效能和可擴展性。

Amazon 首席技術官 Werner Vogels 的 DynamoDB 部落格文章介紹了 Amazon 非關聯式資料庫技術的詳細發展過程。

問：何時該使用 Amazon DynamoDB，何時又該使用 Amazon S3？

Amazon DynamoDB 可儲存按主索引鍵編製索引的結構化資料，並允許對 1 位元組到 400 KB 範圍內的項目提供低延遲讀取和寫入存取。Amazon S3 儲存非結構化 Blob，適合儲存最大 5 TB 的大型物件。為了優化您使用 AWS 服務的成本，大型物件或不常存取的資料集應儲存在 Amazon S3，而小型資料元素或檔案指標 (可能指向 Amazon S3 物件) 最好儲存在 Amazon DynamoDB。

問：是否任何作業系統上執行的應用程式都能使用 DynamoDB？

是。DynamoDB 是一項全受管的雲端服務，可透過 API 進行存取。任何作業系統 (例如，Linux、Windows、iOS、Android、Solaris、AIX、HP-UX 等) 上執行的應用程式都可使用 DynamoDB。我們建議透過 AWS 開發套件開始使用 DynamoDB。您可以在開發人員資源頁面上找到 AWS 開發套件清單。如果您在安裝或使用其中一個軟體開發套件時遇到困難，您可以將問題發佈到相關的 AWS 論壇以通知我們。

問：什麼是資料模型？

Amazon DynamoDB 的資料模型如下：

表格：表格是資料項目的集合，如同關聯式資料庫中的表格是行的集合。每個表格可以有無限數量的資料項目。Amazon DynamoDB 無結構描述，因此表格中的資料項目不必具有相同的屬性，甚至不必具有相同數量的屬性。每個表格必須有一個主索引鍵。主索引鍵可以是單一屬性鍵，也可以是兩個屬性組合而成的「複合」屬性鍵。每個項目都必須有您指定為主索引鍵的屬性，因為主索引鍵可唯一識別表格中的各個項目。

項目：一個項目中包括一個主索引鍵或複合鍵，以及數量不限的屬性。與單一項目相關聯的屬性數量沒有明確限制，但項目的總大小 (包括所有屬性名稱和屬性值) 不可以超過 400 KB。

屬性：與資料項目相關聯的每個屬性包括屬性名稱 (例如 "Color") 以及一個值或一組值 (例如 "Red" 或 "Red、Yellow、Green")。單一屬性沒有明確大小限制，但項目的總大小 (包括所有屬性名稱和值) 不得超過 400 KB。

問：項目大小是否有限制？

項目的總大小 (包括屬性名稱和屬性值) 不得超過 400 KB。請參閱設計指南，了解如何使用「複合排序索引鍵」設計各種超過 400K 限制的項目。

問：項目可擁有的屬性數量是否有限制？

項目可以擁有的屬性數量不受限制。但是，項目的總大小 (包括屬性名稱和屬性值) 不得超過 400 KB。

問：有哪些 API？

• CreateTable – 建立表格並指定用於資料存取的主索引鍵。
• UpdateTable – 為指定的表格更新佈建的輸送量值。
• DeleteTable – 刪除表格。
• DescribeTable – 傳回表格大小、狀態和索引資訊。
• ListTables – 傳回與目前帳戶和端點相關聯的所有表格清單。
• PutItem – 建立新項目，或以新項目取代舊項目 (包括所有屬性)。如果項目已存在於指定的表格中且有相同的主索引鍵，則新項目將會完全取代現有項目。您還可以使用條件運算子，僅在項目的屬性值符合特定條件時才取代項目，或僅在項目尚未存在時插入新項目。
• BatchWriteItem – 透過單一請求 (而不是單一交易) 插入、取代和刪除多個表格中的多個項目。支援對最多 25 個項目批量執行 Put 或 Delete 操作，最大總請求大小為 16 MB。
• UpdateItem – 編輯現有項目的屬性。您還可以使用條件運算子，僅在項目的屬性值符合特定條件時才進行更新。
• DeleteItem – 依主索引鍵刪除表格中的單一項目。您還可以使用條件運算子，僅在項目的屬性值符合特定條件時才刪除項目。
• GetItem – GetItem 操作可為主索引鍵相符的項目傳回一組屬性。根據預設，GetItem 操作可提供最終一致讀取。如果最終一致讀取不適用於您的應用程式，請使用 ConsistentRead。
• BatchGetItem – BatchGetItem 操作可透過主索引鍵傳回多個表格中多個項目的屬性。單一回應的大小限制為 16 MB，最多傳回 100 個項目。支援強制一致性和最終一致性。
• Query – 利用表格主索引鍵，或利用索引鍵從次要索引中取得一或多個項目。您可以使用比較運算子或表達式縮小表格查詢的範圍。您還可以透過對非索引鍵屬性使用篩選條件來篩選查詢結果。支援強制一致性和最終一致性。單一請求的大小限制為 1 MB。
  
• Scan – 透過對表格或次要索引執行全面掃描來取得所有項目和屬性。您可以透過針對一個或多個屬性指定篩選條件來限制傳回的結果集。
  

問：掃描操作的一致性模式為何？

掃描操作支援最終一致性和一致性讀取。預設情況下，掃描操作具有最終一致性。不過，您可以在 Scan API 呼叫中使用可選的 ConsistentRead 參數，修改一致性模式。將 ConsistentRead 參數設為 true 後，您可以透過掃描操作進行一致性讀取。如需詳細資訊，請參閱掃描操作的文件。

問：掃描操作如何運作？

您可將掃描操作視為一種反覆運算器。一旦特定 Scan API 請求的掃描項目的總大小超過 1 MB 限制，則該特定請求將被終止，擷取的結果將與 LastEvaluatedKey 一同傳回 (以便在後續操作中繼續掃描)。

問：掃描操作是否有任何限制？

表格或次要索引的掃描操作，每個操作有不能超過 1 MB 的大小限制。若超過 1 MB 的限制，其將停止操作並傳回到該點為止的相符結果以及後續操作中要應用的 LastEvaluatedKey，這樣您可以在停止的位置恢復操作。

問：掃描操作一次要消耗多少個讀取容量單位？

所需的讀取單位是掃描操作擷取的位元組數，捨入到最接近的 4 KB，除以 4 KB。採用一致性讀取方式掃描表格佔用的讀取容量是採用最終一致讀取方式進行掃描的兩倍。

問：DynamoDB 支援哪些資料類型？

DynamoDB 支援四種純量資料類型：數字、字串、二進位和布林值。此外，DynamoDB 支援集合資料類型：數字集、字串集、二進位集、異質清單和異質對應。DynamoDB 還支援 NULL 值。

問：DynamoDB 支援哪些類型的資料結構？

DynamoDB 支援鍵值和文件資料結構。

問：什麼是鍵值存放？

鍵值存放是一項資料庫服務，對使用包含實際儲存內容的鍵值和值識別的物件集合提供儲存、查詢和更新支援。

問：什麼是文件存放？

文件存放對使用 JSON、XML 和 HTML 等文件格式的項目提供儲存、查詢和更新支援。

問：DynamoDB 是否有 JSON 資料類型？

否，但您可以使用文件軟體開發套件將 JSON 資料直接傳輸到 DynamoDB 中。DynamoDB 資料類型是受 JSON 支援的資料類型超集合。文件軟體開發套件可將 JSON 文件自動對應到本機 DynamoDB 資料類型。

問：我能否使用 AWS 管理主控台查看和編輯 JSON 文件？

是。AWS 管理主控台提供簡單的使用者界面，用於探索並編輯 DynamoDB 表中儲存的資料，包括 JSON 文件。如需查看或編輯表格中的資料，請登入 AWS 管理主控台，選擇 DynamoDB，選擇您要查看的表格，然後按一下 "Explore Table" 按鈕。

問：在 DynamoDB 中查詢 JSON 資料的方式是否有不同？

否。您可以在任何最上層 JSON 元素上建立全域次要索引或本機次要索引。舉例來說，假設您儲存的 JSON 文件中包含關於某個人的下列資訊：名字、姓氏、郵遞區號及他們所有好友的清單。名字、姓氏和郵遞區號為最上層 JSON 元素。您可以建立一個索引，讓您根據名字、姓氏或郵遞區號進行查詢。好友清單不是最上層元素，因此您不能對該好友清單進行索引。如需全域次要索引及其查詢功能的詳細資訊，請參閱常見問答集中的次要索引部分。

問：如果我的 DynamoDB 中有巢狀 JSON 資料，我能否只擷取該資料的特定元素？

是。當您使用 GetItem、BatchGetItem、Query 或 Scan API 時，可以定義一個 ProjectionExpression，以確定應從表格中擷取哪些屬性。這些屬性可包括 JSON 文件的純量、集合或元素。

問：如果我的 DynamoDB 中有巢狀 JSON 資料，我能否只更新該資料的特定元素？

是。更新 DynamoDB 項目時，可以指定您要更新的 JSON 文件的子元素。

問：什麼是文件軟體開發套件？

文件軟體開發套件是 JavaScript 的資料類型包裝函式，可為 JS 和 DynamoDB 資料類型提供方便的相互操作性。此軟體開發套件可以幫您處理請求的包裝；其與回應類似，可以展開資料類型。如需詳細資訊並下載軟體開發套件，請參考這裡的 GitHub 儲存庫。

 

問：我能夠在 Amazon DynamoDB 儲存的資料量是否有限制？

否。它對您在 Amazon DynamoDB 表格中存放的資料量沒有任何限制。隨著您的資料集不斷成長，Amazon DynamoDB 將自動在充足的機器資源上分置您的資料，以滿足您的儲存需求。

問：單一表格的輸送量是否有限制？

否，您可以增加 Auto Scaling 的最高容量限制設定，或者使用 API 或 AWS 管理主控台增加已經為表格手動佈建的輸送量。DynamoDB 可以處理大規模的資料，而您可以達到的最大輸送量在理論上並沒有限制。DynamoDB 會自動將表格分為多個資料分割，其中每個分割都是一個獨立的平行計算單位。DynamoDB 可以透過新增更多分割，不斷提高輸送率。

如果您希望輸送率超過每秒 10,000 次寫入或每秒 10,000 次讀取，請先填寫此線上表格與 Amazon 聯繫。

問：當 Auto Scaling 觸發擴展或是我變更佈建的輸送量以請求擴展或縮減時，Amazon DynamoDB 是否保持可用？

是。Amazon DynamoDB 的設計可以在擴展或縮減佈建的輸送量時仍然保持可用，無論是由 Auto Scaling 管理還是手動管理皆是如此。

問：使用 Amazon DynamoDB 時是否需要管理用戶端分割？

否。Amazon DynamoDB 免除了跨資料庫表格進行分割的需求，以提升輸送量的可擴展性。

問：Amazon DynamoDB 的可用性有多高？

此服務是在 Amazon 經過驗證的高可用性資料中心執行。而且此服務會在 AWS 區域的三個設施上複製資料，以便在發生伺服器故障或可用區域執行中斷時提供容錯能力。

問：Amazon DynamoDB 如何實現高正常執行時間和耐久性？

為了實現高正常執行時間和耐久性，Amazon DynamoDB 在 AWS 區域的三個設施上同步複製資料。

問：什麼是 DynamoDB Auto Scaling？

DynamoDB Auto Scaling 是一項全受管的功能，可在應用程式要求增加或減少 DynamoDB 表或全域次要索引的佈建讀取和寫入容量時，自動地進行擴展或縮減。

問：為什麼需要使用 Auto Scaling？

Auto Scaling 可讓您免於在建立新表格時猜測需要佈建的適當容量，並減少持續監控使用的輸送量及手動調整佈建容量的操作負擔。Auto Scaling 有助於確保應用程式可用性，並降低未使用的佈建容量的成本。

問：哪些應用程式要求模式和工作負載適合使用 Auto Scaling？

一致、可預測，且連續高或低輸送用量持續數分鐘到數小時的要求模式適合使用 Auto Scaling。

問：如何針對 DynamoDB 表或全域次要索引啟用 Auto Scaling？

從 DynamoDB 主控台建立新表格時，核取 'Use default settings' 選項以啟用 Auto Scaling 功能，並針對表格的全域次要索引套用相同設定。如果取消核取 'Use default settings'，則可以手動設定佈建容量，或使用目標使用率、最低容量及最高容量的自訂值啟用 Auto Scaling。對於現有表格，您可以導覽至 'Capacity' 標籤以啟用 Auto Scaling 或變更現有的 Auto Scaling 設定；對於索引，您可以在 'Indexes' 標籤底下啟用 Auto Scaling。您也可以使用 CLI 或 AWS 開發套件，以程式設計方式管理 Auto Scaling。要進一步了解，請參閱 DynamoDB Developer Guide。

問：Auto Scaling 有哪些設定值可以設定？

Auto Scaling 有三個可設定的設定值：目標使用率，實際使用輸送量在某個時間點佔佈建總輸送量的百分比；最低容量，Auto Scaling 可以縮減的下限；最高容量，Auto Scaling 可以擴展的上限。目標使用率的預設值為 70% (允許的範圍是 20% 到 80%，增量級距為 1%)，最低容量的預設值為 1 個單位，最高容量的預設值為您的帳戶在區域中的表格限制。請參閱 Limits in DynamoDB 頁面，了解區域層次的預設表格限制。

問：是否可以變更現有 Auto Scaling 政策的設定？

是，您可以隨時變更現有 Auto Scaling 政策的設定，方法是導覽至管理主控台的 'Capacity' 標籤，或是從 CLI 或軟體開發套件使用 AutoScaling API 以程式設計方式進行變更。

問：Auto Scaling 如何運作？

當您為 DynamoDB 表建立新的 Auto Scaling 政策時，便會以您指定的目標使用率閾值建立 Amazon CloudWatch 警示，並根據發佈至 CloudWatch 的使用和佈建容量指標加以計算。如果表格的實際使用率偏離目標一段特定的時間，CloudWatch 警示便會啟動 Auto Scaling 對您的政策進行評估，然後對 DynamoDB 進行 UpdateTable API 要求，以動態增加 (或減少) 表格佈建的輸送容量，讓實際使用率更接近目標。

問：是否可以在多個區域中的多個表格啟用單一 Auto Scaling 政策？

否，一個 Auto Scaling 政策只能設定至單一區域內的單一表格或全域次要索引。

問：是否可以強制 Auto Scaling 政策立即擴展至最高容量或縮減為最低容量？

否，不支援立即擴展至最高容量或縮減為最低容量。不過您可以暫時停用 Auto Scaling，手動設定一段時間需要的容量，之後再重新啟用 Auto Scaling。

問：是否可以監控 Auto Scaling 觸發的擴展動作？

您可以在管理主控台的 'Capacity' 標籤以及從 'Metrics' 標籤下的 CloudWatch 圖表監控 Auto Scaling 觸發的擴展動作狀態。

問：如何分辨表格是否有作用中的 Auto Scaling 政策？

從 DynamoDB 主控台按一下左側功能表的 Tables，便會顯示您帳戶中所有 DynamoDB 表的清單檢視。如果是含有作用中 Auto Scaling 政策的表格，'Auto Scaling' 欄位會視 Auto Scaling 針對讀取、寫入或二者啟用而定，分別顯示 READ_CAPACITY、WRITE_CAPACITY 或 READ_AND_WRITE。此外，在表格 'Overview' 標籤的 'Table details' 部分之下，佈建的容量標籤會顯示 Auto Scaling 是針對讀取、寫入或二者啟用。

問：刪除含有作用中政策的表格或全域次要索引時，Auto Scaling 政策會發生什麼事？

當您從主控台刪除表格或全域次要索引時，也會一併刪除其 Auto Scaling 政策和支援的 Cloud Watch 警示。

問：使用 Auto Scaling 是否需要額外費用？

否，除了您已為 DynamoDB 和 CloudWatch 警示支付的費用之外，使用 Auto Scaling 無須額外費用。要了解有關 DynamoDB 定價的資訊，請參閱 DynamoDB 定價頁面。

問：Auto Scaling 管理的輸送容量如何搭配我的預留容量使用？

Auto Scaling 與預留容量搭配使用的方式和目前手動佈建的輸送容量方式相同。預留容量會套用至您購買容量所在區域的總佈建容量。Auto Scaling 佈建的容量會先使用預留容量，依折扣價格計費，任何超過的容量將會依標準費率計費。若要將總使用量限制為您購買的預留容量，請在啟用 Auto Scaling 功能的所有表格分配最高容量限制，讓累計總和低於您購買的總預留容量。

問：什麼是全域次要索引？

全域次要索引是包含分區或分區排序索引鍵的一種索引，可不同於表格的主要索引鍵。

為了有效率的存取表格中的資料，Amazon DynamoDB 會針對主索引鍵屬性建立並維護索引。這可讓應用程式透過指定主索引鍵值來快速擷取資料。然而，許多應用程式也會受益於利用一或多個次要 (或替代) 索引鍵，透過主索引鍵以外的屬性有效率地存取資料。若要這樣做，您可以在表格中建立一或多個次要索引，並針對這些索引發出 Query 請求。

Amazon DynamoDB 支援兩種次要索引：

• 本機次要索引 – 是一種與表格擁有相同分區索引鍵但不同排序索引鍵的索引。本機次要索引之所以稱為「本機」，這是因為它的每個分割的範圍都限制在分區索引鍵相同的表格分割內。
• 全域次要索引 – 一種可與表格分區索引鍵或分區排序索引鍵不同的索引。全域次要索引之所以稱為「全域」，這是因為該索引上的查詢可跨過所有分割，涵蓋表格中的所有項目。 

次要索引由 Amazon DynamoDB 以疏鬆物件的形式自動維護。只有當項目存在於已定義索引的表格中時，這些項目才會出現在索引中。這使得按索引進行查詢變得非常有效率，因為索引中的項目數通常遠遠少於表格中的項目數。

全域次要索引支援非唯一屬性，如此可透過表格中的任何非索引鍵屬性進行查詢，藉此提高查詢的靈活度。

假設某個遊戲應用程式將玩家資訊儲存在 DynamoDB 表中，該表格的主索引鍵由 UserId (分區) 和 GameTitle (排序) 組成。項目中包含名稱為 TopScore、Timestamp、ZipCode 的屬性，以及一些其他屬性。表格建立之後，DynamoDB 會在主索引鍵上提供隱含索引 (主索引)，以便能夠高效地查詢並傳回某個特定使用者在所有遊戲中獲得的最高分。

但是，如果應用程式需要獲得某個特定遊戲的使用者最高分，則使用這種主索引查詢的效率較差，並且需要在整個表格中進行掃描。如果改用全域次要索引以 GameTitle 為分區索引鍵元素，並以 TopScore 為排序索引鍵元素，則應用程式可快速擷取某個遊戲的最高分。

GSI 不需要排序索引鍵元素。例如，您的 GSI 索引鍵可以只有一個分區元素 GameTitle。在下方的範例中，GSI 沒有投影屬性，因此它只會傳回屬性與您正在查詢的 GameTitle 相符的所有項目 (透過主索引鍵識別)。

問：何時應該使用全域次要索引？

如果屬性有許多不同的值，全域次要索引特別適合用來追蹤這些屬性之間的關係。例如，您可以建立一個 DynamoDB 表，將 CustomerID 做為表格的主分區索引鍵，將 ZipCode 做為全域次要索引的分區索引鍵，因為有許多郵遞區號，而且您可能有許多客戶。使用主索引鍵時，您可以快速取得任何客戶的相關記錄。使用全域次要索引時，您可以有效率地查詢居住在指定郵遞區號地區的所有客戶。

為確保能充分利用全域次要索引的能力，請參閱我們提供的統一工作負載的最佳實務文件。

問：如何為 DynamoDB 表建立全域次要索引？

您可以隨時指定與表格關聯的 GSI。如需建立表格及其索引的詳細步驟，請參閱這裡。每個表格最多可以建立 5 個全域次要索引。

問：本機版本的 DynamoDB 是否支援全域次要索引？

是。本機版本的 DynamoDB 對於開發和測試可支援 DynamoDB 的應用程式很實用。您可以在這裡下載本機版本的 DynamoDB。

問：什麼是投影屬性？

次要索引中的資料包括從表格投影或複製到索引中的屬性。建立次要索引時，您需要定義索引的其他索引鍵，以及您希望投影在索引中的其他任何屬性。Amazon DynamoDB 會將這些屬性複製到索引中，並從表格複製主索引鍵屬性。然後，您可以查詢該索引，就像查詢表格一樣。

問：是否可以在非唯一屬性上定義全域次要索引鍵？

是。與表格上的主索引鍵不同，GSI 索引不會要求索引屬性具有唯一性。例如，GameTitle 上的 GSI 可將所有項目編製索引，以追蹤每個遊戲的使用者分數。在此範例中，透過查詢這個 GSI 可以傳回玩過 "TicTacToe" 遊戲的所有使用者。

問：全域次要索引與本機次要索引有何不同？

全域次要索引和本機次要索引都能提高查詢的靈活性。LSI 與特定的分區索引鍵值相關聯，而 GSI 涵蓋所有的分區索引鍵值。由於具有相同分區索引鍵值的項目在 DynamoDB 中共用同一分區，所以「本機」次要索引只會包含存放在同一位置 (相同分區) 的項目。因此，LSI 的目的是查詢具有相同分區索引鍵值、但排序索引鍵值不同的項目。例如，假設有一個追蹤客戶訂單的 DynamoDB 表，其中 CustomerId 是分區索引鍵。

OrderTime 上的 LSI 可以有效率地查詢，以擷取特定客戶最近訂購的項目。

反之，GSI 不限於具有共用分區索引鍵值的項目。代之的是，GSI 會跨越表格的所有項目，就像主索引鍵一樣。在上表中，ProductId 上的 GSI 可用來有效率地尋找特定產品的所有訂單。請注意，在這個案例中並未指定 GSI 排序索引鍵，即使可能有許多訂單的 ProductId 相同，也將以單獨的項目存放在 GSI 中。

為了確保表格和索引中的資料共置於同一個分區，LSI 將每個分區索引鍵值的所有元素 (表格和索引) 總大小限制為 10 GB。GSI 不會強制要求資料主機代管，也沒有這種限制。

當您寫入表格時，DynamoDB 會自動更新所有受影響的 LSI。相反地，對表格上定義的任何 GSI 進行的更新最終會保持一致。

LSI 允許 Query API 擷取投影清單之外的屬性。這不是 GSI 支援的行為。

問：全域次要索引如何運作？

GSI 的行為在許多方面與 DynamoDB 表相似。您可以使用 GSI 的分區索引鍵元素來查詢 GSI，同時在 GSI 排序索引鍵元素上使用條件篩選。不過，不同的是，DynamoDB 表的主索引鍵必須是唯一的，但多個項目可以有相同的 GSI 鍵。如果多個項目有相同的 GSI 鍵，會將它們視為單獨的 GSI 項目進行追蹤，而且 GSI 查詢會將它們視為個別項目全部擷取。新增、移除或更新項目時，DynamoDB 會確保內部的 GSI 內容得到適當的更新。

DynamoDB 將 GSI 的投影屬性儲存在 GSI 資料結構中，同時儲存 GSI 鍵和相符項目的主索引鍵。GSI 使用來源表格中投影項目的儲存。這可讓查詢根據 GSI 而不是根據表格進行，藉此提高查詢的靈活性，並改善工作負載的分佈。因此，查詢 GSI 索引不會傳回屬於表格項目一部分但不屬於 GSI 鍵的屬性、表格的主索引鍵或投影屬性。如果應用程式需要在查詢 GSI 後從表格獲得其他資料，可從 GSI 擷取主索引鍵，然後使用 GetItem 或 BatchGetItem API，從表格擷取所需的屬性。由於 GSI 具有最終一致性，因此使用此模式的應用程式必須考慮在 GSI 和 GetItem/BatchItem 呼叫期間的項目刪除 (從表格) 問題。

當您新增、更新和刪除表格時，DynamoDB 會自動處理 GSI 中項目的對應變更。將某個項目 (具有 GSI 鍵屬性) 新增到表格中時，DynamoDB 會對 GSI 進行非同步更新，以新增此項目。同樣地，將某個項目從表格刪除時，DynamoDB 會從受影響的 GSI 刪除該項目。

問：是否可為以分區為基礎的表格和分區排序結構描述表格建立全域次要索引？

是，無論 DynamoDB 表的主索引鍵類型為何，您都可以建立全域次要索引。表格的主索引鍵可以只包含分區索引鍵，或可同時包含分區索引鍵和排序索引鍵。

問：什麼是全域次要索引的一致性模式？

GSI 支援最終一致性。在表格中插入或更新項目時，GSI 不會同步更新。在正常操作條件下，寫入全域次要索引將在一秒內傳播。在極少數故障情況下，可能會有較長的延遲。因此，您的應用程式邏輯應該要能夠處理可能過期的 GSI 查詢結果。請注意，支援最終一致讀取的其他 DynamoDB API 也有此相同行為。

假設有一個追蹤最高分的表格，其中每個項目都有 UserId、GameTitle 和 TopScore 屬性。分區索引鍵是 UserId，而主排序索引鍵是 GameTitle。如果應用程式為 GameTitle "TicTacToe" 和 UserId "GAMER123" 新增一個代表新最高分的項目，再查詢 GSI，則這個新分數可能不在查詢結果中。不過，一旦完成 GSI 傳播，該新項目即開始出現在對 GSI 的此類查詢中。

問：是否可以單獨佈建表格和每個全域次要索引的輸送量？

是。GSI 管理的輸送量與它們所依據的表格無關。當您從主控台為新表格或現有表格啟用 Auto Scaling 時，可以選擇將相同設定套用至 GSI。您也可以為表格和全域次要索引手動佈建不同的輸送量。

根據應用程式的不同，GSI 的請求工作負載與表格或其他 GSI 的請求工作負載可能有明顯差異。以下所列的幾種情形說明了這個差異：

• 與表格相較之下，包含小部分表格項目的 GSI 需要的寫入輸送量明顯較低。
• 與表格相較之下，用於查詢非經常性項目的 GSI 需要的讀取輸送量明顯較低。
• 需大量讀取操作的背景工作所用的 GSI，每天有幾小時可能需要較高的讀取輸送量。

隨著您的需求不斷擴展，您可以變更 GSI 的佈建輸送量，這與表格的佈建輸送量無關。

假設一個 DynamoDB 表具有投影所有屬性的 GSI，而且其中 50% 的項目都有 GSI 鍵。在這種情況下，GSI 的佈建寫入容量單位應設定為表格佈建寫入容量單位的 50%。使用類似的方式可以估算出 GSI 的讀取輸送量。請參閱 DynamoDB GSI 文件，以了解更多詳細資訊。

問：增加全域次要索引會對表格的佈建輸送量和儲存造成什麼影響？

與 DynamoDB 表類似，對 GSI 執行讀取或寫入操作時，它會消耗佈建輸送量。新增或更新 GSI 項目的寫入操作將根據更新的大小消耗寫入容量單位。除了更新表格中項目所需的容量之外，GSI 寫入操作也會消耗容量。

請注意，如果您在 DynamoDB 表中新增、刪除或更新項目，而且這個操作不會導致 GSI 發生變更，則 GSI 將不會消耗任何寫入容量單位。將不含任何 GSI 鍵屬性的項目新增到 DynamoDB 表時，或在不變更任何 GSI 鍵或投影屬性的情況下更新項目時，就會發生這種情況。

查詢 GSI 時，會根據查詢所檢索的項目大小消耗讀取容量單位。

GSI 的儲存成本取決於該 GSI 中所儲存的位元組總數。這包括 GSI 鍵與投影屬性和值，以及用於索引所消耗的 100 個位元組。

問：DynamoDB 是否會因 GSI 的佈建輸送量而限制應用程式對表格的寫入操作？

由於對 DynamoDB 表的部分或全部寫入操作會導致對相關 GSI 的寫入，因此可能會耗盡 GSI 的佈建輸送量。在這種情況下，後續對表格的寫入操作將受到限制。即使表格仍有可用的寫入容量單位，也可能會發生這種情況。

問：我可以多久變更一次索引層級的佈建輸送量？

含 GSI 的表格對於輸送量變更操作次數的每日限制與一般表格相同。

問：DynamoDB 全域次要索引如何收費？

根據表格及其 GSI 的合計佈建輸送量，按小時向您收費。當您手動佈建時 (雖然沒有要求)，會根據表格及其 GSI 的合計佈建輸送量，按小時向您收費。此外，還會向您收取 GSI 所使用的資料儲存體費用，以及標準數據傳輸 (外部) 費用。如果您要變更 GSI 佈建的輸送容量，可以使用 DynamoDB 主控台、UpdateTable API 或更新 Auto Scaling 政策設定的 PutScalingPolicy API 執行此操作。

問：是否能指定用於查詢的全域次要索引？

是。除了常見的查詢參數之外，GSI 的查詢命令還明確包含對其進行操作的 GSI 名稱。請注意，一次查詢只能使用一個 GSI。

問：全域次要索引支援哪些 API 呼叫？

GSI 支援的 API 呼叫包括 Query 和 Scan。Query 操作只搜尋索引鍵屬性值，並且支援比較運算子的子集。由於 GSI 是以非同步方式更新，所以您不能使用 ConsistentRead 參數進行查詢。請參閱這裡以了解有關使用 GSI 進行查詢和掃描的詳細資訊。

問：在全域次要索引的掃描中，如何排序結果？

對於全域次要索引，若只有分區索引鍵結構描述，則沒有排序問題。對於具有分區排序索引鍵結構描述的全域次要索引，相同分區索引鍵結果的排序取決於排序索引鍵屬性。

問：是否能在建立表格之後變更全域次要索引？

是，即使在建立表格之後，您仍可以隨時變更全域次要索引。

問：如何在現有的表格中新增全域次要索引？

您可以透過主控台或 API 呼叫新增全域次要索引。在 DynamoDB 主控台上，先選擇您要新增全域次要索引的表格，然後按一下 "Create Index" 按鈕以新增索引。按照索引建立精靈中的步驟進行，並在完成時選擇 "Create"。您還可以使用 UpdateTable API 呼叫搭配 GlobalSecondaryIndexes 參數新增或刪除全域次要索引。您可以閱讀文件頁面以進一步了解更多資訊。

問：如何刪除全域次要索引？

您可以從主控台或透過 API 呼叫刪除全域次要索引。在 DynamoDB 主控台上，選擇您要刪除的全域次要索引的表格。然後，選擇 "Table Items" 下的 "Indexes" 標籤，再按一下旁邊的 "Delete" 按鈕以刪除索引。您也可以使用 UpdateTable API 呼叫刪除全域次要索引。您可以閱讀文件頁面以進一步了解更多資訊。

問：是否能透過一次 API 呼叫新增或刪除同一個表格中的多個索引？

每個 API 呼叫只能新增或刪除一個索引。

問：如果我提交多個請求新增同一個索引，會發生什麼狀況？

只會接受第一個新增請求，所有後續的新增請求將會失敗，直到第一個新增請求完成為止。

問：是否能同時在同一個表格上新增或刪除多個索引？

否，任何時候，一個表格只能有一個作用中的新增或刪除索引操作。

問：是否應該佈建額外的輸送量以新增全域次要索引？

使用 Auto Scaling 時，建議您在全域次要索引套用和表格相同的設定。雖然沒有要求，但仍強烈建議您在手動佈建時佈建額外的寫入輸送量，與索引的輸送量分開。如果您沒有佈建額外的寫入輸送量，就會消耗索引的寫入輸送量用於新增索引。這樣會在建立索引時影響索引的寫入效能，也會增加建立新索引的時間。

問：建立索引後，是否必須減少全域次要索引的額外輸送量？

是，此程序完成後，您必須調回為新增索引所額外佈建的寫入輸送量。

問：是否能修改為新增全域次要索引所佈建的寫入輸送量？

是，您可以在建立過程中，隨時擴張或縮減建立索引的佈建寫入輸送量。

問：新增或刪除全域次要索引時，是否仍然可使用表格？

是，更新全域次要索引時，可以使用表格。

問：新增或刪除全域次要索引時，是否仍然可使用現有的索引？

是，更新全域次要索引時，可以使用現有的索引。

問：建立新增全域次要索引時，是否可使用新索引？

否，新索引只在索引建立程序完成後才可使用。

問：新增全域次要索引需要多長時間？

所需的時間取決於表格的大小以及為建立全域次要索引所額外佈建的寫入輸送量。新增或刪除索引的程序有所不同，可能花費幾分鐘到幾個小時。例如，假設您有一個佈建了 500 個寫入容量單位的 1 GB 表格，並為索引和建立新索引佈建了 1000 個額外的寫入容量單位。如果新索引包含表格中的所有屬性，且該表格使用所有的寫入容量單位，我們預計建立索引約需要 30 分鐘。

問：刪除全域次要索引需要多長時間？

刪除索引通常在幾分鐘內就能完成。例如，刪除具有 1 GB 資料的索引通常不到 1 分鐘。

問：如何追蹤全域次要索引的新增或刪除操作進度？

您可以使用 DynamoDB 主控台或 DescribeTable API 查看與表格相關的所有索引狀態。對於新增索引操作，正在建立索引時，索引的狀態為「建立中」。索引建立完成後，索引狀態會從「建立中」變成「作用中」。對於刪除索引操作，請求完成時，刪除的索引便不再存在。

問：新增全域次要索引的索引建立程序完成時，是否會收到通知？

您可以請求將通知傳送到您的電子郵件地址，以確認新增索引已經完成。當您透過主控台新增索引時，可以請求在建立索引之前的最後一個步驟傳送通知。當索引建立完成時，DynamoDB 會將 SNS 通知傳送到您的電子郵件。

問：當我已經有 5 個索引，仍嘗試新增更多的全域次要索引時，會出現什麼情況？

目前限制為 5 個 GSI。「新增」操作將會失敗，您會收到錯誤。

問：是否能在刪除某個名稱的索引之後，重複使用相同的全域次要索引名稱？

是，刪除全域次要索引後，在新增新索引時，可以再次使用該索引名稱。

問：是否能在索引建立時取消索引新增？

否，一旦開始建立索引，就不能取消索引建立程序。

問：是否 DynamoDB 表的所有項目都需要 GSI 鍵屬性？

否。GSI 是疏鬆索引。與要求包含主索引鍵的項目不同，DynamoDB 表中的項目不必包含任何 GSI 鍵。如果某個 GSI 鍵包含分區和排序元素，而表格項目省略其中一個元素，那麼對應的 GSI 就不會編製該項目的索引。在這種情況下，GSI 對於有效率地查詢具有稀有屬性的項目非常有用。

問：是否能從全域次要索引擷取 DynamoDB 表的所有屬性？

GSI 查詢只能傳回在建立時就指定包含在 GSI 中的屬性。GSI 中包含的屬性是指預設投影的屬性，例如，GSI 的鍵值屬性和表格的主索引鍵屬性，以及使用者指定要投影的屬性。基於這個原因，對於屬於表格的一部分但並未包含在 GSI 中的項目，GSI 查詢不會傳回其屬性。將所有屬性指定為投影屬性的 GSI 可用於擷取任何表格屬性。請參閱這裡，以了解有關使用 GSI 進行查詢的文件。

問：如何列出與表格相關的 GSI？

DescribeTable API 可傳回有關表格上全域次要索引的詳細資訊。

問：哪些資料類型可以編製索引？

所有純量資料類型 (數字、字串、二進位和布林值) 皆可用於本機次要索引鍵的排序索引鍵元素。集合、清單和對應類型無法編製索引。

問：是否可能有複合屬性索引？

否。但您可以將屬性串連到一個字串中，並將其作為索引鍵。

問：哪些資料類型可以成為 GSI 投影屬性的一部分？

您可以指定將具有任何資料類型 (包括集合類型) 的屬性投影到 GSI 中。

問：GSI 在可擴展性方面有哪些考量？

DynamoDB 表的主索引鍵效能考量同樣適用於 GSI 鍵。GSI 在所有索引鍵上採用相對隨機存取模式。為了充分利用次要索引佈建的輸送量，您選擇的 GSI 分區索引鍵屬性應該包含大量不同的值，而 GSI 排序索引鍵屬性應要求相當平均，盡可能隨機。

問：透過 CloudWatch 可為全域次要索引提供哪些新指標？

具有 GSI 的表格將為表格和 GSI 提供彙總指標，也會為表格和每個 GSI 提供分類指標。

個別 GSI 的報告將支援 CloudWatch 指標 (由表格提供支援) 的子集。其中包括：

• 讀取容量 (佈建的讀取容量、使用的讀取容量)
• 寫入容量 (佈建的寫入容量、使用的寫入容量)
• 限制的讀取事件
• 限制的寫入事件

有關 DynamoDB 表和索引支援的指標更多詳細資訊，請參閱這裡。

問：如何掃描全域次要索引？

您可透過主控台或 Scan API 掃描全域次要索引。

要掃描全域次要索引，除了您要掃描的表格名稱之外，還須明確參考索引。您必須指定索引分區屬性名稱和值。您可以選擇針對索引鍵排序屬性指定條件。

問：全域次要索引掃描是否允許在要傳回的結果集中指定非投影屬性？

全域次要索引掃描不支援擷取非投影屬性。

問：索引是否支援並行掃描？

是，索引支援並行掃描，而且語意與主表格的語意相同。

問：什麼是本機次要索引？

本機次要索引可讓一些需要擷取大量項目再篩選結果的常見查詢執行速度更快，而且非常經濟實惠。這表示您的應用程式可以根據更廣泛的屬性進行更靈活的查詢。

本機次要索引啟動前，如果您想在分區中尋找特定項目 (共用相同分區索引鍵的項目)，DynamoDB 將擷取共用單一分區索引鍵的所有物件，然後據此篩選結果。例如，試想有個電子商務應用程式，透過客戶 ID 訂單時間戳記的分區排序結構描述，將客戶訂單資料存放在 DynamoDB 表中。在沒有 LSI 的情況下，要尋找「顯示客戶 X 出貨日期在最近 30 天內的所有訂單，按出貨日期排序」這個問題的答案，您必須使用 Query API 擷取分區索引鍵 "X" 下的所有物件，按照出貨日期排序結果，然後篩選掉較早的記錄。

使用本機次要索引時，我們可以簡化上述操作。現在，您可以在「出貨日期」屬性上建立索引，並有效率地執行此查詢，僅需擷取必要項目即可。由於您只需擷取符合特定條件的項目，因此大幅減少延遲和查詢成本。此外，您無須再撰寫客戶邏輯來篩選結果，因此，這個操作還可簡化應用程式的程式設計模型。我們將這種新的次要索引稱為「本機」次要索引，由於它與分區索引鍵搭配使用，因此您可以在分區索引鍵儲存貯體內進行本機搜尋。所以，先前您只能使用分區索引鍵和排序索引鍵進行搜尋，現在您還可以使用次要索引來代替排序索引鍵進行搜尋，因此增加了能夠用於有效查詢的屬性數目。

您可以將資料屬性的冗餘備份複製到您定義的本機次要索引中。這些屬性包括表格分區和排序索引鍵，以及您定義的備用排序索引鍵。您還可以將其他資料屬性冗餘存放在本機次要索引中，無須存取表格本身即可存取這些屬性。

本機次要索引並非適用於每個應用程式。它們對於可存放在單一分區索引鍵值中的資料量有所限制。如需詳細資訊，請參閱以下有關項目集合的常見問答集項目。

問：什麼是投影？

複製到本機次要索引中的屬性集稱為「投影」。投影決定您能夠以最有效率的方式擷取哪些屬性。查詢本機次要索引時，Amazon DynamoDB 可以存取任何投影屬性，這些屬性具有的效能特性與它們在其本身表格中相同。如果您需要擷取任何未投影的屬性，Amazon DynamoDB 會自動從表格擷取這些屬性。

定義本機次要索引後，您需要指定要投影到索引中的屬性。每個索引項目至少包含：(1) 表格分區索引鍵值，(2) 做為索引排序索引鍵的屬性，以及 (3) 表格排序索引鍵值。

此外，您也可以選擇要投影到索引中的其他非索引鍵屬性使用者指定清單。您還可以選擇將所有屬性投影到索引中。在這種情況下，索引會複製與表格本身相同的資料，但依照您指定的備用排序索引鍵組織資料。

問：如何建立 LSI？

您需要在建立表格時建立 LSI。目前還無法在之後新增。要建立 LSI，請指定以下兩個參數：

索引排序索引鍵 – 將編製索引和查詢的屬性。

投影屬性 – 表格的屬性清單，將直接複製到本機次要索引中，因此這些屬性傳回速度更快，無須從包含所有表格項目的主索引中擷取資料。在沒有投影屬性的情況下，本機次要索引僅包含主索引和次要索引鍵。

問：什麼是 LSI 的一致性模式？

主索引更新時，本機次要索引將自動進行更新。與從主索引讀取類似，LSI 支援強制一致性讀取和最終一致讀取選項。

問：本機次要索引是否包含對表格中所有項目的參考？

否，不一定。本機次要索引僅參考包含針對該 LSI 指定的索引排序索引鍵項目。DynamoDB 的靈活結構描述表示並非所有項目都必須包含所有屬性。

這表示相較於主索引，本機次要索引可疏鬆填入。由於本機次要索引疏鬆，因此可有效用於支援不常見屬性的查詢。

例如，在上述訂單範例中，某個客戶項目可能包含一些額外屬性，且僅在訂單取消的情況下包括這些屬性 (例如 CanceledDateTime、CanceledReason)。針對已取消項目的相關查詢，由於索引中參考的項目僅為擁有現有屬性的項目，因此，任一屬性上的本機次要索引均有效。

問：如何查詢本機次要索引？

僅可透過 Query API 查詢本機次要索引。

要查詢本機次要索引，除了想要查詢的表格名稱之外，還須明確參考索引。您必須指定索引分區屬性名稱和值。您可以選擇針對索引鍵排序屬性指定條件。

查詢可以執行表格擷取操作以擷取主索引中存放的非投影屬性，但需要支付額外讀取容量單位的費用。

強制一致性和最終一致讀取均支援使用本機次要索引的查詢。

問：如何建立本機次要索引？

必須在建立表格時定義本機次要索引。表格的主索引必須使用分區排序複合鍵。

問：是否能將本機次要索引新增至現有的表格中？

否，目前還不能將本機次要索引新增至現有表格中。我們正在努力新增這個功能，並會在未來發佈。建立含本機次要索引的表格時，您可透過定義目前未使用的排序索引鍵元素來建立本機次要索引，以供日後使用。由於本機次要索引疏鬆，因此在您決定使用此索引前，無須支付任何費用。

問：一個表格可建立多少本機次要索引？

每個表格最多可有 5 個本機次要索引。

問：一個表格可建立多少投影非索引鍵屬性？

以表格中所有本機次要索引總計，每個表格最多可有 20 個投影非索引鍵屬性。每個索引還可以指定要投影主索引的所有非索引鍵屬性。

問：索引建立後是否能修改？

否，索引一旦建立就不能修改。我們正在努力研究，以便在未來新增這個功能。

問：是否能刪除本機次要索引？

否，目前一旦建立就無法從表格中移除本機次要索引。當然，如果您要刪除整個表格，則可以將其刪除。我們正在努力新增這個功能，並會在未來發佈。

問：本機次要索引如何消耗佈建的容量？

您無須為本機次要索引特別佈建容量。它會消耗與其關聯的表格一部分的佈建容量。

按照每 1 KB 資料 1 個單位的標準公式，從 LSI 讀取與利用 LSI 寫入表格所消耗的容量差異如下：

寫入包含與一或多個本機次要索引相關的資料時，這些寫入會鏡像複製到適當的本機次要索引。在這些情況下，表格本身將消耗寫入容量，而各相關 LSI 將消耗額外的寫入容量。

覆寫現有項目的更新會產生兩項操作：刪除和插入，因此 1 KB 資料將消耗額外的寫入容量單位。

當讀取查詢請求屬性未投影至 LSI 中時，DynamoDB 將從主索引擷取這些屬性。這個隱含 GetItem 請求每擷取 4 KB 的項目資料時，將消耗一個讀取容量單位。

問：本機次要索引會消耗多少儲存空間？

對於所有投影非索引鍵屬性，本機次要索引會消耗用於屬性名稱以及每個 LSI 主索引鍵和索引鍵值的儲存空間。此外，每在 LSI 反映一個項目，會增加 100 個位元組的儲存空間。

問：哪些資料類型可以編製索引？

所有純量資料類型 (數字、字串、二進位) 皆可用於本機次要索引鍵的排序索引鍵元素。集合類型無法使用。

問：哪些資料類型可投影到本機次要索引？

所有資料類型 (包括集合類型) 都可投影到本機次要索引。

問：什麼是項目集合及其如何與 LSI 關聯？

在 Amazon DynamoDB 中，項目集合是表格及其所有本機次要索引中擁有相同分區索引鍵項目的任何組合。傳統的分區 (或碎片) 關聯式資料庫系統將這些項目稱為「碎片」或「分區」，其參照到分區索引鍵下存放的所有資料庫項目或列。

對於每個包含本機次要索引的表格，其項目集合都會自動建立及維護。DynamoDB 會將每個項目集合存放在單一磁碟分割。

問：項目集合的大小是否有限制？

Amazon DynamoDB 中每個項目集合大小有不得超過 10 GB 的限制。對任何不同的分區索引鍵值，表格中項目大小總和加上該表格的本機次要索引所有項目大小總和不得超過 10 GB。

不具有本機次要索引的表格則不受此項目集合 10 GB 的限制；此限制僅影響擁有一或多個本機次要索引的表格。

雖然個別項目集合大小受到限制，但是具有本機次要索引的整體表格儲存大小則不受限制。如果任一分區索引鍵值儲存大小總和 (表格和索引) 不超過 10 GB 閾值，則 Amazon DynamoDB 中已編製索引的表格大小總和實際上不會受到限制。

問：如何追蹤項目集合的大小？

DynamoDB 的寫入 API (PutItem、UpdateItem、DeleteItem 和 BatchWriteItem) 包含一個選項，此選項允許 API 回應包含相關項目集合大小的預估值。此預估值包括特定項目集合中資料的預估大小上限與下限，以 GB 為單位。

我們建議您對應用程式進行檢測，以監控項目集合的大小。您的應用程式應檢測與項目集合大小相關的 API 回應，並在項目集合超出使用者定義的限制 (例如，8 GB) 時，記錄錯誤訊息。這將提供早期警告系統，讓您知道項目集合正在不斷變大，但會給您足夠的時間處理。

問：如果超過項目集合的 10 GB 大小限制會發生什麼情況？

如果特定項目集合超過 10 GB 的大小限制，您將無法寫入新項目，或增加該特定分區索引鍵現有項目的大小。仍然允許進行會減小項目集合大小的讀取和寫入操作。表格中的其他項目集合則不受此影響。

若要解決這個問題，您可以將集合中超過 10 GB 的項目移除或減少項目大小。或是，您可以將新項目引入新分區索引鍵值下，以解決這個問題。如果表格中包含不常存取的歷史資料，可以考慮將這些歷史資料存檔至 Amazon S3、Amazon Glacier 或另一個資料存放區。

問：如何掃描本機次要索引？

要掃描本機次要索引，除了您想要掃描的表格名稱之外，還須明確參考索引。您必須指定索引分區屬性名稱和值。您可以選擇針對索引鍵排序屬性指定條件。

掃描可以執行表格擷取操作以擷取主索引中存放的非投影屬性，但需要支付額外讀取容量單位的費用。

問：本機次要索引掃描是否允許在要傳回的結果集中指定非投影屬性？

本機次要索引掃描支援擷取非投影屬性。

問：在本機次要索引的掃描中，如何排序結果？

對於本機次要索引，集合內的排序取決於索引屬性的排序。

問：什麼是 DynamoDB 微調存取控制權？

微調存取控制權 (FGAC) 可讓 DynamoDB 表擁有者對表中的資料進行高度控制。特別是表格擁有者可指定誰 (發起人) 可以存取哪些表格項目或屬性，以及執行什麼動作 (讀/寫能力)。FGAC 與 AWS Identity and Access Management (IAM) 配合使用，後者可管理安全登入資料及相關的許可。

問：DynamoDB FGAC 的常用案例有哪些？

FGAC 對任何追蹤 DynamoDB 表中資訊的應用程式都有好處，在這些應用程式中，最終使用者 (或代表最終使用者的應用程式用戶端) 需要直接讀取或修改表格，不需中間層服務。例如，開發人員開發一個名為 Acme 的行動應用程式，他可以使用 FGAC 追蹤 DynamoDB 表中每個 Acme 使用者的最高分數。FGAC 允許應用程式用戶端只修改目前執行應用程式的使用者的最高分數。

問：是否可將微調存取控制權與 JSON 文件搭配使用？

是。您可以使用微調存取控制權 (FGAC)，根據文件中的頂層屬性限制對資料的存取。您不能使用 FGAC 限制以巢狀屬性為基礎的存取。例如，假設您儲存的 JSON 文件中包含關於人員的下列資訊：ID、名字、姓氏及其所有好友清單。您可以使用 FGAC 限制以 ID、名字或姓氏為基礎的存取，但不能限制以好友清單為基礎的存取。

問：如果不使用 FGAC，開發人員如何達到項目層級的存取控制？

要在不使用 FGAC 的情況下達到這個層級的控制，開發人員必須從幾種可能較為不便的方法中選擇。其中幾種方法如下：

1. 代理：應用程式用戶端將請求傳送到執行身份驗證和授權的仲介代理。這種解決方案會增加系統架構的複雜性，且可能產生更高的總體擁有成本 (TCO)。
2. 用戶端專用表格：為每個應用程式用戶端指派專用表格。由於應用程式用戶端各自存取不同的表格，彼此之間互不流通。這可能需要開發人員建立數百萬個表格，使得資料庫管理變得極為困難。
3. 用戶端專用嵌入字符：在應用程式用戶端嵌入秘密字符。這種方法的缺點是難以變更字符和處理其對所儲存資料的影響。在這種情況下，可由此用戶端存取的項目鍵值會包含秘密字符。

問：DynamoDB FGAC 如何運作？

使用 FGAC 時，應用程式會要求安全字符，授權應用程式只能存取特定 DynamoDB 表中的特定項目。透過此字符，最終使用者應用程式代理器可直接向 DynamoDB 發出請求。收到請求後，DynamoDB 會先評估傳入請求的登入資料，它使用 IAM 驗證請求，並決定允許使用者具有的能力。如果使用者的請求沒有獲得許可，FGAC 將阻止對資料的存取。

問：DynamoDB FGAC 的費用是多少？

使用 FGAC 不會收取其他費用。如往常一樣，您只需為佈建的輸送量和與 DynamoDB 表相關的儲存付費。

問：如何開始使用？

請參考 DynamoDB Developer Guide 的 Fine-Grained Access Control 部分，了解如何建立存取政策、為應用程式建立 IAM 角色 (例如，為 Facebook app_id 34567 建立名為 AcmeFacebookUsers 的角色)，以及將存取政策指派給角色。角色的信任政策決定可接受哪些身分供應商 (例如，Login with Amazon、Facebook 或 Google)，存取政策則描述可存取哪些 AWS 資源 (例如，DynamoDB 表)。使用角色，您的應用程式現在可透過呼叫 AWS Security Token Service (STS) 的 AssumeRoleWithIdentityRequest API 取得 DynamoDB 的臨時登入資料。

問：如何允許使用者查詢本機次要索引，但避免造成表格擷取以提取非投影的屬性？

如果請求未投影到索引中的屬性，有些本機次要索引上的查詢操作會比其他操作的成本更為昂貴。您可以使用 "dynamodb:Attributes" 內容索引鍵，將許可限制為僅投影的屬性，以限制這種可能高價的「擷取」操作。

問：如何防止使用者存取特定的屬性？

要防止存取特定的屬性，建議的方法是遵循最小權限原則，只允許存取特定的屬性。

或者，您可以使用拒絕政策，指定不允許存取的屬性。但是不建議使用此方法，原因如下：

1. 使用拒絕政策時，使用者可能為尋找隱藏的屬性名稱而針對每個可能的屬性名稱重複發出請求，直到最終被拒絕存取為止。
2. 拒絕政策較容易受到影響，因為 DynamoDB 將來會引入新的 API 功能，這些功能可能會允許您之前要封鎖的存取模式。

問：如何避免使用者將無效資料新增到表格中？

可用的 FGAC 控制項可判斷哪些項目已變更或讀取，以及決定可變更或讀取哪些屬性。使用者可以新增不具封鎖屬性的新項目，以及變更任何可修改的屬性值。

問：是否可授權對多個屬性的存取，但不將其全部列出？

是，IAM 政策語言支援多種比較操作，包括 StringLike、StringNotLike 等等。如需其他詳細資訊，請參閱 IAM 政策參考。

問：如何建立適當的政策？

建議您使用 DynamoDB 主控台的 DynamoDB 政策產生器。您也可以將您的政策與 Amazon DynamoDB Developer Guide 中列出的政策比較，以確保符合建議的模式。您可以將政策發佈到 AWS 論壇，了解 DynamoDB 社群中其他人的看法。

問：是否可根據正式使用者 ID 而不是根據使用者登入的身分供應商個別 ID 授與權限？

未執行「字符販賣機」時不可以。如果使用者透過 STS，使用 Facebook 登入資料直接擷取 IAM 角色的聯合存取權，則臨時登入資料只會包含該使用者的 Facebook 登入資訊，不包含 Amazon 登入或 Google 登入資訊。如果您要將每一個登入資訊的映射存放到內部自己的穩定識別符，可以執行使用者用來登入的服務，然後呼叫 STS，並將以分區索引鍵值為排序的登入資料提供給使用者，做為他們的正式使用者 ID。

問：無法對使用 FGAC 的發起人隱藏哪些資訊？

目前無法針對發起人封鎖的表格項目特定資訊如下：

• 項目集合指標。發起人可以要求項目集合中預估的項目數和大小 (以位元組為單位)。
• 消耗的輸送量。發起人可以要求操作所消耗的佈建輸送量詳細明細或摘要。
• 驗證案例。在某些情況下，發起人可以在您未提供存取權時，得知表格的存在情況和主索引鍵結構描述。要避免發生這種狀況，請遵循最小權限原則，僅允許存取您允許存取的表格和動作。
• 如果您拒絕對特定屬性的存取，而不是將對特定屬性的存取權列入白名單，則執行「允許除外項目之外所有項目」邏輯時，發起人理論上可以確定隱藏屬性的名稱。所以，改為將特定屬性名稱列入白名單會比較安全。

問：使用 Amazon DynamoDB 如何收費？

每個 DynamoDB 表都會佈建與其相關聯的讀取輸送量和寫入輸送量。如果您超過免費方案的範圍，該輸送容量將按小時計費。

請注意，無論您是否傳送請求給表格，我們都將按小時對輸送容量收費。如果您要變更表格佈建的輸送容量，可以使用 AWS 管理主控台、UpdateTable API 或 Auto Scaling 的 PutScalingPolicy API 執行此操作。

此外，DynamoDB 也會針對索引資料儲存體收費，您還必須支付標準網際網路數據傳輸的費用。

要進一步了解有關 DynamoDB 定價的資訊，請參閱 DynamoDB 定價頁面。

問：可以提供一些定價範例嗎？

在接下來的例子中，我們將使用美國東部 (維吉尼亞北部) 區域的定價來計算輸送量費用。要查看其他區域的價格，請參閱我們的定價頁面。

如果您建立一個表格，請求佈建的輸送量為 10 個寫入容量單位和 200 個讀取容量單位，則收費如下：

0.01 USD + (4 x 0.01 USD) = 每小時 0.05 USD

如果您的輸送量需求發生變化，您將預留輸送量要求增加至 10,000 個寫入容量單位和 50,000 個讀取容量單位，則收費將變成：

(1 000 x 0.01 USD) + (1 000 x 0.01 USD) = 每小時 20 USD

要進一步了解有關 DynamoDB 定價的資訊，請參閱 DynamoDB 定價頁面。

問：價格含稅嗎？

若需稅務的詳細資訊，請參閱 Amazon Web Services 稅務說明。

問：什麼是佈建的輸送量？

Amazon DynamoDB Auto Scaling 可根據您所需的目標使用率、最低和最高容量限制，隨著請求量的變更自動調整輸送容量，或是讓您手動指定希望表格能夠達到的請求輸送量。服務會在背景處理資源的佈建，以達到請求的輸送率。您不必考慮執行個體、硬體、記憶體及其他可能影響輸送率的因素，只需佈建您希望達到的輸送量等級。這就是服務的佈建輸送量模型。

建立新表格或全域次要索引時，預設會以目標使用率、最低和最高容量的預設值啟用 Auto Scaling；您也可以手動指定需要的讀取和寫入容量需求；Amazon DynamoDB 會自動分割和保留適量的資源量以符合您的輸送量需求。

問：主索引鍵的選擇會如何影響我所能實現的可擴展性？

儲存資料時，Amazon DynamoDB 會將表格分為多個分區，並根據主索引鍵的分區索引鍵元素來分配資料。分配容量資源時，Amazon DynamoDB 會在所有主索引鍵上採用相對隨機存取模式。您應該設定您的資料模型，使您的請求在主索引鍵之間產生相當平均的流量分佈。如果表格有少量的密集存取分區索引鍵元素，甚至可能只有一個非常密集使用的分區索引鍵元素，則流量將集中在少數分區，甚至可能只集中在一個分區。如果工作負載嚴重不平衡，也就是不成比例地集中在一個或少數分區上，則操作將無法達到整體佈建的輸送量等級。為了充分利用 Amazon DynamoDB 輸送量，建置的表格分區索引鍵元素應具有大量相異值，而且盡可能以隨機且一致的方式請求值。例如，如果應用程式有許多客戶，而對各個客戶記錄所做的請求大致平均，那麼 CustomerID 就是適合的主索引鍵。"Product Category Name" 則是一個嚴重不均衡的主索引鍵，因為其中的某些產品類別比其餘類別更受歡迎。

問：什麼是讀取/寫入容量單位？

如何估計應用程式所需的讀取和寫入容量單位數量？一個寫入容量單位可讓您針對最大 1 KB 的項目每秒執行一次寫入操作。同樣地，一個讀取容量單位可讓您針對最大 4 KB 的項目每秒執行一次強制一致性讀取操作 (或每秒兩次最終一致讀取操作)。更大的項目需要更多容量。您可以透過以下方式計算需要的讀取和寫入容量單位數量：預估每秒需要執行的讀取或寫入次數，乘以項目的大小 (進位到最接近的 KB)。

寫入所需的容量單位 = 每秒的項目寫入量 x 以 1 KB 區塊為單位的項目大小

讀取所需要的容量單位* = 每秒的項目讀取量 x 以 4 KB 區塊為單位的項目大小

* 如果使用最終一致讀取，會得出兩倍的每秒讀取數輸送量。

如果項目小於 1 KB，則每個讀取容量單位將提供每秒 1 次強制一致性讀取容量，每個寫入容量單位將提供每秒 1 次寫入容量。例如，如果項目大小為 512 位元組，您需要每秒從表格讀取 100 個項目，則您需要佈建 100 個讀取容量單位。

如果項目大於 4 KB，您應該計算所需的讀取容量和寫入容量單位數量。例如，如果項目大小為 4.5 KB，您希望每秒進行 100 次強制一致性讀取，則需要佈建 100 (每秒讀取次數) x 2 (儲存 4.5 KB 所需的 4 KB 區塊量) = 200 個讀取容量單位。

請注意，需要的讀取容量單位數量取決於每秒讀取的項目數量，而不是 API 呼叫的數量。例如，如果您需要每秒從表格讀取 500 個項目，而且這些項目等於或小於 4 KB，則需要 500 個讀取容量單位。無論是執行 500 次單獨 GetItem 呼叫，還是執行 50 次 BatchGetItem 呼叫，每次傳回 10 個項目，並沒有影響。

問：是否可以一直維持達到佈建的輸送量等級？

Amazon DynamoDB 在所有主索引鍵上採用相對隨機存取模式。您應該設定您的資料模型，使您的請求在主索引鍵之間產生相當平均的流量分佈。如果存取模式非常不平均或嚴重傾斜，您將無法達到佈建的輸送量等級。

儲存資料時，Amazon DynamoDB 會將表格分為多個分區，並根據主索引鍵的分區索引鍵元素來分配資料。與表格關聯的佈建輸送量也在多個分區之間加以劃分；每個分區的輸送量根據所分配的配額單獨管理。各分區不會共用佈建的輸送量。因此，如果分區索引鍵值之間的工作負載分佈非常平均，Amazon DynamoDB 中的表格就最能夠符合佈建的輸送量等級。將請求分佈給各個分區索引鍵值也就是將請求分佈到各個分區，有助於您達到完整的佈建輸送量等級。

如果工作負載模式在主索引鍵之間分佈不平均，無法達到您的佈建輸送量等級，您可以進一步提高佈建的輸送量等級，為每個分區提供更多的輸送量，以符合輸送量需求。但是，我們建議您考慮修改請求模式或資料模型，以實現主索引鍵之間的相對隨機存取模式。

問：如果我只擷取 JSON 文件的某一個元素，是否會被收取整個項目的讀取費用？

是。讀取 DynamoDB 中的資料時，您消耗的是讀取整個項目所需的輸送量。

問：單一 DynamoDB 表可佈建的最大輸送量為何？

DynamoDB 的設計旨在實現無限制的擴展。但是，如果您希望個別表格超過 10,000 個寫入容量單位或 10,000 個讀取容量單位的輸送率，您必須先透過此線上表單與 Amazon 聯絡。如果希望從單一訂閱者帳戶佈建超過 20,000 個寫入容量單位或 20,000 個讀取容量單位，必須先使用上述表單聯絡我們。

問：單一 DynamoDB 表可佈建的最小輸送量為何？

對於 Auto Scaling 和手動佈建輸送量，您可以佈建的最小輸送量都是 1 個寫入容量單位和 1 個讀取容量單位。

這屬於免費方案的範圍，免費方案允許 25 個寫入容量單位和 25 個讀取容量單位。免費方案適用於帳戶等級而非表格等級。換句話說，如果您加總所有表格的佈建容量，總容量不超過 25 個寫入容量單位和 25 個讀取容量單位，您的佈建容量就屬於免費方案範圍。

問：透過單一請求可變更的佈建輸送量是否有任何限制？

您可以使用 UpdateTable API，增加任意數量表格佈建的輸送容量。例如，您可以透過單一 API 呼叫，將表格的佈建寫入容量從 1 個寫入容量單位提高到 10,000 個寫入容量單位。您的帳戶仍然受限於表格級和帳戶級容量限制，如文件頁面所述。如果您需要提高佈建容量限制，可以瀏覽我們的支援中心，按一下 "Open a new case" 並傳送提高服務限制的請求。

問：佈建的輸送量如何收費？

每個 Amazon DynamoDB 表都已經預先佈建達到您請求的輸送率所需的資源。只要您的表格消耗這些資源，即按小時費率計費。如需完整價目表以及相關範例，請參閱 DynamoDB 定價頁面。

問：如何變更現有 DynamoDB 表的佈建輸送量？

有兩種方式可更新 Amazon DynamoDB 表的佈建輸送量。您可以在管理主控台進行變更，或是使用 UpdateTable API 呼叫進行變更。在這兩個方式中，當佈建輸送量等級提高或降低時，Amazon DynamoDB 將保持在可用狀態。

問：多久可以變更一次佈建的輸送量？

您可以隨時提高佈建的輸送量，每天最多可以縮減 4 次輸送量，不限時間。一天是根據 GMT 時區來定義。此外，如果過去 4 個小時內沒有任何縮減，便允許 1 次額外的縮減，等於一天內最多可縮減 9 次 (第一個 4 小時 4 次縮減，當天後續每 4 小時 1 次額外縮減)。

請注意，如果 Amazon DynamoDB 表仍在回應您的上一個佈建輸送量變更請求，您無法變更佈建的輸送量。使用管理主控台或 DescribeTables API 可以查看表格的狀態。如果狀態為 "CREATING"、"DELETING" 或 "UPDATING"，您將無法調整表格的輸送量。請等待表格進入 "ACTIVE" 狀態，然後重試。

問：一致性等級是否會影響輸送率？

是。對於特定的資源分配，DynamoDB 表可以實現的讀取速率在強制一致性讀取和最終一致讀取是不同的。如果您請求「1,000 個讀取容量單位」，DynamoDB 將分配足夠的資源，以達成最大 4 KB 項目每秒 1,000 次強制一致性讀取。如果您需要實現最大 4 KB 項目 1,000 次最終一致讀取，則只需要一半的容量，即 500 個讀取容量單位。如需為表格選擇適當輸送率的更多指導，請參閱佈建的輸送量指南。

問：項目大小是否會影響輸送率？

是。對於特定的資源分配，DynamoDB 表可以達到的讀取速率取決於項目的大小。當您指定希望達到的佈建讀取輸送量時，DynamoDB 會假設項目小於 4 KB，以此大小來佈建資源。每增加 4 KB，達到相同輸送率所需的資源也會線性增加。例如，如果您為 DynamoDB 表佈建 100 個讀取容量單位，表示它每秒可以處理 100 個 4 KB 讀取操作、或 50 個 8 KB 讀取操作，或 25 個 16 KB 讀取操作，以此類推。

同樣地，DynamoDB 表所能達到的寫入速率也取決於項目的大小。當您指定希望達到的佈建寫入輸送量時，DynamoDB 會假設項目小於 1 KB，以此大小來佈建資源。每增加 1 KB，達到相同輸送率所需的資源也會線性增加。例如，如果您為 DynamoDB 表佈建 100 個寫入容量單位，表示它每秒可以處理 100 個 1 KB 寫入操作、或 50 個 2 KB 寫入操作，或 25 個 4 KB 寫入操作，以此類推。

如需為表格選擇適當輸送率的更多指導，請參閱佈建的輸送量指南。

問：如果我的應用程式執行的讀取或寫入次數超過我的佈建容量，會發生什麼狀況？

如果應用程式的每秒讀取次數或每秒寫入次數超過表格佈建的輸送容量允許範圍，則超出佈建容量的請求將受到節流控制，您會收到 400 錯誤代碼。例如，如果您請求 1,000 個寫入容量單位，並嘗試執行 1 KB 項目每秒 1,500 次寫入，DynamoDB 將只允許每秒執行 1,000 次寫入，您的額外請求將收到錯誤代碼 400。您應該使用 CloudWatch 來監控請求速率，以確保永遠有足夠的佈建輸送量來達到所需的請求速率。

問：如何得知是否超過佈建的輸送容量？

DynamoDB 以 CloudWatch 指標的形式公佈您消耗的輸送容量。您可以在這個指標上設定警示，就可以在接近佈建的容量時收到通知。

問：變更表格的佈建輸送量等級需要多長時間？

一般而言，在任何地方降低輸送量需要幾秒到幾分鐘，而在任何地方提高輸送量則需要幾分鐘到幾小時。

我們強烈建議，不要在需要額外輸送量時才設法增加輸送量。我們建議您提前佈建足夠的輸送容量，以確保在需要時能隨時取得容量。

問：什麼是預留容量？

預留容量是一種計費功能，可讓您享有佈建的輸送容量的折扣。所需條件如下：

• 一次性前期費用
• 合約期間承諾每月最低用量。

預留容量適用於單一 AWS 區域，可購買 1 年期或 3 年期。無論是 Auto Scaling 管理還是您在建立或更新表格時手動佈建的 DynamoDB 表，每個表格都有關聯的佈建的輸送容量。此容量決定您的 DynamoDB 表可以達到的讀取和寫入輸送率。預留容量是一種計費管理方式，對 DynamoDB 表的效能或容量沒有直接影響。例如，如果您購買 100 個寫入容量單位的預留容量，即表示您同意在合約期間 (1 年或 3 年) 支付該容量的費用，以換取定價折扣。

問：如何購買預留容量？

登入 AWS 管理主控台，移至 DynamoDB 主控台頁面，然後按一下 "Reserved Capacity"。這會進入 "Reserved Capacity Usage" 頁面。按一下 "Purchase Reserved Capacity"，系統會顯示一個讓您填寫購買預留容量的表單。確定已選擇要在其中使用預留容量的 AWS 區域。完成購買預留容量後，您將在 "Reserved Capacity Usage" 頁面中看到您購買的項目。

問：是否可取消購買預留容量？

否，您無法取消預留容量，而且一次性付款也無法退款。無論使用多少容量，在預留容量期限內都必須繼續支付小時費用。

問：購買預留容量的最低限額是多少？

最小的預留容量產品是 100 個容量單位 (讀取或寫入)。

問：有沒有用於購買預留容量的 API？

目前沒有。之後我們會提供 API 和更多預留容量選項。

問：是否可以將預留容量從一個區域移到另一個區域？

否。預留容量與單一區域關聯。

問：是否可以佈建比預留容量更多的輸送容量？

是。當您購買預留容量時，即表示您同意最低用量等級，並以折扣費率支付該用量等級的費用。如果您佈建的容量超過該最低等級，將按標準費率支付超出部分的費用。

問：如何使用我的預留容量？

預留容量會自動套用到您的帳單。例如，如果您購買 100 個寫入容量單位的預留容量，而且已佈建 300 個寫入容量單位。那麼，您的預留容量購買將自動涵蓋 100 個寫入容量單位的費用，您將按標準費率支付其餘 200 個寫入容量單位的費用。

問：如果我佈建的輸送容量少於預留容量，會發生什麼狀況？

預留容量購買是同意在合約期間內支付最低數量的佈建的輸送容量費用，以獲得折扣定價。如果您的使用量少於預留容量，每個月仍需支付該最低數量的佈建的輸送容量費用。

問：是否可以將我的預留容量用於多個 DynamoDB 表？

是。預留容量可用於您購買預留容量的區域內的總佈建容量。例如，如果您購買 5,000 個寫入容量單位的預留容量，可以將其用於有 5,000 個寫入容量單位的一個表格，或者有 50 個寫入容量單位的 100 個表格，或者有 5 個寫入容量單位的 1,000 個表格，等等。

問：預留容量是否會套用到合併帳單帳戶中的 DynamoDB 用量？

是。如果有多個帳戶與合併帳單連結，無論是付款人帳戶等級或連結帳戶等級購買的預留容量單位，都會與連結到付款人帳戶的所有帳戶共用。預留容量會首先套用到購買它的帳戶，然後未使用的任何容量會套用到其他連結的帳戶。

 

問：什麼是 DynamoDB 跨區域複寫？

DynamoDB 跨區域複寫讓您能夠在一個或多個 AWS 區域中維護完全相同的 DynamoDB 表格 (稱為主表格) 副本 (稱為複本)。為表格啟用跨區域複寫後，您可以在其他 AWS 區域中建立完全相同的表格副本。在表格中寫入的內容會自動傳播到所有複本。

 

問：何時應使用跨區域複寫？

在下列情況下，您可以使用跨區域複寫。

• 提高災難復原的效率：將表格複製到多個資料中心，在資料中心出現故障時，您可以切換為使用另一個區域的 DynamoDB 表格。
• 加快讀取速度：如果您的客戶位於多個區域，則可以讀取最靠近 AWS 資料中心的 DynamoDB 表格，更快速地提供資料。
• 簡化流量管理：您可以使用複本跨表格分配讀取工作負載，藉此降低主表格佔用的讀取容量。
• 便於區域遷移：在新區域中建立僅供讀取複本，然後將此複本提升為主表格，您便能更輕鬆地將應用程式遷移到該區域中。
• 即時資料遷移：若要將 DynamoDB 表格從一個區域移至另一個區域，您可以在目標區域中建立來源區域的表格複本。當表格進行同步後，您可以將應用程式切換為寫入目標區域。
  

問：支援哪種跨區域複寫模式？

目前跨區域複寫支援單一主模式。單一主模式是指有一個主表格以及一個或多個複本表格。

問：如何為表格設定單一主模式的跨區域複寫？

您可以使用 DynamoDB 跨區域複寫程式庫建立跨區域複本。

問：如何得知引導操作何時完成？

在複寫管理應用程式上，複寫狀態會從 Bootstrapping 變為 Active。

問：單一主表格是否能有多個複本？

是，單一主表格的複本表格數量沒有任何限制。系統會為每個複本表格建立一個 DynamoDB Streams 讀取程式，這些讀取程式會複寫主表格中的資料，讓複本保持同步。

問：為表格設定跨區域複寫需要支付多少費用？

使用 DynamoDB 跨區域複寫程式庫可啟用 DynamoDB 跨區域複寫。您無須為跨區域複寫程式庫支付額外費用，只需針對程序使用的下列資源支付一般費用。您需要支付的費用包括：

• 佈建輸送量 (寫入和讀取) 以及複本表格的儲存。
• 跨區域資料傳輸。
• 從 DynamoDB Streams 讀取資料並讓表格保持同步。
• 對託管複寫程序佈建的 EC2 執行個體。執行個體費用取決於您選擇的執行個體類型和託管執行個體的區域。

問：託管跨區域複寫的 Amazon EC2 執行個體會在哪個區域執行？

託管跨區域複寫應用程式的 Amazon EC2 執行個體位於跨區域複寫應用程式最初啟動時所在的同一個區域。您需要按照此區域的執行個體價格支付費用。

問：Amazon EC2 執行個體是否隨主表格和複本表格的大小和輸送量的變更而自動擴展？

我們目前無法自動擴展 EC2 執行個體。當設定 DynamoDB 跨區域複寫時，您將需要挑選執行個體大小。

問：如果管理複寫的 Amazon EC2 執行個體發生故障，會發生什麼情況？

Amazon EC2 執行個體是在 Auto Scaling 群組的幕後執行，這表示應用程式會將故障自動容錯移轉到其他執行個體。底層應用程式使用 Kinesis Client Library (KCL)，可對副本進行檢查點的檢查。如果執行個體發生故障，則應用程式會知道要去尋找檢查點，並從檢查點恢復。

問：建立僅供讀取複本期間，是否可繼續使用我的 DynamoDB 表格？

是，建立複本是一項線上操作。建立僅供讀取複本期間，您的表格仍可以執行讀取和寫入操作。引導操作使用掃描操作複製來源表格中的內容。我們建議為表格佈建足夠的讀取容量單位，以支援掃描操作。

 

問：建立複寫需要多長時間？

最初從主表格到複本表格的複寫時間取決於主表格的大小、主表格和複本表格的佈建容量。將主表格上的項目等級變更傳播到複本表格的時間取決於主表格和複本表格上的佈建容量，以及執行複寫應用程式的 Amazon EC2 執行個體大小。

問：如果變更了主表格上的佈建容量，則複本表格上的佈建容量是否也會隨之更新？

建立複寫後，主表格上的任何佈建容量變更都不會更新複本表格的輸送容量。

 

問：複本表格的索引是否與主表格相同？

如果您選擇透過複寫應用程式建立複本表格，則主表格上的次要索引不會自動建立在複本表格上。複寫應用程式不會將主表格的次要索引變更傳播到複本表格中。您必須透過 AWS 管理主控台新增/更新/刪除每個複本表格上的索引，就像處理一般的 DynamoDB 表格一樣。

 

問：複本佈建的輸送容量是否與主表格相同？

我們建議您在建立複本表格時，至少佈建與主表格相同的寫入容量，以確保複本表格有足夠的容量來處理傳入的所有寫入操作。您可以在適合您應用程式的任意等級，設定複本表格的佈建讀取容量。

 

問：什麼是複本表格的一致性模式？

複本為非同步更新。DynamoDB 會將主表格接受的寫入操作確認為成功的寫入操作。然後，寫入操作會傳播到每個複本。這表示寫入操作傳播到所有複本表格之前會略有延遲。

問：跨區域複寫是否有 CloudWatch 指標？

CloudWatch 指標適用於所有複寫設定。您可以選擇複寫群組，然後瀏覽至監控標籤查看指標。您可以查看輸送量和已處理的記錄數的相關指標，並能監控主表格和複本表格之間的任何輸送量差異。

問：是否能在主表格所在的同一個區域擁有複本表格？

是，只要複本表格與主表格的名稱不同，就可以位於同一個區域中。

問：是否能在建立複寫群組後新增或刪除複本？

是，您可以隨時在複寫群組新增複本或從中刪除複本。

問：是否能在建立複本群組之後將其刪除？

是，刪除複寫群組也會刪除此群組的 EC2 執行個體。不過，您必須刪除 DynamoDB 中繼資料表格。

問：什麼是 DynamoDB Triggers？

DynamoDB Triggers 的功能讓您能根據 DynamoDB 表格上的項目等級更新來執行自訂動作。您可以在程式碼中指定自訂動作。

問：DynamoDB Triggers 可以用來做什麼？

DynamoDB Triggers 適用於多個應用程式案例。一些使用案例包含傳送通知、更新彙總表格以及將 DynamoDB 表格連接到其他資料來源。

問：DynamoDB Triggers 如何運作？

DynamoDB Triggers 的自訂邏輯以程式碼形式存放在 AWS Lambda 函數中。若要為指定的表格建立觸發，可將 AWS Lambda 函數與 DynamoDB 表格上的串流 (透過 DynamoDB Streams) 建立關聯。當表格更新時，更新便會發佈到 DynamoDB Streams 中。反之，AWS Lambda 會從關聯的串流中讀取更新，並執行函數中的程式碼。

問：使用 DynamoDB Triggers 需要支付多少費用？

使用 DynamoDB Triggers，您只需按 AWS Lambda 函數的請求數和 AWS Lambda 函數的執行時間支付費用。您可在這裡進一步了解有關 AWS Lambda 定價的資訊。您無須為 AWS Lambda 函數對與表格關聯的串流 (透過 DynamoDB Streams) 執行的讀取動作支付費用。

問：表格觸發的數量是否有限制？

表格觸發的數量沒有任何限制。

問：DynamoDB Triggers 支援哪些語言？

目前 DynamoDB Triggers 支援用 Javascript、Java 以及 Python 來編寫觸發函數。

問：API 是否支援建立、編輯或刪除 DynamoDB 觸發？

否，目前沒有用於建立、編輯或刪除 DynamoDB 觸發的原生 API。您必須使用 AWS Lambda 主控台建立 AWS Lambda 函數，並將它與 DynamoDB Streams 中的某個串流關聯。如需詳細資訊，請參閱 AWS Lambda 常見問答集頁面。

問：如何建立 DynamoDB 觸發？

建立觸發的方法是，建立一個 AWS Lambda 函數，然後將此函數的事件來源與 DynamoDB Streams 中的某個串流建立關聯。如需詳細資訊，請參閱 AWS Lambda 常見問答集頁面。

問：如何刪除 DynamoDB 觸發？

您可以刪除關聯的 AWS Lambda 函數來刪除觸發。您可以透過 AWS Lambda 主控台或 AWS Lambda API 呼叫來刪除 AWS Lambda 函數。如需詳細資訊，請參閱 AWS Lambda 常見問答集和文件頁面。

問：我有一個現有的 AWS Lambda 函數，如何建立使用此函數的 DynamoDB 觸發？

您可以將 AWS Lambda 函數的事件來源變更為指向 DynamoDB Streams 中的某個串流。您可以透過 DynamoDB 主控台執行此動作。在啟用的串流表格中，依序選擇對應的串流和關聯的 Lambda 函數按鈕，然後在 Lambda 函數清單中選擇要用於 DynamoDB 觸發的函數。

問：哪些區域可以使用 DynamoDB Triggers？

可使用 AWS Lambda 和 DynamoDB 的所有 AWS 區域皆可使用 DynamoDB Triggers。

問：什麼是 DynamoDB Streams？

DynamoDB Streams 會按時間順序排序過去 24 小時內表格中的項目等級的資料變更。您可以透過簡單的 API 呼叫存取串流，並使用它將其他資料存放區保持在 DynamoDB 最新變更的最新狀態，或根據表格變更採取動作。

問：DynamoDB Streams 有哪些優點？

開發人員透過使用 DynamoDB Streams API 可以在項目變更前後取用更新並接收項目層級的資料。這可以用來為建置在 DynamoDB 上的應用程式建立有創意的延伸功能。例如，開發人員使用 DynamoDB 建置全球多人遊戲時，可使用 DynamoDB Streams API 建置多主機拓撲結構，並透過使用各主機的 DynamoDB Streams 和重新執行遠端主機中的更新，以保持各主機的同步。另一個例子是，開發人員可使用 DynamoDB Streams API 建置行動應用程式，只要使用者上傳新的自拍，就會自動通知朋友圈中所有好友的行動裝置。開發人員還可以使用 DynamoDB Streams 保持 Amazon Redshift 等資料倉儲工具與其 DynamoDB 表所有變更同步，以啟用即時分析。DynamoDB 也使用 Amazon DynamoDB Logstash 外掛程式與 Elasticsearch 整合，讓開發人員能夠為 DynamoDB 內容新增任意文字搜尋。

更多有關 DynamoDB Streams 的資訊，請參閱我們的文件。

問：透過 DynamoDB Streams 的 DynamoDB 表變更可用多久？

DynamoDB Streams 會將表格的所有變更保持記錄 24 小時。此後即清除。

問：如何啟用 DynamoDB Streams？

DynamoDB Streams 必須以每個表格為基礎啟用。要為現有的 DynamoDB 表啟用 DynamoDB Streams，需先透過 AWS 管理主控台選取表格，再選擇 Overview 標籤，接著按一下 Manage Stream 按鈕，然後選擇一種檢視類型，最後按一下 Enable。

如需詳細資訊，請參閱我們的文件。

問：如何驗證 DynamoDB Streams 是否已啟用？

啟用 DynamoDB Streams 後，您可以在 AWS 管理主控台中看到串流。選擇您的表格，然後選擇 Overview 標籤。在 Stream 詳細資訊下方，確認 Stream 啟用是設定為 Yes。

問：如何存取 DynamoDB Streams？

您可以透過 DynamoDB Streams 使用 DynamoDB 開發套件，透過簡單的 API 呼叫存取串流，也可以使用 Kinesis Client Library (KCL)。KCL 可協助您使用和處理串流的資料，也有助於管理各項任務，例如，多個閱讀器之間的負載平衡、回應執行個體故障，以及檢查指向處理記錄。

如需存取 DynamoDB Streams 的詳細資訊，請參閱我們的文件。

問：DynamoDB Streams 是否會依照順序顯示 DynamoDB 表的所有更新？

任何個別項目的變更會以正確的順序顯示。不同項目的變更可能會以不同於它們的接收順序顯示在 DynamoDB Streams 中。

例如，假設您有一個追蹤遊戲高分的 DynamoDB 表，且該表格中的每個項目都代表一個玩家。如果您以此順序進行以下三種更新：

• 更新 1：將玩家 1 的最高分改為 100 分
• 更新 2：將玩家 2 的最高分改為 50 分
• 更新 3：將玩家 1 的最高分改為 125 分
  

更新 1 和更新 3 變更的是同一個項目 (玩家 1)，所以 DynamoDB Streams 將在更新 1 之後顯示更新 3。這樣，您就可以擷取每個玩家的最新高分。串流可能不會以相同順序顯示這三個進行的更新 (即，更新 2 在更新 1 之後，在更新 3 之前)，但每位玩家記錄的更新會以正確的順序顯示。

問：是否需要管理 DynamoDB Streams 的串流容量？

否，DynamoDB Streams 會自動管理串流的容量。如果您大幅增加 DynamoDB 表的流量，DynamoDB 會自動調整串流的容量，使它能夠繼續接受所有更新。

問：從 DynamoDB Streams 讀取的速率為何？

從 DynamoDB Streams 串流讀取更新的速率最高可達 DynamoDB 表佈建寫入容量的兩倍。例如，如果您已佈建足夠的容量，可在 DynamoDB 表中每秒更新 1,000 個項目，則您每秒最多可從串流中讀取 2,000 個更新。

問：如果刪除 DynamoDB 表，是否也會刪除 DynamoDB Streams 串流？

否，不會立即刪除。DynamoDB Streams 串流將存續 24 個小時，讓您有機會讀取表格的最新更新。24 小時後，串流便會自動從 DynamoDB Streams 中刪除。

問：如果關閉表格的 DynamoDB Streams，會發生什麼狀況？

如果關閉 DynamoDB Streams，串流將存續 24 小時，但不會更新 DynamoDB 表的任何其他變更。

問：如果關閉 DynamoDB Streams 後再重新開啟，會發生什麼狀況？

當您關閉 DynamoDB Streams 時，串流將存續 24 小時，但不會更新 DynamoDB 表的任何其他變更。如果重新開啟 DynamoDB Streams，將會建立一個新的 DynamoDB Streams 串流，其中包含從新的串流建立時開始，對 DynamoDB 表所做的變更。

問：DynamoDB Streams 中是否會有重複或缺漏？

否，DynamoDB Streams 的設計能夠將表格的每個更新一次正確無誤的呈現在串流中。

問：DynamoDB Streams 中包含哪些資訊？

DynamoDB 串流將包含項目先前值和變更後值的資訊。串流還包含變更類型 (INSERT、REMOVE 和 MODIFY) 以及發生變更的項目的主索引鍵。

問：如何選擇包含在 DynamoDB Streams 中的資訊？

如果是新表格，使用 CreateTable API 呼叫，並指定 ViewType 參數來選擇將哪些資訊包含在串流中。
如果是現有的表格，使用 UpdateTable API 呼叫，並指定 ViewType 參數來選擇將哪些資訊包含在串流中。

ViewType 參數會使用以下值：

ViewType: {
                    { KEYS_ONLY,
                      NEW_IMAGE,
                      OLD_IMAGE,
                      NEW_AND_OLD_IMAGES}
                }

這些值分別代表下列意義：KEYS_ONLY：僅變更過的項目索引鍵名稱包含在串流中。

• NEW_IMAGE：索引鍵名稱和更新後的項目 (新項目) 包含在串流中。
• OLD_IMAGE：索引鍵名稱和更新前的項目 (舊項目) 包含在串流中。
• NEW_AND_OLD_IMAGES：索引鍵名稱、更新前項目 (舊項目) 和更新後項目 (新項目) 包含在串流中。

問：是否可使用 Kinesis Client Library 存取 DynamoDB Streams？

是，熟悉 Kinesis API 的開發人員將能夠輕鬆地使用 DynamoDB Streams。您可以使用實作 Amazon Kinesis 界面的 DynamoDB Streams 配接器，讓應用程式使用 Amazon Kinesis 用戶端程式庫 (KCL) 存取 DynamoDB Streams。如需使用 KCL 存取 DynamoDB Streams 的詳細資訊，請參閱我們的文件。

問：是否可變更 DynamoDB Streams 中所包含的資訊類型？

如果您要在串流建立後變更其中儲存的資訊類型，必須停用串流，並使用 UpdateTable API 建立新的串流。

問：變更 DynamoDB 表後，該變更需要多久才會出現在 DynamoDB 串流中？

變更通常會在一秒之內反映在 DynamoDB 串流中。

問：如果刪除某個項目，該變更是否會包含在 DynamoDB Streams 中？

是，DynamoDB 串流中的每個更新都包含一個參數，該參數指定更新是刪除、插入新項目還是對現有項目的修改。如需更新類型的詳細資訊，請參閱我們的文件。

問：為表格開啟 DynamoDB Streams 之後，何時可開始從串流讀取資訊？

您可以使用 DescribeStream API 取得串流的目前狀態。一旦狀態變更為 ENABLED，表格的所有更新都將呈現在串流中。

您可以在開始建立串流時就開始從中讀取資訊，但在狀態變更為 ENABLED 之前，串流中可能不會包含表格的所有更新。

問：什麼是適用於 Elasticsearch 的 Amazon DynamoDB Logstash 外掛程式？

Elasticsearch 是專為簡化即時搜尋和大數據分析所設計的熱門開放原始碼搜尋和分析引擎。Logstash 是與 Elasticsearch 配合使用的開放原始碼資料管道，可協助您處理日誌與其他事件資料。Amazon DynamoDB Logstash 外掛程式能輕鬆將 DynamoDB 表與 Elasticsearch 叢集整合。

問：Amazon DynamoDB Logstash 外掛程式的費用是多少？

您可以免費下載和使用 Amazon DynamoDB Logstash 外掛程式。

問：如何下載和安裝 Amazon DynamoDB Logstash 外掛程式？

您可在 GitHub 取得 Amazon DynamoDB Logstash 外掛程式。請閱讀我們的文件頁面，進一步了解有關安裝和執行外掛程式的資訊。

問：什麼是適用於 Titan 的 DynamoDB 儲存後端？

適用於 Titan 的 DynamoDB 儲存後端是一個外掛程式，讓您可以使用 DynamoDB 作為 Titan 圖形資料庫的基礎儲存層。這是一種用戶端解決方案，可在 DynamoDB 之上針對快速圖形周遊實作無須索引的鄰接。

問：什麼是圖形資料庫？

圖形資料庫是一個存放區，用於存放點和連接這些點的邊。點和邊都可以有儲存為鍵值組的屬性。

圖形資料庫使用相鄰清單存放邊，以允許簡單的周遊。圖形資料庫中的圖形可沿特定的邊類型或跨整個圖形周遊。圖形資料庫可使用動作、擁有權、來源等等呈現實體的相關性。

問：哪些應用程式適用於圖形資料庫？

只要實體之間的連線或關係位於您嘗試要建立模型的資料核心，圖形資料庫就是當然之選。因此，圖形資料庫非常適用於社交網路、商業關係、相依性、運輸路線等等的模型建立和查詢。

問：如何開始使用適用於 Titan 的 DynamoDB 儲存後端？

開始使用最簡單的方式是使用此文件頁面所提到的 CloudFormation 範本，啟動以適用於 Titan 的 DynamoDB 儲存後端執行 Gremlin 伺服器的 EC2 執行個體。您也可以從 GitHub 儲存庫複製專案，並依照這裡的文件中的指示，在自己的電腦上跟隨 Marvel 和 Graph-Of-The-Gods 教學開始使用。當您準備好擴展測試或執行生產，可以切換後端使用 DynamoDB 服務。請查看 AWS 文件了解進一步的指導。

問：DynamoDB 儲存後端與其他 Titan 儲存後端有什麼不同？

DynamoDB 是受管的服務，因此將它做為 Titan 的儲存後端時，您不必為圖形儲存管理自己的叢集就能夠執行圖形工作負載。

問：適用於 Titan 的 DynamoDB 儲存後端是否為完全受管的服務？

否。適用於 Titan 的 DynamoDB 儲存後端會管理 Titan 工作負載的儲存層。不過，外掛程式不會佈建和管理用戶端。我們已針對簡單的 Titan 佈建開發了一個 CloudFormation 範本，該範本以 Gremlin 伺服器設定適用於 Titan 的 DynamoDB 儲存後端；請參閱這裡取得說明。

問：使用適用於 Titan 的 DynamoDB 儲存後端的費用是多少？

您只需支付一般 DynamoDB 輸送量和儲存費用。使用 DynamoDB 作為 Titan 圖形工作負載的儲存後端不會收取額外費用。

問：DynamoDB 後端是否提供與其他後端 Titan 功能集的完整相容性？

您可以在文件查閱不同 Titan 儲存後端功能集的比較表。

問：外掛程式支援哪些版本的 Titan？

我們已發行適用於 Titan 版本 0.5.4 和 1.0.0 的 DynamoDB 儲存後端外掛程式。

問：我現在使用 Titan 搭配不同的後端。可以遷移到 DynamoDB 嗎？

當然可以。適用於 Titan 的 DynamoDB 儲存後端會實作 Titan KCV 存放區界面，所以只需要稍微修改應用程式，就可以從不同的儲存後端切換到 DynamoDB。有關適用於 Titan 的各種儲存後端的完整比較，請參閱我們的文件。

問：我現在使用 Titan 搭配不同的後端。如何遷移到 DynamoDB？

您可以使用大批載入，將您的圖形從一個儲存後端複製到適用於 Titan 的 DynamoDB 儲存後端。

問：如何透過外掛程式將我的 Titan 執行個體連接到 DynamoDB？

如果您在已安裝適用於 Titan 的 DynamoDB 儲存後端的情況下建立圖形和 Gremlin 伺服器執行個體，則連接到 DynamoDB 唯一需要做的就是將委託人/登入資料組提供給預設的 AWS 登入資料供應商鏈。使用 EC2 執行個體描述檔、環境變數或是您主資料夾中的登入資料檔即可完成。最後，您需要選擇要連接的 DynamoDB 端點。

問：使用適用於 Titan 的 DynamoDB 儲存後端時，我的資料耐用性如何？

使用適用於 Titan 的 DynamoDB 儲存後端時，您的資料會受到 DynamoDB 的強大保護，此服務是在 Amazon 經過驗證的高可用性資料中心執行。而且此服務會在 AWS 區域的三個設施上複製資料，以便在發生伺服器故障或可用區域執行中斷時提供容錯能力。

問：適用於 Titan 的 DynamoDB 儲存後端的安全性如何？

適用於 Titan 的 DynamoDB 儲存後端將圖形資料存放在多個 DynamoDB 表中，所以能夠享有在所有 DynamoDB 工作負載上提供的相同高安全性。精細的存取控制、IAM 角色以及 AWS 委託人/登入資料組可控制 DynamoDB 表與 DynamoDB 表中項目的存取。

問：適用於 Titan 的 DynamoDB 儲存後端如何擴展？

適用於 Titan 的 DynamoDB 儲存後端的擴展方式和 DynamoDB 的任何其他工作負載一樣。您可以隨時選擇要增加或減少所需的輸送量。

問：我的圖形可以包含多少點與邊？

這受限於 Titan 的限制，只要邊存放區使用多項目模型，圖形中的邊數量上限為 (2^60)，而點的數量為邊的一半。如果您使用單一項目模型，則可在特定點外鍵值存放的邊數受限於 DynamoDB 的項目大小上限，目前為 400 kb。

問：我的點與邊屬性可以成長到多大？

多項目模型中的所有邊屬性總和不可以超過 400 kb，也就是項目大小上限。在多項目模型中，每個點屬性最多可達 400 kb。在單一項目模型中，總項目大小 (包含點屬性、邊及邊屬性) 不可以超過 400 kb。

問：有多少個資料模型？有什麼差別？

適用於 Titan 的 DynamoDB 儲存後端有兩種不同的儲存模型 – 單一項目模型與多項目模型。在單一項目儲存模型中，點、點屬性以及邊是儲存在一個項目中。而在多項目資料模型中，點、點屬性以及邊是儲存在不同項目中。在這兩個模型中，邊屬性都是儲存在邊所對應的相同項目中。

問：我該使用哪種資料模型？

一般而言，我們建議您針對邊存放區與圖形索引表格使用多項目資料模型。否則，您就要限制在一個點外可以存放的邊/點屬性數目，或是要限制在圖形索引中特定的屬性名稱值組可以製作索引的實體數目。一般可以為 Titan 版本 0.5.4 和 1.0.0 中其他 4 KCV 存放區使用單一項目資料模型，因為其中存放的每個項目通常小於 400 KB。有關 Titan 外掛程式在 DynamoDB 上建立的表格完整清單，請參閱這裡。

問：是否需要為 Titan 圖形資料庫建立結構描述？

Titan 支援自動類型建立，所以新的邊/點屬性與標籤會在首次使用時立即註冊 (請參閱這裡以取得詳細資訊)。預設會使用 Gremlin 結構 (Edge 標籤=MULTI、Vertex 屬性=SINGLE)。

問：是否可以變更 Titan 圖形資料庫的結構描述？

是，但是不可以變更現有點/邊屬性與標籤的結構描述。關於詳細資訊，請參閱這裡。

問：適用於 Titan 的 DynamoDB 儲存後端如何處理超級節點？

DynamoDB 透過點標籤資料分割來處理超級節點。如果您建立點標籤時在管理系統中將其定義為已分割，則可在邊存放區表格的分區排序索引鍵值空間，於不同分區索引鍵值輸入傳出點的邊與點屬性的不同子集。只要您的邊存放區有超過一個實體分割區，這通常會導致虛擬點標籤分割區儲存在不同的實體 DynamoDB 分割區。要預估備份邊存放區表格的實體分割區數目，請參閱文件中的指導。

問：適用於 Titan 的 DynamoDB 儲存後端是否支援批次圖形操作？

是，適用於 Titan 的 DynamoDB 儲存後端使用 Blueprints BatchGraph 實作，並透過 Titan 的大批載入組態選項來支援批次圖形。

問：適用於 Titan 的 DynamoDB 儲存後端是否支援交易？

適用於 Titan 的 DynamoDB 儲存後端支援開放式鎖定。這表示適用於 Titan 的 DynamoDB 儲存後端可以決定在該鍵值欄組或鍵值的現有值上寫入個別鍵值欄組 (在多項目模型) 或個別鍵值 (在單一項目模型)。

問：是否可以在一個區域有 Titan 執行個體，然後在另一個區域存取 DynamoDB？

雖然可以存取與 EC2 Titan 執行個體不同區域中的 DynamoDB 端點，但不建議這樣做。在 EC2 外執行 Gremlin 伺服器時，建議連接到 EC2 執行個體區域中的 DynamoDB 端點，以降低跨區域請求的延遲影響。我們也建議在 VPC 執行 EC2 執行個體以改善網路效能。CloudFormation 範本可以為您執行這整個組態。

問：是否可以搭配更新串流和跨區域複寫等其他 DynamoDB 功能來使用此外掛程式？

您可以使用跨區域複寫搭配 DynamoDB Streams 功能，在其他區域建立圖形表格的僅供讀取複本。

問：Amazon DynamoDB 是否會回報 CloudWatch 指標？

是，Amazon DynamoDB 在 CloudWatch 上會回報數個表格層級的指標。您可以為 Amazon DynamoDB 表做出操作決定並採取特定動作，例如根據這些指標設定警示。如需所回報指標的完整清單，請參閱我們文件中的使用 CloudWatch 監控 DynamoDB 章節。

問：如何檢視 Amazon DynamoDB 表的 CloudWatch 指標？

在 Amazon DynamoDB 主控台，選取您要檢視 CloudWatch 指標的表，然後選取 Metrics 標籤。

問：回報指標的頻率為何？

大多數適用於 Amazon DynamoDB 的 CloudWatch 指標會以 1 分鐘的間隔回報，而其他指標則以 5 分鐘的間隔回報。有關詳細資訊，請參閱我們文件中的使用 CloudWatch 監控 DynamoDB 章節。

問：什麼是標籤？

標籤是您指派給 AWS 資源的標記。每個標籤都由您可以定義的鍵值和數值組成。AWS 使用標籤做為一種機制，在成本分配報告上組織資源成本。如需標記的詳細資訊，請參閱 AWS Billing and Cost Management User Guide。

問：我可以標記哪些 DynamoDB 資源？

您可以標記 DynamoDB 表。與已標記表格關聯的本機次要索引和全域次要索引會自動加上相同的標籤。本機次要索引和全域次要索引的成本會顯示在對應 DynamoDB 表所使用的標籤底下。

問：為什麼要使用 DynamoDB 標記？

您可以使用 DynamoDB 標記來分配成本。使用標籤進行成本分配可讓您在 DynamoDB 資源指派標記，以便根據專案或其他條件輕鬆追蹤成本來反映自己的成本結構。

問：如何使用標籤來分配成本？

您可以使用成本分配標籤來分類和追蹤 AWS 成本。AWS 成本總管和詳細的帳單報告可支援依標籤列出 AWS 成本的明細。通常，客戶會使用成本中心/業務單位、客戶或專案等商業標籤來建立 AWS 成本與傳統成本分配方式的關聯。不過，成本分配報告可包含各種標籤。這樣可讓您輕鬆建立成本與技術或安全性方面的關聯，像是特定應用程式、環境或合規計劃。

問：如何查看分配到 AWS 已標記資源的成本？

您可以透過成本總管或成本分配報告，查看分配到 AWS 已標記資源的成本。

成本總管是免費的 AWS 工具，可用來查看最多 13 個月前的成本，並預測未來三個月可能的支出。您可以使用 "Tag" 篩選，然後選擇標籤鍵和值 (如果未指定標籤值，則選擇 "No tag")，查看特定標籤的成本。

成本分配報告包含每個計費期間的所有 AWS 成本。該報告同時包含已標記和未標記資源，因此您可以清楚地整理資源的費用。例如，如果您使用應用程式名稱來標記資源，則可追蹤在這些資源上執行的單一應用程式總成本。如需成本分配的詳細資訊，請參閱 AWS Billing and Cost Management User Guide。

問：是否可標記 DynamoDB Streams 的用量？

否，目前無法標記 DynamoDB Streams 的用量。

問：帳單的表格標籤下是否會顯示預留容量的用量？

是，每個表格的 DynamoDB 預留容量費用都會顯示在相關的標籤下。請注意，預留容量會在所有連結的 AWS 帳戶以先到先服務的方式套用到 DynamoDB 用量。這表示即使每個月表格和索引的 DynamoDB 用量很類似，但可能會在每個標籤的成本分配報告中看到些微差異，因為預留容量會依優先計算的 DynamoDB 資源進行分配。

問：帳單中的表格標籤下是否會顯示資料使用費？

否，不會標記 DynamoDB 資料使用費。這是因為資料用量是以帳戶層級而不是表格層級計費。

問：標籤是否需要值屬性？

否，標籤值可以是 NULL。

問：標籤是否區分大小寫？

是，標籤鍵和值會區分大小寫。

問：一個 DynamoDB 表可以新增幾個標籤？

您可以在一個 DynamoDB 表最多新增 50 個標籤。您無法手動建立前綴為 "aws:" 的標籤，且不計入每個資源標籤數量的限制。

問：是否可以將標籤追溯套用到我的 DynamoDB 表？

否，標籤會從套用當日開始整理並追蹤資料。如果您在 1 月 1 日建立表格，但等到 2 月 1 日才為它指定標籤，則該表格一月份的所有用量都會維持未標記的狀態。

問：如果在該月結束前從 DynamoDB 表移除標籤，該標籤是否仍然會顯示在帳單中？

是，如果您為特定時間期間建立一個追蹤開支的報告，則成本報告會顯示該時段已標記的資源成本。

問：如果刪除 DynamoDB 表，現有的標籤會如何？

刪除 DynamoDB 表之後，會自動移除其標籤。

問：如果我新增的標籤與現有標籤有相同的鍵值，會發生什麼狀況？

每個 DynamoDB 表最多只能有一個相同鍵值的標籤。如果您新增一個與現有標籤擁有相同鍵值的標籤，則現有標籤將會更新為新的值。

問：什麼是 DynamoDB 存留時間 (TTL)？

DynamoDB 存留時間 (TTL) 是一種機制，讓您設定特定的時間戳記，以從表格中刪除過期的項目。一旦時間戳記過期，對應的項目會標示為已過期，接著就會從表格中刪除。藉由使用這項功能，您就不用追蹤過期的資料並手動刪除它。TTL 可幫助降低儲存使用量並減少存放不再相關的資料的費用。

問：為什麼需要使用 TTL？

TTL 在兩個主要的案例中非常實用：

• 刪除不再相關的舊資料 – 像是事件日誌、使用歷史記錄、工作階段資料等等的資料。因為收集的資料量在一段時間後會膨脹，而存放在系統中的舊資料可能就不再具有相關性。在這種情況下，最好是從系統清除這些過時的記錄，這可省下存放資料所需支付的金錢。
• 有時候您希望在指定的一段時間內將資料保留 DynamoDB，以遵守資料保留和管理的政策。這段指定的時間期滿之後，您可能還是要刪除這些資料。請務必了解 TTL 會盡最大努力來確保有足夠的輸送量供其他關鍵操作使用。DynamoDB 的目標是在兩天的期間內刪除過期項目。實際所花的時間可能更長，這取決於資料的大小。

問：DynamoDB TTL 如何運作？

若要為表格啟用 TTL，請先確定有一個屬性可以存放表格中每個項目的過期時間戳記。這個時間戳記需要使用 epoch 時間格式。這可避免用戶端與伺服器之間的時區不一致。

DynamoDB 會在背景執行監控所有項目的掃描程序。如果時間戳記已經過期，程序會將項目標記為已過期並放入佇列，以便後續的刪除。

注意：TTL 需要一個填入 epoch 時間戳記的數值 DynamoDB 表格屬性，以指定資料的過期條件。設定 TTL 屬性的值時必須小心，因為錯誤的值可能造成太早刪除項目。

問：如何指定 TTL？

若要指定 TTL，請先在表格上啟用 TTL 設定，並指定屬性做為 TTL 值。當您將項目新增到表格時，如果希望 DynamoDB 在項目過期時自動刪除它，則可指定 TTL 屬性。這個值是過期時間，以 epoch 時間格式指定。DynamoDB 會負責其餘的工作。您可以從主控台中表格的概觀標籤來指定 TTL。或者，開發人員可以叫用 TTL API 來設定表格上的 TTL。請參閱我們的文件和 API Guide。

問：是否可以在現有的表格上設定 TTL？

是。如果已經建立表格，而且有可做為項目 TTL 的屬性，那麼只需要為表格啟用 TTL，然後為 TTL 指定適當的屬性即可。如果表格沒有可用於 TTL 的屬性，則必須建立這個屬性，然後使用 TTL 的值來更新項目。

問：是否可以在整個表格上設定 TTL 來刪除整個表格？

否。雖然您需要在表格等級定義用於 TTL 的屬性，但是刪除資料的精細度是位於項目等級。也就是說，表格中每個在過期後需要被刪除的項目，都必須為 TTL 屬性定義一個值。您無法選擇自動刪除整個表格。

問：是否可以只為表格中的一組項目設定 TTL？

是。TTL 只對定義了 TTL 屬性值的項目生效。表格中的其他項目都不受影響。

問：指定 TTL 的格式是什麼？

TTL 值應該使用 epoch 時間格式，這是自國際標準時間 1970 年 1 月 1 日開始的秒數。如果沒有為項目的 TTL 屬性值指定正確的格式，就會忽略該值，而且將不會刪除項目。

問：如何讀取表格中項目的 TTL 值？

TTL 值就像項目上的任何屬性一樣。讀取它的方式和讀取任何其他屬性的方式相同。為了更易於以視覺方式確認 TTL 值，DynamoDB 主控台允許您將滑鼠停留在 TTL 屬性上，以簡單易懂的當地時間和國際標準時間格式來查看它的值。

問：是否可以根據指派給表格中項目的 TTL 值來建立索引？

是。TTL 的使用方式就和任何其他項目屬性相同。您可以建立索引，就像對待其他項目屬性一樣。

問：TTL 屬性是否可以投影到索引？

是。TTL 屬性可以投影到索引，就像任何其他屬性一樣。

問：為項目設定 TTL 屬性值之後，是否可以編輯它？

是。修改 TTL 屬性值就和在項目上修改任何其他屬性一樣。

問：是否可以變更表格的 TTL 屬性？

是。如果表格已經啟用 TTL，而您想要指定不同的 TTL 屬性，那麼您需要先停用表格的 TTL，然後使用新的 TTL 屬性在表格上重新啟用 TTL。請注意，停用 TTL 最長可能要花一個小時來套用到所有分區，而且在這個動作完成之前，您將無法重新啟用 TTL。

問：是否可以使用 AWS 管理主控台來檢視和編輯 TTL 值？

是。AWS 管理主控台可讓您輕鬆檢視、設定或更新 TTL 值。

問：是否可以將 JSON 文件內的屬性設定為 TTL 屬性？

否。我們目前不支援將 JSON 文件中的屬性指定為 TTL 屬性。若要設定 TTL，您必須明確地將 TTL 屬性新增到每個項目。

問：是否可以為 JSON 文件中的特定元素設定 TTL？

否。TTL 值只能為整份文件設定。我們不支援在 JSON 文件中的特定項目過期時就刪除它。

問：如果我需要移除特定項目上的 TTL 會怎樣？

移除 TTL 就和移除指派到 TTL 屬性的值或移除項目的屬性本身一樣簡單。

問：如果我將 TTL 時間戳記值設定為過去的時間會怎樣？

系統允許以較舊的 TTL 值來更新項目。每次背景程序檢查過期項目時，它會尋找和標記項目，然後刪除該項目。不過，如果 TTL 屬性中的時間戳記值包含 epoch 值，而且時間戳記早於 5 年以前，那麼 DynamoDB 將忽略這個時間戳記，而且不會刪除該項目。這樣做是為了當 TTL 屬性中存放了很少的值時，可避免系統不小心刪除項目。

問：項目上 TTL 過期與實際刪除該項目之間的延遲為多久？

TTL 會使用系統中可用的背景輸送量來掃描和刪除過期項目。因此，可能不會立即從表格中刪除過期項目。DynamoDB 的目標是在兩天的期間內盡可能刪除過期的項目，以確保系統可在背景為其他資料操作提供輸送量。然而，項目在過期之後真正被刪除的確切時段，將取決於工作負載的本質和表格的大小。

問：如果我試著查詢或掃描已被 TTL 歸為過期的項目時，會發生什麼事？

鑑於項目過期之後到背景程序實際刪除它之間可能有延遲，所以如果您嘗試讀取已過期但尚未被刪除的項目，則傳回的結果將包含過期的項目。如果您的目的是不要顯示過期項目，則可以按照 TTL 值來篩選這些項目。

問：如果本機次要索引 (LSI) 中的資料過期，這些資料會發生什麼事？

影響就和任何刪除操作一樣。本機次要索引是存放在與項目本身相同的分區中。因此，如果刪除某個項目，就會立即從本機次要索引中移除它。

問：如果全域次要索引 (GSI) 中的資料過期，這些資料會發生什麼事？

影響就和任何刪除操作一樣。全域次要索引 (GSI) 最終還是會保持一致，所以當過期的原始項目被刪除的時候，GSI 可能需要一些時間來更新。

問：如何使用 TTL 搭配 DynamoDB Streams？

表格中資料的過期是因為觸發清除的 TTL 值，它會被記錄為刪除操作。所以，Streams 也將在其中記錄刪除操作。刪除記錄將有額外的限定詞，以便您區分您的刪除或因 TTL 而被刪除的資料。串流項目將在刪除的時間點寫入，而不是在 TTL 過期時間點，以反映刪除記錄的實際時間。請參閱我們的文件和 API Guide。

問：何時應該使用刪除操作，而何時又該使用 TTL？

TTL 很適合從表格移除過期的記錄。不過，它的用意是盡力執行操作，以協助您移除不想要的資料，但不保證刪除時段。因此，如果表格中的資料需要在特定時段內刪除 (通常是立即)，我們會建議使用刪除命令。

問：是否可以控制誰有權設定或更新 TTL 值？

是。TTL 屬性就像表格上任何其他屬性一樣。您能夠控制表格上屬性等級的存取權。TTL 屬性將遵循為表格指定的一般存取控制。

問：是否有方式可以擷取在 TTL 過期之後刪除的資料？

否。過期的項目在刪除之前是不會進行備份。您可以利用 DynamoDB Streams 來追蹤表格上的變更，並在需要時還原值。刪除記錄在刪除之後的 24 小時內可從 Streams 取得。

問：如何知道表格上是否已啟用 TTL？

只要叫用 DescribeTable API 或在 DynamoDB 主控台中檢視表格詳細資訊，就可以隨時取得 TTL 的狀態。請參閱我們的文件和 API Guide。

問：如何追蹤被 TTL 刪除的項目？

如果您已經啟用 DynamoDB Streams，所有 TTL 刪除將會出現在 DynamoDB Streams，並被指定為系統刪除，以區別它和您執行的明確刪除。您可以視需求從 Streams 讀取項目並加以處理，也可以編寫一個 Lambda 函數將項目分開存檔。請參閱我們的文件和 API Guide。

問：為資料啟用 TTL 功能是否必須支付一定費用？

否。啟用 TTL 不需額外付費。

問：啟用 TTL 會如何影響整體佈建的輸送用量？

TTL 所需的掃描和刪除操作是由系統執行，不會納入您佈建的輸送量或用量的計算。

問：是否必須支付監控 TTL 的掃描操作費用？

否。針對監控項目的 TTL 過期所執行的內部掃描操作，我們不會收取費用。此外，這些操作將不會影響表格的輸送用量。

問：過期項目的儲存費用是否會累計到刪除為止？

是。項目過期之後會被新增到刪除佇列以便後續刪除。不過，在它被刪除之前，仍可像任何一般項目一樣被讀取或更新，因此將產生儲存費用。

問：如果我查詢過期項目，是否會耗用我的讀取容量？

是。這種行為就像是您查詢表格中不存在的項目一樣。

問：什麼是 DynamoDB Accelerator (DAX)？

Amazon DynamoDB Accelerator (DAX) 是 DynamoDB 專用的全受管、高可用性的記憶體內快取，可讓您受益於為高需求應用程式提供的快速記憶體內效能。DAX 可改進讀取密集型 DynamoDB 工作負載的效能，以非常低的延遲立即重複讀取快取資料，無須從 DynamoDB 重新查詢。DAX 可在快取未命中時自動從 DynamoDB 表格擷取資料。寫入指定為使用直接寫入方式進行 (資料會先寫入 DynamoDB，然後在 DAX 快取中更新)。

如同 DynamoDB，DAX 具備容錯和可擴展性。DAX 叢集有一個主要節點和零或多個僅供讀取複本節點。在主要節點發生故障時，DAX 將會自動容錯移轉並選擇一個新的主要節點。如需擴展或縮減，您可以新增或移除僅供讀取複本。

若要開始使用，請建立 DAX 叢集、下載適用於 Java 或 Node.js 的 DAX 開發套件 (與 DynamoDB API 相容)、重新建立您的應用程式以使用 DAX 用戶端而非 DynamoDB 用戶端，最後將 DAX 用戶端指向 DAX 叢集端點。您不必在應用程式實行任何額外的快取邏輯，因為 DAX 用戶端會實作與 DynamoDB 相同的 API 呼叫。

問：「與 DynamoDB 相容」代表什麼意思？

它表示您目前在 DynamoDB 使用的大部分程式碼、應用程式和工具只需進行少量變更或不需變更，即可與 DAX 搭配使用。DAX 引擎是專為支援 DynamoDB API 所設計，可讀取與修改 DynamoDB 中的資料。CreateTable/DescribeTable/UpdateTable/DeleteTable 這類表格管理操作則不支援。

問：什麼是記憶體內快取，而它對應用程式有何幫助？

快取是將關鍵資料存放在記憶體中進行低延遲且高輸送量的存取，以提高應用程式效能。例如 DAX，可快取 DynamoDB 操作的結果。當應用程式請求存放在快取中的資料時，DAX 便可立即提供此資料，無須對一般 DynamoDB 表格執行查詢。藉由指定資料的存留時間 (TTL) 值，便可讓資料在 DAX 中過時或從其中移出；或者當所有可用記憶體用盡時，便會根據最近最少使用 (LRU) 演算法將項目移出。

問：DAX 的一致性模式是什麼？

使用者從 DAX 讀取資料時，可以指定最終一致讀取或是嚴格一致讀取：

最終一致讀取 (預設) – 最終一致性選項可以最大程度提高讀取輸送量和最低的延遲。當快取命中時，DAX 用戶端會直接從快取傳回結果。當快取未命中時，DAX 將會查詢 DynamoDB、更新快取，然後傳回結果集。應注意的是，最終一致讀取可能不會反映最近完成的寫入結果。如果您的應用程式需要完全一致性，建議您使用嚴格一致讀取。

嚴格一致讀取 – 除了提供最終一致性外，如果您的應用程式或應用程式的某個元素需要，DAX 還提供您請求嚴格一致讀取的彈性和控制能力。嚴格一致讀取對 DAX 而言是直接傳送，不會在 DAX 中快取結果，傳回的結果將會反映讀取之前在 DynamoDB 中收到成功回應的所有寫入。

問：DAX 的常用案例有哪些？

DAX 有許多使用案例，彼此之間不會互相排斥：

需要盡可能快速的讀取回應時間的應用程式。部份範例包括即時競價、社群遊戲以及交易應用程式。DAX 可為這些使用案例提供快速的記憶體內讀取效能。

頻繁讀取少量項目的應用程式。例如，某個電子商務系統正在為某項熱門產品舉行一日特賣。在特賣期間，該產品的需求 (和 DynamoDB 中的資料) 和其他產品相比會大幅增加。若要減輕熱門關鍵字和不均勻資料分佈的影響，您可以將讀取活動卸載至 DAX 快取，直到一日特賣結束。

讀取密集且對成本敏感的應用程式。使用 DynamoDB，您可以佈建應用程式所需的每秒讀取數目。讀取活動增加時，您可以增加表格佈建的讀取傳輸量 (需要額外成本)。或者，您也可以將應用程式的活動卸載至 DAX 叢集，減少需要購買的讀取容量單位數目。

需要對大型資料進行重複讀取的應用程式。例如某應用程式可能會從其他應用程式轉移資料庫資源。例如，長時間執行的區域氣象資料分析可能會暫時耗用 DynamoDB 表格中的所有讀取容量，對需要存取相同資料的其他應用程式造成負面影響。使用 DAX，便可改為對快取的資料執行氣象分析。

運作方式

問：DAX 可替我管理哪些項目？

DAX 是 DynamoDB 專用的全受管快取。可管理設定專用快取節點的相關工作，從佈建伺服器資源到安裝 DAX 軟體。DAX 快取叢集設置完畢並開始執行後，該服務會自動處理常見的管理工作，如故障偵測和恢復及軟體修補程式等。DAX 提供與叢集相關的詳細 CloudWatch 監控指標，讓您能夠對問題進行快速診斷和反應。使用這些指標，您便可以設定接收 CloudWatch 警示的閾值。DAX 可處理所有資料快取、擷取及移出，所以您的應用程式不必執行這些工作。只要使用 DynamoDB API 寫入和擷取資料，DAX 便可以在幕後處理所有快取邏輯，提供改進的效能。

問：DAX 可快取哪些種類的資料？

DAX 可快取所有讀取 API 呼叫，嚴格一致請求會從 DynamoDB 直接讀取，而最終一致讀取則會在項目可用時從 DAX 讀取。寫入 API 呼叫是使用直接寫入的方式 (同步寫入 DynamoDB，成功寫入後會在快取進行更新)。

下列 API 呼叫將會檢查快取。命中時，將會傳回項目。未命中時，將會直接傳送請求，並在成功擷取時快取並傳回項目。

• GetItem
• BatchGetItem
• Query
• Scan

下列 API 呼叫為直接寫入操作。

• BatchWriteItem
• UpdateItem
• DeleteItem
• PutItem

問：DAX 如何處理資料移出？

DAX 使用三種方式來處理快取移出。第一，使用存留時間 (TTL) 值代表項目可在快取中使用的絕對期間。第二，當快取已滿時，DAX 叢集會使用最近最少使用 (LRU) 演算法決定要移出的項目。第三，使用直接寫入功能，DAX 會將較舊的值移出並將新值直接寫入 DAX。這有助於使用單一 API 呼叫使 DAX 項目快取與基礎資料存放區保持一致。

問：DAX 是否可搭配 DynamoDB GSI 和 LSI 運作？

如同 DynamoDB 表格，DAX 會對 DynamoDB GSI 和 LSI 查詢和掃描操作的結果集進行快取。

問：DAX 如何處理查詢和掃描結果集？

在 DAX 叢集內，有兩種不同的快取：1) 項目快取和 2) 查詢快取。項目快取可管理個別鍵值組的 GetItem、PutItem 和 DeleteItem 請求。查詢快取可管理來自掃描和查詢請求的結果集。在這種情況下，掃描/查詢文字為「鍵」而結果集為「值」。雖然項目快取和查詢快取都在相同的叢集中管理 (您可以為每個快取指定不同的 TTL 值)，兩者不會重疊。例如，表格的掃描不會填入項目快取，而是在存放掃描結果集的查詢快取中記錄一個項目。

問：更新項目快取是否會更新查詢快取中的結果集，或是使其無效？

否。消除項目快取和查詢快取之間不一致的最佳方式是，將查詢快取的 TTL 設為可接受的期間，以便讓您的應用程式能夠處理這類不一致。

問：是否可從 VPC 外部連線至我的 DAX 叢集？

從 VPC 外部連線到 DAX 叢集的唯一方式是透過 VPN 連接。

問：使用 DAX 時，如果我的基礎 DynamoDB 表格受到調節會發生什麼事？

DAX 讀取或寫入 DynamoDB 表格時若發生調節例外狀況，DAX 會將此例外狀況傳回 DAX 用戶端。之後，DAX 服務便不會嘗試在伺服器端重試。

問：DAX 是否支援快取預熱？

DAX 利用延遲載入來填入快取。這表示 DAX 會在第一次讀取某項目時，從 DynamoDB 擷取該項目，然後再填入快取。雖然 DAX 不支援快取預熱功能，不過 DAX 快取可以藉由執行讀取所需資料的外部指令碼/應用程式來進行預熱。

問：DAX 如何搭配 DynamoDB TTL 功能運作？

DynamoDB 和 DAX 都具備 "TTL" (或存留時間) 功能的概念。在 DynamoDB 相關環境中，TTL 功能可讓客戶藉由特定屬性和相對應的時戳來標記資料，以便使資料過時。例如，如果客戶想要將資料在一個月之後刪除，便可以使用 DynamoDB TTL 功能來完成此任務，而不須自行管理時效工作流程。

在 DAX 相關環境中，TTL 可指定項目在快取中有效的持續時間。例如，如果 TTL 設為 5 分鐘，則項目便會在填入快取之後持續有效並從快取提供服務，直至 5 分鐘之後為止。雖然不是這個問題的重點，但是可以藉由將相同的項目寫入快取來搶佔 TTL，或是 DAX 節點有記憶體方面的壓力時，LRU 可將最近最少使用的項目移出。

雖然 DynamoDB 和 DAX 的 TTL 通常會以相當不同的時間規模來運作 (例如 DAX TTL 會以分鐘/小時的範圍來運作，而 DynamoDB TTL 會以週/月/年的範圍來運作)，客戶還是有可能需要了解這兩個功能會如何互相影響。例如，假設 DynamoDB 的 TTL 值小於 DAX 的 TTL 值。在此情況下，可想而知項目會快取到 DAX，之後會透過 DynamoDB TTL 功能從 DynamoDB 刪除。結果將會是不一致的快取。雖然我們不預期這樣的情況會經常發生，因為兩個功能的時間規模通常有相當大的差異，不過這可以讓我們更了解兩個功能相互之間的關係。

問：DAX 是否支援跨區域複寫？

目前 DAX 僅支援相同 AWS 區域的 DynamoDB 表格做為 DAX 叢集。

問：AWS CloudFormation 是否支援使用 DAX 做為資源類型？

是。您可以使用 AWS CloudFormation 建立、更新和刪除 DAX 叢集、參數群組及子網路群組。

入門

問：如何開始使用 DAX？
您可以透過 AWS 主控台或 AWS 開發套件建立新的 DAX 叢集，以取得 DAX 叢集端點。並且需要下載 DAX 相容用戶端，並在應用程式中搭配新的 DAX 端點使用。

問：如何建立 DAX 叢集？

您可以使用 AWS 管理主控台或 DAX CLI 建立 DAX 叢集。R3 執行個體類型的 DAX 叢集範圍從 13 GiB 快取 (dax.r3.large) 到 216 GiB (dax.r3.8xlarge)、R4 執行個體類型從 15.25 GiB 快取 (dax.r4.large) 到 488 GiB(dax.r4.16xlarge)，至於較小的 T2 執行個體類型則從 2 GiB (dax.t2.small) 到 4 GiB (data.t2.medium)。只需要在主控台中按幾下，或是使用單一 API 呼叫，您便可以將最多 10 個複本新增至叢集，以提高輸送量。

單一節點組態讓您能夠以經濟實惠的方式快速開始使用 DAX，之後隨著需求增長再擴展成多節點組態。多節點組態由一個管理寫入的主要節點和最多九個僅供讀取複本節點組成，且會為您自動佈建主要節點。

指定您偏好的子網路群組和可用區域 (選用)、節點數目、節點類型、VPC 子網路群組，以及其他系統設定值即可。選擇您想要的組態之後，DAX 將會佈建所需的資源並設定 DynamoDB 專用的快取叢集。

問：記憶體是否需要能夠容納所有資料才能使用 DAX？

否。DAX 將會運用節點上的可用記憶體。當記憶體空間用盡時，將會使用 TTL 和/或 LRU 抹除項目，以便為新的資料挪出空間。

問：DAX 支援哪些語言？

DAX 提供適用於 Java、Node.js、Python 和 .NET 的 DAX SDK 供您下載。我們正在積極努力增加其他用戶端 SDK 的支援。

問：是否可同時使用 DAX 和 DynamoDB？

是。您可以同時透過不同用戶端來存取 DAX 端點和 DynamoDB。但是，DAX 無法偵測直接寫入 DynamoDB 的資料變更，除非對 DynamoDB 進行直接更新之後，將這些變更透過讀取操作明確地填入 DAX。

問：是否可以在相同 DynamoDB 表格使用多個 DAX 叢集嗎？

是。您可以為相同的 DynamoDB 表格佈建多個 DAX 叢集。這些叢集將會提供可用於不同使用案例的不同端點，確保每種情況都有最佳的快取。兩個 DAX 叢集會互相獨立運作，不會共享狀態或更新，所以可以用於完全不同的表格來為使用者提供最佳服務。

問：如何知道工作負載所需的 DAX 節點類型？

調整 DAX 叢集大小是一種重複性的程序。建議您佈建一個三節點叢集 (以取得高可用性)，而且要有足夠的記憶體讓應用程式在記憶體中運作。根據應用程式的效能和輸送量、DAX 叢集的使用率以及快取命中/未命中率，您可能需要擴展 DAX 叢集以達到想要的結果。

問：DAX 可在哪些類型的 Amazon EC2 執行個體執行？

如需了解 DAX 支援的最新執行個體類型，請參閱 Amazon DynamoDB 定價頁面。

問：DAX 是否支援預留執行個體或 AWS 免費用量方案？

目前 DAX 僅支援隨需執行個體。

問：DAX 如何計費？

DAX 的計費方式按消耗的節點小時數計算，從節點啟動時開始，直至節點終止為止。執行未滿一小時的節點，將按一小時計費。定價會套用到 DAX 叢集中的所有個別節點。例如，如果您有一個三節點的 DAX 叢集，您需要依小時費率分別支付每個節點的費用 (總共三個節點)。

可用性

問：如何使用 DAX 叢集來達到高可用性？

DAX 提供內建異地同步備份支援，可讓您為 DAX 叢集中的節點選擇偏好的可用區域。DAX 使用非同步複寫來提供節點之間的一致性，因此即使發生故障，也會有其他節點處理請求。若要使 DAX 叢集達到高可用性，無論是計劃性或非計劃性中斷，都建議您在 3 個不同的可用區域部署至少 3 個節點。每個 AZ 在各自實體不同的獨立基礎設施中執行，並已設計成具備高可靠性。

問：DAX 節點故障時會發生什麼事？

如果主要節點故障，DAX 將自動偵測該故障，選取其中一個可用的僅供讀取複本，並將其提升為新的主要節點。此外，DAX 會在與故障主要節點相同的可用區域佈建一個新節點；這個新節點會取代剛升級的僅供讀取複本。如果主要節點因為暫時性的可用區域中斷而故障，則會在 AZ 復原時立刻啟動新複本。如果單一節點叢集故障，DAX 會在相同的可用區域啟動新的節點。

可擴展性

問：DAX 支援哪種類型的擴展？

DAX 目前支援兩種擴展選項。第一個選項是讀取擴展，藉由在叢集新增僅供讀取複本以取得額外的輸送量。單一 DAX 叢集支援最多 10 個節點，每秒可服務數百萬筆請求。新增或移除額外複本都是線上操作。第二個擴展叢集的方式是藉由選取較大或較小的 r3 執行個體類型來進行擴展或縮減。較大的節點可讓叢集在記憶體中存放較多的應用程式資料集，進而降低快取未命中率並改進應用程式整體效能。建立 DAX 叢集時，叢集的所有節點都必須是相同的執行個體類型。此外，若您想要變更 DAX 叢集的執行個體類型 (例如從 r3.large 擴展為 r3.2xlarge)，則必須使用所需的執行個體類型來建立新的 DAX 叢集。DAX 目前不支援線上擴展或縮減操作。

問：如何擴展應用程式的寫入能力？

在 DAX 叢集中，只有主要節點會處理對 DynamoDB 的寫入操作。因此，在 DAX 叢集加入更多節點可增加讀取輸送量，但是不會增加寫入輸送量。若要增加應用程式的寫入輸送量，您需要擴展至較大的執行個體大小或是佈建多個 DAX 叢集，並在應用程式層將鍵值空間進行碎片處理。

監控

問：如何監控 DAX 叢集的效能？
您可以透過 AWS 管理主控台或 Amazon CloudWatch API 取得 DAX 叢集的 CPU 使用率、快取命中/未命中數及讀寫流量等指標。您也可透過 Amazon CloudWatch 的自訂指標功能，新增更多使用者定義的指標。除了 CloudWatch 指標之外，DAX 還可透過 AWS 管理主控台提供關於快取命中、未命中、查詢及叢集效能等資訊。

維護

問：什麼是維護時段？軟體維護期間是否可使用 DAX 叢集？

您可以將 DAX 維護時段視為控制叢集修改時間的機會，例如進行軟體修補的時間。如果在指定的星期排定「維護」事件，則將在您指定的維護時段期間的某個時間點啟動和完成維護。

只會針對與安全性和可靠性相關的修補程式自動排定必要的修補。這種修補並非頻繁發生 (通常幾個月才進行一次)。如果您建立叢集時未指定偏好的每週維護時段，則會指派預設值。如果您希望在代您執行維護時進行修改，則可在 AWS 管理主控台或使用 UpdateCluster API 修改叢集來執行此操作。每個叢集都可以有不同的偏好維護時段。

對於多節點叢集，叢集內的更新會以序列方式執行，一次更新一個節點。節點更新之後，將會與叢集其中一個對等節點同步，以使該節點具備最新的工作資料集。對於單一節點叢集，我們將會佈建一個複本 (免費)，以最新的資料同步此複本，然後執行容錯移轉使新複本成為主要節點。使用這種方式，您便不會在單一節點叢集升級期間遺失任何資料。 

問：什麼是 DynamoDB 全域表？

DynamoDB 全域表是 DynamoDB 新增的多主機、跨區域複寫功能，可支援資料庫工作負載的資料存取位置和區域容錯能力。應用程式現在可以在世界各地的 AWS 區域執行 DynamoDB 的讀取和寫入操作，並將任一區域中異動的資料傳播到每個複寫表格的區域。

問：為什麼應該使用全域表？

全域表可讓您建立採用資料位置的應用程式以降低整體延遲。您的應用程式可以在離最終使用者最近的區域讀取/寫入資料，進而提高應用程式的整體回應速度。另外，Global Tables 可讓您的應用程式維持高度可用性，即使是發生整個區域隔離或降級等特殊情況亦同。

問：哪些 AWS 區域支援全域表？

目前有五個區域支援全域表：美國東部 (俄亥俄)、美國東部 (維吉尼亞北部)、美國西部 (奧勒岡)、歐洲 (愛爾蘭) 及歐洲 (法蘭克福)。

問：我可以複寫到多少個 AWS 區域？

每個區域可以有一個複本表格，而且只要在支援全域表的區域都能使用，不限數量。

問：全域表提供什麼樣的一致性保證？

全域表可確保最終一致性，這意味著在任一複本表格更新任何項目之後，這些更新都會複寫到同一個全域表中的所有其他複本。如果對同一項目進行多次更新，則全域表中的所有複本都將同意最後所做的更新，因此所有複本將不斷地彙整以達到存放相同資料的狀態。

問：存取複本表格時可預期什麼樣的延遲？

如果託管應用程式的區域含有全域表，則透過其區域端點存取本機複本表格時，可預期與 DynamoDB 相同的低於 10 毫秒延遲。

問：全域表的定價為何？

請參閱定價頁面以取得詳細資訊。

問：Dynamo DB 免費方案是否包含全域表？

是。您可以建立一個內含複本表格的全域表，只要複寫的 AWS 區域不超過兩個，則兩者皆符合免費方案的資格。

問：DynamoDB 全域表是否支援跨帳戶存取 (即從一個 AWS 帳戶將資料複寫到另一個)？

答：否。全域表目前可在單一 AWS 帳戶跨區域複寫資料。

問：DynamoDB 支援的表格備份選項為何？

您可以為 Amazon DynamoDB 表啟用 point-in-time 恢復 (PITR) 及建立隨需備份。

PITR 可以為 DynamoDB 表格資料提供持續備份。在 AWS 管理主控台按一下或透過單一 API 呼叫，就能啟用 PITR。啟用時，DynamoDB 會維護表格的持續備份，最早是 35 天前。您可以將該表格的副本恢復到 PITR 啟用後的任何時間點的狀態，最早是 35 天前。PITR 會提供持續備份，直到明確將它停用為止。

隨需備份允許您建立 DynamoDB 表格資料及各項設定的備份。只要在 AWS 管理主控台按一下或使用單一 API 呼叫，就能隨時啟動隨需備份。您隨時可以將備份恢復到同一 AWS 區域的新 DynamoDB 表。

對於 PITR 和隨需備份，DynamoDB 會自動加密備份、建立備份型錄和存放備份。

問：為什麼要使用 PITR 和隨需備份？

Amazon DynamoDB 為您的資料保護和存檔提供兩種互補選項。

PITR 可為 DynamoDB 表提供持續保護，以防止意外寫入和刪除。使用 PITR，不需為建立、維護或排程備份操心。在表格上啟用 PITR，您的備份就能恢復到啟用後的任何時間點，最早是 35 天前。例如，如果有測試指令碼意外寫入生產環境 DynamoDB 表，您可以將表格恢復到過去 35 天內的任何時間點。

隨需備份有助於滿足長期存檔需求，以遵守相關法規。隨需備份可讓您全面掌控對備份生命週期的管理，並根據實際需要建立無限個備份及無限期的保留。

問：如何啟用或停用 PITR？

您可以使用 Amazon DynamoDB 主控台、AWS CLI 或任一 AWS SDK 啟用或停用 PITR。

問：如何啟動隨需備份？

您可以從 DynamoDB 主控台、AWS CLI 或任一 AWS SDK 啟動隨需備份。透過 DynamoDB 表的備份標籤，即可存取所有隨需備份動作 – 建立、恢復和刪除。您也可以從主控台的導覽窗格，瀏覽自己帳戶中的隨需備份完整清單。如需隨需備份和恢復 API 的詳細資訊，請參閱 DynamoDB API 參考文件。

問：隨需備份和 PITR 備份會保留多久？

DynamoDB 會一直保留隨需備份，直到您將它們刪除為止。PITR 會保留過去 35 天的備份。

問：刪除來源表格後，我的備份會發生什麼事？

刪除來源表格之後，仍然可以存取隨需備份。當您刪除啟用 PITR 的表格後，系統會停止追蹤變更。如果您需要恢復已刪除的表格，必須在 35 天的恢復時間內聯絡 AWS Support，以從 PITR 備份恢復該表格。

問：備份是否會消耗來源表格佈建的讀取或寫入容量？

否。DynamoDB 會在這個服務內執行備份和恢復操作，不會消耗來源表格佈建的任何讀取或寫入容量。

問：備份是否會影響表格效能？

否。

問：備份存放在哪裡？

備份使用 DynamoDB 高耐用性的受管儲存體存放，可提供簡易、高效能和操作簡便的體驗。

問：DynamoDB 使用 PITR 恢復哪些項目？

當您恢復由 PITR 建立的備份時，DynamoDB 會在新表格中將您的表格資料恢復成所選日期和時間 (day:hour:minute:second) 的狀態。該新表格的設定來自來源表格目前的設定，並且包含本機次要索引、全域次要索引、加密及讀取容量單位和寫入容量單位設定。

問：是否可使用 PITR 在不同的帳戶或 AWS 區域中恢復表格？

否。您只能將表格恢復到與來源表格相同的 AWS 區域和帳戶。

問：表格恢復是否可覆寫現有表格？

否。當您從備份恢復表格時，此程序一律會寫入新表格。

問：哪些 AWS 區域支援隨需備份和 PITR？

請參閱定價詳情以了解最新的區域可用性和定價。

問：DynamoDB 使用隨需備份和 PITR 保留哪些項目？

隨需備份會連同資料一併保留表格的讀取容量單位、寫入容量單位、本機次要索引、全域次要索引、串流及加密設定。隨需備份不會保留 Auto Scaling 政策、PITR 設定、存留時間 (TTL)、標籤及 CloudWatch 指標和警示。

PITR 會備份表格的內容，在恢復時會使用該表格目前的設定。

問：DynamoDB 從隨需備份恢復哪些項目？

恢復時，目標表格設定的佈建讀取容量單位和寫入容量單位與來源表格相同，與請求備份時所記錄的容量單位相同。恢復程序會恢復本機次要索引和全域次要索引，但不會恢復串流和 TTL 資料。

問：如果停用 PITR 後又重新啟用會發生什麼事？

如果您在表格上停用 PITR 後又重新啟用，將會重設可以恢復該表格的開始時間。例如，停用 PITR 後，會移除恢復快照與日誌。因此，您無法恢復該表格。如果之後再次為該表格啟用 PITR，DynamoDB 會建立新的快照和日誌序列。

問：備份和恢復操作需要多長時間才能完成？

DynamoDB 可以在幾秒內處理備份請求，這些備份可以立即用於恢復。恢復表格所需的時間會根據多種因素而有所不同，恢復時間不一定與表格大小有直接關聯。例如，由於並行處理的緣故，恢復 300 GB 的表格所需時間可能與恢復 3 GB 的表格相同。以下是關於恢復時間的一些考量：

1. 備份是恢復到新表格。執行建立新表格和啟動恢復程序的所有動作，最多可能需要 20 分鐘的時間 (即使表格是空的)。

2. 對於資料跨主索引鍵平均分佈的表格，恢復時間會與項目數最大的單一分區成比例，而非整體表格大小。對於含有數十億筆項目的最大分區，恢復所需的時間可能在 10 小時內。

3. 如果來源表格包含明顯偏斜的資料，恢復所需的時間可能會增加。例如，如果表格的主索引鍵是以月份分割，而您的資料全部來自十二月，您的資料就是偏斜資料。

問：可建立的隨需備份數量是否有限制？

否。您可以為表格建立的隨需備份數量沒有限制，可在 AWS 帳戶中保留的備份數量也沒有限制。

問：使用隨需備份與 PITR 的成本為何？

請參閱定價詳情，進一步了解隨需備份和 PITR 的定價。

問：是否可使用隨需備份或 PITR 來備份 DynamoDB 表，並在其他 AWS 帳戶恢復？

否。就目前而言，您必須從備份將表格恢復到與執行備份所在的相同 AWS 區域和 AWS 帳戶。

問：是否可備份 DynamoDB 全域表？

您可以在全域表的每個本機複本上建立隨需備份或啟用 PITR。當您從備份恢復時，它會建立不屬於全域表的新獨立表格。

問：是否可備份加密表格？

是。您可以在加密表格上建立隨需備份或啟用 PITR。

問：隨需備份與使用 AWS Data Pipeline 的匯入和匯出有何不同？

AWS Data Pipeline 匯入和匯出功能使用表格佈建的讀取和寫入輸送容量，而且會影響表格效能，因為 DynamoDB 表格資料是使用完整表格掃描移動的。另一方面，隨需備份不會消耗任何輸送容量，也不會影響表格效能和可用性。DynamoDB 主控台 Actions 功能表中的 Import 和 Export 選項已被移除，但仍可從 AWS Data Pipeline 主控台存取。

問：什麼是 DynamoDB 靜態加密？

DynamoDB 靜態加密可以讓您為 DynamoDB 表中保存的資料 (靜態資料) 進行加密。這包括基本表格、本機次要索引和全域次要索引。靜態加密會自動與 AWS Key Management Service (KMS) 整合，以便管理表格加密時使用的金鑰。

問：為什麼需要使用靜態加密？

靜態加密是一種受管伺服器端加密功能，使用存放在 AWS 帳戶中的 AWS KMS 金鑰。將資料傳送到 DynamoDB 之前的加密和擷取資料之後進行解密，都不必實作和維護額外的程式碼。一旦為 DynamoDB 表啟用靜態加密功能，您的應用程式將能無縫地運作而無須進行任何其他變更。

問：如何加密表格？

您可以使用主控台、AWS CLI 或 API，為新的 DynamoDB 表啟用靜態加密。目前，您無法為現有的 DynamoDB 表啟用靜態加密。

問：我的全域次要索引 (GSI) 和本機次要索引 (LSI) 是否會使用靜態加密功能加密？

是的，為已加密表格關聯的全域次要索引 (GSI) 和本機次要索引 (LSI) 進行加密時，預設使用的金鑰與加密表格時使用的金鑰相同。

問：使用 DynamoDB 靜態加密會有什麼額外的費用？

使用 DynamoDB 靜態加密時，沒有額外的 DynamoDB 費用。但是，使用服務預設金鑰時會另行收取 KMS 費用。這些費用可以在 AWS KMS 定價頁面上看到。

問：是否可以加密 DynamoDB 串流？

目前，您無法為 DynamoDB Streams 啟用靜態加密。如果合規/法規要求靜態加密，建議關閉加密表格的 DynamoDB Streams。

問：DynamoDB 隨需備份是否也會加密？

是的，DynamoDB 加密表格的隨需備份會加密 (使用 S3 的伺服器端加密)。目前，這些備份使用服務預設金鑰和服務受管金鑰進行部分加密。我們正努力使用客戶擁有的 KMS 金鑰來加密隨需備份所有相關的資料。

問：靜態加密如何加密我的資料？

DynamoDB 使用信封加密來加密您的資料，在該資料中使用階層式加密金鑰來加密資料庫。您可以使用 AWS KMS 管理此階層中的最上層加密金鑰。資料加密後，Amazon DynamoDB 可以透明的方式處理您的資料解密，同時對效能影響最小。您不需要修改資料庫用戶端應用程式即可使用加密。

問：如何管理用於靜態加密的金鑰？

DynamoDB 與 AWS KMS 整合在一起，方便管理表格加密時使用的金鑰。DynamoDB 靜態加密使用存放在 KMS 帳戶中的服務預設金鑰 (DynamoDB 特有)。如果建立 DynamoDB 加密表格時，服務預設金鑰不存在，則 KMS 將自動為您建立新的金鑰，以後建立的加密表格就會用到這個金鑰。如需詳細資訊，請參閱 AWS Key Management Service Developer Guide。

問：我可以選擇哪些加密金鑰來加密我的 DynamoDB 表？

目前，您只能使用 DynamoDB 表的服務預設金鑰。如果這個金鑰不存在，系統會建立一個金鑰。 

問：在靜態加密中，AWS Key Management Service (KMS) 中的服務預設金鑰有什麼作用？

沒有存取 KMS 服務預設金鑰，DynamoDB 將無法讀取您的表格資料。DynamoDB 使用信封加密和金鑰階層來加密資料。您的 KMS 加密金鑰是用來加密此金鑰階層的根金鑰。如需詳細資訊，請參閱信封加密如何與支援的 AWS 服務協同工作。

問：是否可以為不同表格使用不同的服務預設金鑰？

不可以，DynamoDB 使用單一服務預設金鑰來加密所有的 DynamoDB 表。

問：是否可以只加密表格中的部分項目？

否。靜態加密只適用於表格級的精細度。

問：如何檢查我的表格是否啟用了靜態加密？

您可以在主控台從 "Overview" 標籤的 "Table details" 部分得知加密狀態。您也可以使用 DescribeTable 命令了解表格的加密狀態。 

問：啟用表格的靜態加密後是否可停用？

不可以，您無法停用加密表格的靜態加密。

問：靜態加密與 DynamoDB 用戶端加密庫有何不同？

用戶端加密庫 – 適用於 Java 的 Amazon DynamoDB 加密用戶端 – 在用戶端 (在使用 AWS SDK 的應用程式中) 對資料進行加密和解密。加密金鑰常駐在用戶端。由於 DynamoDB 無法存取您的加密金鑰，因此 DynamoDB 無法存取您解密的資料。伺服器端靜態加密功能會在將資料存放到 DynamoDB 表之前加密您的資料。DynamoDB 會利用您指定的 KMS 加密金鑰在伺服器端進行資料的加密和解密。您仍然可以對加密的資料使用完整的查詢功能。

問：透過網路傳輸資料時，靜態加密是否會保護我的資料？

否。只有持久性儲存媒體上的資料是靜態 (靜止) 時，靜態加密才會加密資料。您必須加密用戶端上的敏感資料或使用加密連接 (TLS)，確保當資料透過公有或私有網路主動移動 (傳輸中的資料) 時，一定會受到保護。

問：靜態加密使用什麼加密演算法？

靜態加密使用 256 位元 AES 加密來加密您的資料。

問：靜態加密如何與 DynamoDB 全域表搭配使用？

您可以在全域表複本上啟用靜態加密。請注意，全域表使用 DynamoDB Streams，它尚不支援靜態加密。因此，DynamoDB Streams 上複寫的資料不會被靜態加密。

問：什麼是 Amazon DynamoDB 的 VPC 端點？

Amazon Virtual Private Cloud (VPC) 是一項 AWS 服務，透過在 AWS 雲端佈建邏輯隔離的部分，將虛擬私有雲端提供給使用者。Amazon DynamoDB 的 VPC 端點是 VPC 中的邏輯實體，可在 VPC 和 DynamoDB 之間建立私有連線，而無須透過網際網路、通過網路位址轉譯 (NAT) 裝置或 VPN 連接進行存取。如需 VPC 端點的詳細資訊，請參閱 VPC 端點。

問：為什麼要使用 DynamoDB 的 VPC 端點？

在過去，從 VPC 內存取 Amazon DynamoDB 的主要方式是周遊網際網路，這種方式可能需要防火牆和 VPN 這類複雜的組態。DynamoDB 的 VPC 端點從 VPC 內以私有連線存取 DynamoDB，不需使用網際網路閘道或 NAT 閘道，以此方式為客戶提升隱私權和安全性，特別是處理有合規和稽核需求等敏感工作負載的客戶。另外，DynamoDB 的 VPC 端點支援 AWS Identity and Access Management (IAM) 政策，以簡化 DynamoDB 存取控制。您現在可以輕鬆地將 DynamoDB 表的存取限制為特定的 VPC 端點。

問：如何開始使用 DynamoDB 的 VPC 端點？

您可以使用 AWS 管理主控台、AWS 開發套件或 AWS 命令列界面 (CLI) 建立 Amazon DynamoDB 的 VPC 端點。您必須指定 VPC 及 VPC 中的現有路由表，並描述要連接到端點的 IAM 政策。路由會自動新增到每個指定的 VPC 路由表。

問：DynamoDB 的 VPC 端點是否可確保流量不會路由到 Amazon 網路外部？

是，使用 Amazon DynamoDB 的 VPC 端點時，DynamoDB 和 VPC 之間的資料封包會留在 Amazon 網路中。

問：是否可使用 DynamoDB 的 VPC 端點連接與 VPC 位於不同 AWS 區域的 DynamoDB 表？

否，只能為與 VPC 位於相同 AWS 區域的 Amazon DynamoDB 表建立 VPC 端點。

問：DynamoDB 的 VPC 端點是否會限制傳到 DynamoDB 的輸送量？

否，您可以使用 VPC 內的公有 IP 持續從執行個體傳送與現在相同的輸送量到 Amazon DynamoDB。

問：使用 DynamoDB 的 VPC 端點定價為何？

使用 Amazon DynamoDB 的 VPC 端點無須額外付費。

問：是否可使用 DynamoDB 的 VPC 端點存取 DynamoDB Streams？

目前，您無法使用 Amazon DynamoDB 的 VPC 端點存取 Amazon DynamoDB Streams。

問：我目前使用網際網路閘道和 NAT 閘道將請求傳送到 DynamoDB。使用 VPC 端點時是否需要變更應用程式程式碼？

不需要變更您的應用程式程式碼。只要建立 VPC 端點、更新路由表以指向 DynamoDB VPC 端點的 Amazon DynamoDB 流量，然後直接存取 DynamoDB 即可。您可以持續使用相同的程式碼和相同的 DNS 名稱存取 DynamoDB。

問：是否可在 DynamoDB 和其他 AWS 服務使用一個 VPC 端點？

不可以，每個 VPC 端點只支援一個服務。您可以為 Amazon DynamoDB 和其他 AWS 服務分別建立，然後在一個路由表使用它們。 

問：一個 VPC 是否可有多個 VPC 端點？

是，一個 VPC 可有多個 VPC 端點。例如，您可以為 Amazon S3 提供一個 VPC 端點，為 Amazon DynamoDB 提供另一個 VPC 端點。

問：單一 VPC 是否可有多個 DynamoDB VPC 端點？

是，單一 VPC 中可有多個 Amazon DynamoDB VPC 端點。個別的 VPC 端點可以有不同的 VPC 端點政策。例如，一個 VPC 端點僅供讀取，另一個則可用於讀取/寫入。不過，由於路由表會透過指定的 VPC 端點將所有流量路由到 DynamoDB，因此 VPC 中的單一路由表只能與單一 DynamoDB VPC 端點關聯。

問：S3 的 VCP 端點和 DynamoDB 的 VPC 端點有什麼差別？

主要差別在於這兩個 VPC 端點支援不同的服務 – Amazon S3 和 Amazon DynamoDB。

問：對於從 DynamoDB VPC 端點傳入的流量，AWS CloudTrail 日誌會顯示哪個 IP 地址？

Amazon DynamoDB 的 AWS CloudTrail 日誌包含 VPC 中 Amazon EC2 執行個體的私有 IP 地址和 VPC 端點識別符 (例如，ourceIpAddress=10.89.76.54、VpcEndpointId=vpce-12345678)。

問：如何使用 AWS 命令列界面 (CLI) 管理 VPC 端點？

您可以使用以下 CLI 命令管理 VPC 端點：create-vpc-endpoint、modify-vpc-endpoint、describe-vpc-endpoint、delete-vpc-endpoint 和 describe-vpc-endpoint-services。您應該指定 VPC 和 DynamoDB 區域特定的 Amazon DynamoDB 服務名稱 (例如，com.amazon.us.east-1.DynamoDB)。如需詳細資訊，請參閱 create-vpc-endpoint。

問：DynamoDB 的 VPC 端點是否需要客戶了解和管理 DynamoDB 的公有 IP 地址範圍？

否，客戶不需要知道或管理 Amazon DynamoDB 的公有 IP 地址範圍就能使用此功能。我們將會提供一個前綴清單讓您在路由表和安全群組使用。AWS 會保留清單中的地址範圍。前綴清單名稱是：com.amazonaws. .DynamoDB (例如，com.amazonaws.us-east-1.DynamoDB)。

問：是否可在 DynamoDB 的 VPC 端點上使用 AWS IAM 政策？

是。您可以將 AWS IAM 政策連接到 VPC 端點，且這個政策會套用到經過此端點的所有流量。例如，使用此政策的 VPC 端點只允許 describe* API 呼叫：
{
    "Statement":  [
       {
            "Sid": "Stmt1415116195105",
            "Action": "dynamodb:describe*",
            "Effect":"Allow",
            "Resource": "arn:aws:dynamodb:region:account-id:table/table-name",
            "Principal": "*"
        }
    ]
}

問：是否可限制從 VPC 端點存取我的 DynamoDB 表？

是，您可以建立 AWS IAM 政策，限制 DynamoDB 表特定 VPC 端點的 IAM 使用者、群組或角色。

將 IAM 政策的 Resource 元素設定為 DynamoDB 表，並將 Condition 元素的索引鍵設定為 aws:sourceVpce，即可完成這個工作。如需詳細資訊，請參閱 IAM JSON Policy Elements Reference。

例如，除非 sourceVpce 符合 "vpce-111bbb22"，否則以下 IAM 政策會限制對 DynamoDB 表的存取

{
    "Statement":  [
       {
            "Sid": "Stmt1415116195105",
            "Action": "dynamodb:*",
            "Effect":"Deny",
            "Resource": "arn:aws:dynamodb:region:account-id:*",
            "Condition": { "StringNotEquals" : { "aws:sourceVpce": "vpce-111bbb22" } }
        }
    ]
}

問：DynamoDB 的 VPC 端點是否支援精細存取控制權的 IAM 政策條件？

是。DynamoDB 的 VPC 端點支援所有更精細的存取控制權存取金鑰。您可以使用精細存取控制權的 AWS IAM 政策條件，控制對個別資料項目和屬性的存取。如需更精細的存取控制權詳細資訊，請參閱 Using IAM Policy Conditions for Fine-Grained Access Control。

問：是否可使用 AWS 政策產生器建立 DynamoDB 的 VPC 端點政策？

是，您可以使用 AWS 政策產生器建立 VPC 端點政策。

問：DynamoDB 是否支援與 Amazon S3 儲存貯體政策類似的資源政策？

否，Amazon DynamoDB 不支援個別表格、項目等有關的資源政策。