簡介
Amazon DynamoDB是一個完全託管的NoSQL資料庫服務，可以提供快速的、可預期的性能，並且可以實現無縫擴展。只需要在AWS（Amazon Web Service）管理控制台上面，用滑鼠輕鬆點擊幾下，用戶就可以自己創建一個新的Amazon DynamoDB資料庫表，並可以根據實際需求對表進行擴展和收縮，這個過程既不需要停止對外服務，也不會降低服務性能。通過AWS管理控制台，用戶還可以看見資源利用情況和各種性能指標。Amazon DynamoDB可以使得用戶把操作和擴展分散式資料庫的沉重負擔，交付給AWS來處理，這樣，用戶就不需要擔心硬體配置、複製、軟體安裝和打補丁包、簇擴展等。
DynamoDB是亞馬遜的key-value模式的存儲平台，可用性和擴展性都很好，性能也不錯：讀寫訪問中99.9%的回響時間都在300ms內。DynamoDB的NoSQL解決方案，也是使用鍵/值對存儲的模式，而且通過伺服器把所有的數據存儲在SSD上的三個不同的區域。如果有更高的傳輸需求，DynamoDB也可以在後台添加更多的伺服器。
AmazonDynamoDB被設計成用來解決資料庫管理、性能、可擴展性和可靠性等核心問題。開發人員可以創建一個資料庫表，該表可以存儲和檢索任何數量的數據，並且可以
功能
如果要使用Amazon DynamoDB，你只需要：
使用AWS管理控制台或者AWS DynamoDB API來創建一個表，並且確定你所需要的請求容量。
使用Amazon DynamoDB API進行寫和檢索數據的操作；
使用AWS管理控制台中Amazon CloudWatch，對你的AWS DynamoDB資料庫的表的狀態和性能進行監視；
為你實際使用的資源付費：你每個月的消費賬單，是基於你確定的表的處理請求能力和存儲的數量；
特性
1、可擴展性：AWS DynamoDB的設計，可以支持在吞吐量和存儲能力上的無縫擴展；
額定的吞吐量：在創建一個表的時候，可以很簡單地設定你的表所需要的處理請求的能力。AWS DynamoDB會根據你的處理能力要求，為你的表分配專用的資源，從而滿足你的性能需求，並且會把數據分區到足夠多的伺服器上，從而滿足你對處理能力的要求。如果你的吞吐量需求改變了，你可以使用AWS管理控制台或者AWS DynamoDB API對你的表所需要的處理請求的能力進行修改。當擴展正在進行時，你仍然可以獲得先前級別的處理能力。
自動存儲擴展：AWS DynamoDB沒有對一個表中可以存儲的數據量的大小進行限制，當你使用AWS DynamoDB的寫操作API存入更多數據時，就會自動為你分配更多的存儲空間。
完全分散式、非共享架構：AWS DynamoDB可以實現水平擴展，可以無縫地把一個表擴展到多個（幾百個）伺服器上。
2、快速、可預期的性能：AWS DynamoDB的服務端的平均延遲，通常是幾毫秒(millisecond)。運行在固態盤上面的服務，可以在任何擴展級別下維持一致性和低延遲。
3、簡易的管理：AWS DynamoDB是一個完全託管的服務，你只需要簡單地創建一個資料庫表，剩下的所有事情都交給AWS服務來處理。你不需要擔心硬體和軟體的配給、建立、配置，也不要擔心軟體安裝和打補丁包，更不必擔心如何運行一個可靠的分散式資料庫簇，或者把數據分區到多個實例。
4、內置的容錯性：AWS DynamoDB具有內在的容錯能力，可以自動、同步地把你的數據複製到一個Region中的多個可用的Zone中，即使遇到單個機器或設施的實效，你的數據也可以得到很好的保護。
5、靈活性：AWS DynamoDB沒有固定的模式（schema）。相反，每個項目(item)都具有不同數量的屬性，可以支持多種數據類型，比如string、number和set。
6、強一致性、原子計數器：和許多非關係型資料庫不同，AWS DynamoDB使你的開發工作變得更加簡單，它可以支持讀操作的強一致性，從而保證你可以總是獲得最新的數據。讀操作支持多個本地(native)數據類型，比如number、string和multi-value attribute。這種服務也可以支持原子計數器（Atomic Counter），允許你通過一個簡單的API調用就可以自動增加和減少數值屬性。
7、性價比高：AWS DynamoDB被設計成在任何級別的負載下都可以取得很高的性價比。你可以從一個免費的等級開始，這種級別只支持每個月4000萬次的資料庫操作，對於超出這個免費級別的範圍，你只需要為你使用的資源支付以小時計費的很低的費用。由於具備了簡易的管理和高效的請求定價能力，採用AWS DynamoDB相比採用其他非關係型資料庫而言，具有更低的總體擁有成本（TCO：total cost of owership）。
8、安全：AWS DynamoDB使用可靠的密鑰方法，只允許授權用戶訪問數據，而絕對不允許非授權用戶的非法訪問。AWS DynamoDB集成了AWS Identiy and Access Management(簡稱AWS IAM)，可以實現更細粒度的訪問控制。
9、集成的監視功能：AWS DynamoDB可以在AWS管理控制台中，把關於你的表的關鍵性能指標都顯示出來。同時還集成了Amazon CloudWatch，可以讓用戶每個表的請求吞吐量和延遲，從而很容易實現對資源的跟蹤。
10、彈性的MapReduce集成：AWS DynamoDB同時集成了Amazon Elastic MapReduce（簡稱Amazon EMR）。Amazon EMR可以支持對大型的數據集執行複雜的分析操作，並且採用AWS中按需付費的Hadoop框架。隨著AWS DynamoDB的發布，對於用戶而言，很容易使用Amazon EMR來對存儲在DynamoDB中的數據集進行分析，並且把分析結果存儲在Amazon Simple Storage Service（簡稱Amazon S3）中，而原來的數據仍然原封不動地保存在AWS DynamoDB中。用戶也可以使用Amazon EMR來訪問存儲在多個地方的數據，比如AWS DynamoDB、Amazon RDS和Amazon S3，並且對來自這些地方的數據進行合併以後，做更加複雜的分析，並且把分析結果存儲在Amazon S3中。
比較
DynamoDB和SimpleDB的區別
熟悉Amazon AWS的朋友應該知道SimpleDB。細心的朋友還會發現，自DynamoDB上線以後，在AWS首頁的Database列表中，只能看到RDS和DynamoDB，DynamoDB已經替換了SimpleDB原來在這個列表中的位置，似乎SimpleDB已被打入冷宮
SimpleDB是AWS上的第一個NoSQL資料庫服務，AWS團隊也在部落格上詳數SimpleDB幾個致命的缺點，正是這些缺點導致AWS開發全新的資料庫服務。
•SimpleDB有單表限制。SimpleDB也有類似於Table的東西叫做Domain，每個Domain最多只能保存10GB的數據，而DynamoDB並沒有單表存儲的任何限制。雖然SimpleDB提供的Schema Free可以提高開發者的效率和靈活性，但10GB這種無法擴展的限制妨礙了很多開發者的使用，使得很多開發者採用了其他NoSQL解決方案。
•性能不穩定。SimpleDB以簡單為設計目標，SimpleDB並不需要用戶指定Primary Key，也不需要用戶創建索引，會默認對所有Attribute創建索引。然而這種簡潔性也帶來了一些副作用：如果用戶插入的一條數據帶有非常多的Attribute，SimpleDB就需要去更新所有Attribute的索引，而且不管用戶將來是否需要。真是所謂的：用或者不用，索引就在那裡。正是由於默認對所有Attribute創建索引，整個Domain才會有10GB這么奇怪的限制，以避免數據量變得比較大時，創建索引的過程會變得極慢無比，根本不能忍受。而DynamoDB因為有了Provisioned Throughput的限制以及採用了固態硬碟，可以保證每個請求的性能是非常穩定而且高效的。
•一致性問題。SimpleDB設計時採用的是最終一致性模型，而DynamoDB讀數據時用戶可以選擇弱一致性或者強一致性，對用戶而言可以根據業務特徵來進行選擇，畢竟強一致性在邏輯上更容易讓用戶接受。
在Schema上，兩者都不需要固定Schema，但value類型不夠豐富，在API設計上DynamoDB繼承了SimpleDB的風格，請求的參數個數顯得比較臃腫，好在有不同語言的SDK，方便了用戶的開發。
DynamoDB不是SimpleDB 2.0，但DynamoDB也吸收了SimpleDB以及其他NoSQL數據設計思想的精華，相信會有不少用戶會採用DynamoDB作為他們的NoSQL解決方案。
DynamoDB和Cassandra、MongoDB的比較
前面說過Cassandra受2007年Amazon發表的Dynamo論文影響非常深，在DynamoDB發布的第一天，提供Cassandra商業化支持的DataStax公司的Jonathan Ellis就寫了一篇文章，分析了Cassandra和DynamoDB的差異。
雖然Jonathan Ellis認為DynamoDB不支持Secondary Key Indexes是在開歷史的倒車，但如果DynamoDB支持了Secondary Key Indexes，那么它是無法保證每個請求性能的高效性的。這和DynamoDB的設計理念相衝突，於是捨棄了這部分的功能。
其實從開發的易用角度來講，DynamoDB沒有Cassandra和MongoDB強大，Cassandra有CQL可以做非常豐富的查詢，MongoDB的查詢功能也非常強大，而且後兩者都提供Shell客戶端，並有不少第三方開發的工具可以進行管理與使用。在條件更新上，DynamoDB也沒有MongoDB使用起來那么方便，並且MongoDB提供了更多的原子性操作。在對value類型的支持上，另兩者都不如MongoDB，畢竟MongoDB是文檔型的資料庫，可以理解為底層存儲的是JSON。畢竟，JSON支持的類型以及在JSON上可以做的操作是很豐富的。我一直覺得DynamoDB沒有支持類JSON格式是個遺憾。也許可能是DynamoDB團隊覺得如果支持類JSON格式的話，在API的設計上會顯得更加臃腫和讓用戶更難理解API如何使用。但個人認為，DynamoDB如果提供相應的SDK其實是可以解決這個問題的，就算MongoDB的開放接口相對DynamoDB更加複雜，開發者都是直接使用驅動（相當於SDK）進行開發，於是在開發套用上MongoDB遠勝於DynamoDB。
但從運維的角度來講，DynamoDB省去開發者部署/監控/維護資料庫環節，給開發者節約了大量時間，強大的擴展能力又減輕了後續運維的壓力，這正是DynamoDB最大的價值所在。
發展現狀
亞馬遜的Dynamo資料庫（DB）是增長速度最快的亞馬遜網路服務（AWS）產品之一。DynamoDB是一個提供自動化的可擴展性和配置IOPS的鍵-值數據存儲服務。對於開發人員和更喜歡使用一個託管服務來管理他們自己的NoSQL資料庫的應用程式管理員來說，亞馬遜的DynamDB是一個不錯的選擇。對於已經投入時間和資源建立IAM策略的AWS用戶來說，這是特別有吸引力的，因為他們可以精細地控制對保存在亞馬遜DynamoDB中數據的訪問。
為了在亞馬遜DynamoDB中保持細粒度的訪問控制，管理員們必須在IAM策略中指定條件。條件可以允許或拒絕對鍵-值數據存儲中特定項和屬性的訪問。這一模式限制了對特定值或行的訪問，例如與特定客戶賬戶相關的數據，這樣一來客戶就只能查看他們自己的數據了。它還允許應用程式管理員們為訪問特定屬性而定義規則。例如，一個策略可以指定只有甘願而非顧客可以查看資料庫中的一個類別屬性。
