標籤:日常 容量 大量 情境 方式 購物車 經濟 競價 複製
DynamoDB是一款全面託管的NoSQL資料庫服務。客戶能夠很easy地使用DynamoDB的服務。同一時候享受到高效能,海量擴充性和資料的持久性保護。
DynamoDB資料庫是Amazon在2012年1月18日公布的。
它融入了亞馬遜在大規模非關係型資料庫和雲端運算領域積累的多年豐富經驗。事實上早在2007年。亞馬遜就以前公布了一篇論文。深入討論了AmazonDynamo所使用的設計理念和實現技術,而且討論了怎樣在大規模擴充的同一時候提供高可靠的資料保護的問題。
最初的Dynamo設計基於一系列核心原則。以實如今分布式系統中搭建高可靠、高擴充系統。
如今的Amazon DynamoDB,繼續基於這些設計原則來構建。可是同一時候融入了Amazon多年以來在非關係型資料庫和雲端運算領域積累的寶貴經驗,比方Amazon SimpleDB和AmazonS3服務的技術。客戶能夠很easy的方式使用到全然託管的資料庫服務。
AmazonDynamoDB 是高效能、可擴充的NoSQL資料庫。今天的互連網應用的使用者、流量和資料都在不斷地增長。資料庫怎樣非常好地擴充。以滿足互連網應用對容量與效能的需求是讓非常多客戶頭疼的問題。DynamoDB非常好地攻克了這一難題。使用DynamoDB。開發人員能夠從相對小的規模開始,在應用吸引了很多其它使用者的時候,對應地添加DynamoDB的表的效能。
DynamoDB中的表沒有不論什麼容量限制。通過分布式的技術。DynamoDB把使用者對一個表的資料和流量請求分布在足夠數量的server上,以滿足並發請求的效能要求。同一時候,在面對不論什麼規模的請求的時候,DynamoDB都能夠提供能夠預測的高效能低延時的使用者體驗。
我們在國內的客戶,木瓜移動,就是採用了DynamoDB的資料庫服務,在RTB即時競價的線上移動營銷領域獲得成功。AppFlood是木瓜移動公布的移動即時競價的廣告平台。作為AppFlood的核心組件,資料庫的效能非常大程度上決定平台的即時競價的能力。
非常多因素,如網路通訊延遲、資料庫資料讀取的延遲、定價演算法的延遲都可能造成競價過程逾時。提供穩定的高效能、低延遲響應的DynamoDB,非常大程度上協助木瓜移動搭建成功的RTB平台。
DynamoDB給使用者提供了例如以下價值:
- 使用簡單。DynamoDB協助使用者處理全部的資料庫管理工作,從硬體資源配置,安裝配置,分布式叢集的搭建。和日常的系統維護。開發人員能夠從繁瑣的資料庫管理工作解放出來。
作為全然託管的資料庫,你不須要專家的技能來管理DynamoDB的安裝-你的開發人員全然能夠獨立完畢。訪問DynamoDB的時候,能夠通過簡單地API的方式。眼下通過只13個API,你就能夠實現對DynamoDB資料庫的表的管理,查詢檢索操作。單個項目Item的訪問和實現批量存取項目。
- 可擴充。Amazon DynamoDB的設計,沒有不論什麼容量上得限制。能夠把單個表的資料,分布在多個可用性區域內的多台server上。來滿足容量和吞吐的需求。
- 高效能。在高並發請求的情況下。DynamoDB仍然能夠保證非常低的延時。
由於全部資料都儲存在固態磁碟上。所以能夠保證持續的高效能。
執行在同一個地區的EC2上的應用程式,在訪問DynamoDB的資料對象的時候,通常能夠在server端體驗到個位元毫秒的回應時間。更重要的是,DynamoDB的表的效能是能夠預測的。即使在資料增長的情況下。由於DynamoDB分布式的特點。仍然能夠維持穩定的低延時的響應。DynamoDB在後台把你的資料在大量資源之間進行分區和在須要的時候又一次分區,從而能夠在大規模訪問的情況下還能提供非常高的IO效能。
- 持久和高可用。AmazonDynamoDB自己主動地在至少3個資料中心內複製資料。每一個寫操作。在至少寫入兩個節點之後,才會返回寫成功確認。
在不論什麼一個節點或者磁碟發生損壞的時候。資料都會及時的又一次複製資料和又一次分區。
這樣能夠確保在各種複雜的故障出現的時候,DynamoDB仍然能夠正常的提供服務,你全然不須要操心由於物理故障造成的資料丟失的情況。
除了上述的優點之外,作為一款雲上的全面託管的資料庫服務,DynamoDB還有非常多不同的地方。比較特別是它提供預先配置的輸送量目標。
曾經大家在使用資料庫的時候。想要準確的獲得你所預期的效能指標,包含回應時間和輸送量。是一件非常複雜的事情。你須要配置不同的硬體資源。包含CPU。記憶體,儲存容量與效能等等,然後期望這樣特定的硬體資源能夠非常好地支撐你的資料庫的效能需求。但實際上。你想要的資料庫效能是回應時間,和每秒鐘支援事務量,它們和硬體資源之間沒有準確的相關性。
非常多時候資料庫的效能容量規劃都像一個科研項目。充滿了不確定性。DynamoDB非常好地攻克了這個問題。
使用者在開始建立DynamoDB的表的時候,能夠配置應用所須要支援的輸送量目標。你能夠分別指定表每秒鐘支援多少個讀取和寫入的請求。完畢目標設定後。DynamoDB將會為你預留必要的機器資源,從而確保僅僅要是在給定的並發訪問量以下,應用就能夠享受到個位元毫秒的低延時的高速響應。
更重要的是,預配置的效能容量目標不是一成不變的。
假設你的資料庫的訪問量有了大幅度的增長,你能夠隨時調大DynamoDB的表的容量目標,從而支撐很多其它的訪問請求。對應地,假設你的應用不再須要之前預配置的並發訪問容量。你還能夠靈活地減少預配置的容量指標。從而幫你減少成本。
使用DynamoDB能夠讓開發人員靈活地開發應用程式。DynamoDB是模式自由的。這樣使用者不會被限制在某一個特定的資料模型裡。傳統的SQL資料庫中,表的模式在建立的時候就定義好。
你不能改動或者添加新的列到一個已經建立好的表中。Amazon DynamoDB沒有一個固定的模式,這樣開發人員能夠隨時給表添加新的屬性。靈活的資料模型能夠讓開發人員更加方便地進行敏捷開發和應用的高速迭代更新。
當然,和不論什麼分布式的系統一樣,使用DynamoDB也須要注意一致性的問題。DynamoDB把一致性的選擇權交給開發人員,讓開發人員自由地選擇適合自己應用的一致性模型。
在讀取資料的時候,開發人員能夠選擇採用強一致性的方式,還是終於一致性的方式來讀取資料。
假設是終於一致性的方式,意味著應用在剛提交一個寫操作之後,假設立即進行讀取,可能無法讀取到最新的資料,可是終於你會讀的一致的資料。
終於一致性的模型能夠在最大程度上確保服務的可用性,而且改善效能。比較典型的情境是大家在網上購物時使用的購物車。或者網站的評論資訊等等。這些情境對於一致性沒有非常嚴格的要求。
假設選擇採用強一致性的方式讀取資料,可能會犧牲一定程度的效能和服務的可用性。優點是在不論什麼情況下都能夠訪問到最新的資料。軟體開發也比較簡單。
比較典型的用例是須要強一致性的情境。比方網上購物時提交訂單的情境。
須要使用強一致性來確保同一商品不會同一時候銷售給兩個不同的客戶。
使用DynamoDB的成本是能夠預測。DynamoDB的定價模式很easy。基於每月每GB的儲存容量。和每月預配置的讀取和寫入的輸送量容量單位計費。容量比較easy理解。輸送量容量單位是個比較重要,大家也比較陌生的概念。每一個讀取容量單位(或者寫入容量單位)支援每秒鐘進行1次讀取(或者寫入)1個項目(item)。每一個讀取操作最大4KB大小,每一個寫入操作最大1KB大小。
超出大小的項目(item)須要額外的效能吞吐容量。
舉個範例,比方你配置了1000個讀取輸送量容量單位,和1000個寫入效能的輸送量容量單位。
這樣的情況下你的表將能夠支撐每秒鐘1000個讀取操作,和1000個寫入操作。假設是終於一致性的方式來讀取的話,你的表將能夠支撐每秒2000個讀取操作。
DynamoDB還提供了其它功能來進一步提高應用訪問的效能, DynamoDB能夠建立和維護針對主鍵屬性的索引。應用程式把須要查詢的主鍵提交給資料庫。就能非常快地獲得所相應的資料集。除此之外,Amazon DynamoDB還支援建立全域和本地的二級索引。使用二級索引,能夠讓應用程式在查詢主鍵以外的其它屬性時。也能夠獲得非常好的效能。客戶能夠對一個表建立一個或者多個二級索引,然後對索引執行查詢query的操作。
Amazon DynamoDB能讓使用者以簡單而且經濟有效地方式儲存和檢索隨意規模的資料。同一時候提供高並發下地低時延的響應。對於輸送量的保證和幾毫秒的低時延響應,使DynamoDB很適合遊戲、廣告、移動等等基於互連網的應用程式。
假設您想要瞭解更具體的資訊。能夠訪問DynamoDB頁面。
Amazon DynamoDB, 面向互連網應用的高效能、可擴充的NoSQL資料庫