目錄
從關聯式資料庫轉換到非關聯式資料庫，以下是這兩種資料庫之間的區別：
表 1.關聯式資料庫轉與非關聯式資料庫的比較
| 特色 | 關聯式資料庫 | NoSQL |
|---|---|---|
| 資料儲存方式 | 行與列 | 鍵值對(Key-value)、文件、圖 |
| 資料結構 (Schemas) | 固定 | 動態 |
| 查詢方式 | 以 SQL 為主 | 以文件集合方式 |
| 擴展方式 | 垂直 | 水平 |
DynamoDB 是一項快速而靈活的 NoSQL 資料庫服務，適合所有需要一致性且延遲不超過十毫秒的任意規模的應用程式。Amazon 會為該服務管理所有底層資料基礎設施，作為容錯架構的一部分，資料以冗餘方式儲存在區域內的多個設施中。藉助 DynamoDB，可以建立表和項目，可以向表中添加項目。系統會自動將資料分區，且具有可滿足工作負載要求的表儲存，可以在表中儲存的項目數量沒有任何實際限制。例如，一些客戶的生產表包含數十億個項目。
當應用程式越來越受歡迎且用戶一如既往地與其進行互動時，儲存空間可以隨應用程式需求的擴大而增加。DynamoDB 中的所有資料都儲存在固態硬碟（SSD）上，且其查詢語言非常簡單，可提供一致的低延遲查詢性能。除了擴展儲存，DynamoDB 還支持為自己的表預置所需的讀取或寫入吞吐量。隨著應用程式用戶數量的增加，可以通過手動預置來擴展 DynamoDB 表，以處理增加的讀取/寫入請求數量。或者，可以啓用自動擴展功能，以便 DynamoDB 監控表上的負載並自動增加或減少預置的吞吐量。另外一些關鍵功能還有全局表（可以幫助您跨所選的 AWS 區域自動複寫）、靜態加密以及項目生存時間（TTL）。
NoSQL 資料庫的優勢之一是同一個表中的項目可以具有不同的屬性。這樣一來，便可以隨著應用程式的發展靈活地添加屬性。可以將較新格式的項目與較舊格式的項目並排儲存到一個表中，而無需執行架構遷移。
表、項目和屬性是 DynamoDB 的核心組件。
圖 1. DynamoDB 的核心組件
建立 DynamoDB 資料表時，除了指定資料表名外，還必須指定資料表的主鍵(primary key)。主鍵唯一標識表中的每個項目，因此任何兩個項目都不能具有相同的鍵。
DynamoDB 支持兩種不同類型的主鍵：
一個項目可以具有任意數量的具有不同值類型的屬性，每個屬性都有一個名稱和一個值。屬性值可以是以下類型之一：
項目的大小是其屬性名稱和值的長度總和，一個項目的最大可達 400 KB。
圖 2. DynamoDB 的屬性類型
無伺服器(Serverless)
使用 DynamoDB，您無需預置任何伺服器，也無需修補、管理、安裝、維護或操作任何軟體。 DynamoDB 提供零停機維護。它沒有版本（主要、次要或補丁），並且沒有維護視窗。
DynamoDB 的隨選容量模式為讀取和寫入要求提供隨選付費定價，因此您只需為使用的量付費。透過按需，DynamoDB 可以立即擴大或縮小您的表格以調整容量並以零管理保持效能。它還可以縮小到零，因此當您的表沒有流量且沒有冷啟動時，您無需為吞吐量付費。
NoSQL
作為 NoSQL 資料庫，DynamoDB 旨在提供比傳統關聯式資料庫更高的效能、可擴展性、可管理性和靈活性。為了支援各種用例，DynamoDB 支援鍵值和文件資料模型。
與關聯式資料庫不同，DynamoDB 不支援 JOIN 運算子。我們建議您對資料模型進行非規範化，以減少資料庫往返次數和回答查詢所需的處理能力。作為 NoSQL 資料庫，DynamoDB 提供強大的讀取一致性和ACID 事務 建立企業級應用程式。
完全託管
作為一個完全託管的資料庫服務，DynamoDB 可以處理管理資料庫的無差別繁重工作，以便您可以專注於為客戶創造價值。它處理設定、配置、維護、高可用性、硬體配置、安全性、備份、監控等。這可確保當您建立 DynamoDB 表時，它可以立即為生產工作負載做好準備。 DynamoDB 不斷提高其可用性、可靠性、效能、安全性和功能，無需升級或停機。
任何規模的個位數毫秒性能
DynamoDB 專為提高關聯式資料庫的效能和可擴展性而構建，以在任何規模下提供個位數毫秒的效能。為了實現這種規模和效能，DynamoDB 針對高效能工作負載進行了最佳化，並提供了鼓勵高效資料庫使用的 API。它忽略了大規模時效率低且性能不佳的功能，例如 JOIN 操作。無論您擁有 100 還是 1 億用戶，DynamoDB 都能為您的應用程式提供一致的個位數毫秒效能。
具有交易功能
可以使用 DynamoDB 交易(transactions)透過單一請求跨一個或多個表實現原子性、一致性、隔離性和持久性 (atomicity, consistency, isolation, and durability, ACID)。
許多用例可以透過使用交易來實現，例如：
DynamoDB 與 AWS 服務進行無伺服器整合的一些範例：
預設情況下，DynamoDB 會自動跨三個可用區複製資料提供高耐用性和 99.99% 可用性 SLA。 DynamoDB 還提供其他功能來幫助實現交易連續性和災難復原目標。
DynamoDB 包含以下功能來幫助支援您的資料彈性和備份需求：
全域表
DynamoDB 全域表可達到99.999% 的可用性 SLA和多區域韌性。這可以用來建立韌性應用程式並對其進行最佳化，以實現最低的復原時間目標 (recovery time objective, RTO) 和復原點目標 (recovery point objective, RPO)。全域表也與AWS 故障注入服務 (AWS Fault Injection Service, AWS FIS)整合，以對全域表工作負載執行故障注入實驗。
連續備份和時間點恢復
連續備份為您提供每秒粒度以及啟動時間點復原的能力。透過時間點恢復，可以將表恢復到過去 35 天內的任意時間點（最多可達秒）。連續備份和啟動時間點恢復不使用預配容量。它們也不會對應用程式的效能或可用性產生任何影響。
按需備份和恢復
透過按需備份和恢復，可以建立表格的完整備份，以便長期保留和歸檔，以滿足法規遵循需求。備份不會影響表的效能，並且可以備份任何大小的表。透過整合 AWS Backup ，可以使用自動規劃、複製、標記和管理 DynamoDB 按需備份的生命週期。使用 AWS Backup，可以跨帳戶和區域複製按需備份，並將舊備份轉移到冷儲存以優化成本。
DynamoDB 會自動跨 AWS 區域中的多個可用區保存資料，從而提供內建的高可用性和資料持久性，在寫入操作後的一秒鐘內，所有資料副本通常都是一致的。
DynamoDB 支援最終一致(eventually consistent)和強一致性(strongly consistent)讀取，全域二級索引不支援一致性讀取。
Amazon DynamoDB 支援預置(provisioned)吞吐量和按需(on-demand)吞吐量。預先配置吞吐量是應用程式可以從表或索引消耗的最大容量。如果應用程式超出了資料表或索引上預置的吞吐量容量，則會受到請求限制。
DynamoDB 在分割區之間平均分配吞吐量。每個分區的吞吐量是總預配置吞吐量除以分區數。
透過預先設定吞吐量，可以根據讀取容量單位 (read capacity units, RCU) 和寫入容量單位 (write capacity units, WCU) 指定吞吐量：
選擇 Amazon DynamoDB 按需時，DynamoDB 會根據工作負載擴大或縮小，使用按需模式的表可提供與 DynamoDB 已提供的相同的個位數毫秒延遲、服務等級協定 (SLA) 承諾和安全性。可以為新資料表和現有資料表選擇按需模式，並且可以繼續使用現有的 DynamoDB 應用程式介面 (API)，而無需變更程式碼。 DynamoDB 按需為讀取和寫入請求提供按請求付費的定價，以便需為使用的內容付費。
以下任一情況時，按需模式是個不錯的選擇：
試算RCU
假設必須每秒讀取 10 個大小為 10 KB 的項目，並保持最終一致性，必須配置多少個 RCU？
注意：1 RCU = 1 個強一致性或 2 個最終一致性，每秒讀取大小不超過 4 KB 的項目
答：需要 15 個 RCU。
計算如下：
DynamoDB 會針對在 DynamoDB 資料表中以下項目收費
DynamoDB 具有兩種容量模式：隨需和預置，而且隨附針對處理資料表上的讀取和寫入的具體計費選項。
注意：預置容量並非是發生在讀取或寫入時才計費，而是24小時都計費，慎選
如果有以下情況，則預置容量模式可能最適合：
如果有以下情況，則隨需容量模式可能最適合：
此範例說明支援 Auto Scaling 的已預置容量模式表格定價如何計算。Auto Scaling 會依實際使用容量持續設定預置的容量，讓實際的使用率保持在最接近目標使用率的狀態。
假設美國東部 (維吉尼亞北部) 區域建立新的 DynamoDB 標準資料表，且目標使用率設為預設值 70%、最低容量單位為 100 個 RCU 和 100 個 WCU，以及最高容量設為 400 個 RCU 和 400 個 WCU。為簡單起見，假設每次使用者與您的應用程式互動時，會執行一次寫入 1 KB 和一次嚴格一致讀取 1 KB。
假設在前 10 天內使用 1 到 70 個不等的 RCU 和 WCU。Auto Scaling 不會觸發任何擴展活動，而且每小時的帳單為 0.078 USD，其中包括 100 個已預置 WCU 共 0.065 USD (0.00065 USD * 100) 加上 100 個 RCU 共 0.013 USD (0.00013 USD * 100)。
現在假設第 11 天使用的容量增加到 100 個 RCU 和 100 個 WCU。Auto scaling 就會觸發擴展活動，將已預置容量增加到 143 個 WCU 和 143 個 RCU (100 個使用的容量 ÷ 143 預置的容量 = 69.9 %)。每小時帳單為 0.11109 USD (143 個 WCU 共 0.0925 USD 加上 143 個 RCU 共 0.01859 USD)。
假設第 21 天使用的容量減少到 80 個 RCU 和 80 個 WCU。Auto scaling 就會觸發縮減活動，將已預置容量減少到 114 個 WCU 和 114 個 RCU (80 個使用的容量 ÷ 114 預置的容量 = 70.2 %)。每小時帳單為 0.08952 USD (114 個 WCU 共 0.0741 USD 加上 114 個 RCU 共 0.01482 USD)。
當月需要支付 66.86 USD，帳單明細如下：
AWS 免費方案包括針對使用 DynamoDB 標準資料表類別的表格，預置容量為 25 個 WCU 和 25 個 RCU，讓您的每月帳單減少 14.04 USD。
資料儲存：假設資料表在月初佔用 25 GB 的儲存空間，而在月底增加到 29 GB，根據對資料表大小的持續監控，平均為 27 GB。由於您的資料表類別設定為 DynamoDB 標準，因此 AWS 免費方案中包含前 25 GB 的儲存空間。剩餘的 2 GB 儲存收費為每 GB 0.25 USD，因此該月的儲存成本為 0.50 USD。
至於當月，您的帳單將為 53.32 USD，其中包括 66.86-14.04 = 52.82 USD 的讀取和寫入容量費用，以及 0.50 USD的資料儲存費用。
假設美國東部 (維吉尼亞北部) 區域建立一個新的 DynamoDB 標準資料表。由於此表格適用於新應用程式，因此不會知道自己的流量模式。為簡單起見，假設每次使用者與應用程式互動時，會執行 1 次 1 KB 寫入和 1 次 1 KB 嚴格一致讀取。
在 10 天的期間，應用程式只有少許流量，每天在表格上產生 10,000 次讀取和 10,000 次寫入。但是在第 11 天，應用程式受到社群媒體的關注，應用程式流量在當天達到 2,500,000 次讀取和 2,500,000 次寫入。DynamoDB 可進行擴展，為使用者提供無縫體驗。然後，應用程式進入較規律的流量模式，到月底每天平均有 50,000 次讀取和 50,000 次寫入。下表總結當月的用量總計。
| 時間範圍 (當月日次) | 寫入總計 | 讀取總計 |
|---|---|---|
| 1–10 | 100,000 次寫入 (10,000 次寫入 x 10 天) | 100,000 次讀取 (10,000 次讀取 x 10 天) |
| 11 | 2,500,000 次寫入 | 2,500,000 次讀取 |
| 12–30 | 950,000 次寫入 (50,000 次寫入 x 19 天) | 950,000 次讀取 (50,000 次讀取 x 19 天) |
| 每月總計 | 3,550,000 次寫入 | 3,550,000 次讀取 |
| 每月費用 | 4.44 USD (每百萬次寫入 1.25 USD x 355 萬次寫入) | 0.89 USD (每百萬次讀取 0.25 USD x 355 萬次讀取) |
資料儲存：假設表格在月初佔用 25 GB 的儲存空間，而在月底增加到 29 GB，根據 DynamoDB 的持續監控，平均為 27 GB。由於您的資料表類別設定為 DynamoDB 標準，因此 AWS 免費方案中包含前 25 GB 的儲存空間。剩餘的 2 GB 儲存收費為每 GB 0.25 USD，因此該月的資料表儲存成本為 0.50 USD。
至於當月，帳單將為 5.83 USD，其中包括 4.44+0.89 = 5.33 USD 的讀取和寫入費用以及 0.50 USD 的資料儲存費用。
iThome鐵人賽
看影片追技術