亞馬遜CTO長文解析:我們為什麼要提供這麼多的資料庫產品?
在今年的AWS峰會上,AWS又釋出了一系列新的服務,毫無疑問,資料庫服務絕對是AWS投入的重點之一。雖然沒有像去年11月份的AWS re:Invent大會上那麼豐富,但依然佔有很大比重。
從下圖可以看到,AWS 所提供的資料庫服務品類豐富程度。
6月21日,亞馬遜(Amazon.com)技術長(CTO) Werner Vogels發表博文,對亞馬遜為何要在資料庫領域重金投入,並打造如此之多的資料庫產品的原因進行了解析,並列舉了大量的案例。
此前,他在就曾表示,資料是大部分企業業務的核心,而使業務獨特的原因所在,是所擁有的資料、資料的質量以及如何利用這些資料,這使得資料儲存越來越重要,寶藏就在資料庫中。兩年來,AWS透過其資料庫遷移服務遷移了超過60000個資料庫。
他指出,亞馬遜提供眾多資料庫產品供使用者選擇,是因為一刀切的資料庫時代已經成為過去式,儘管目前關聯式資料庫保持活躍,並且仍然適用於許多應用場景,但針對鍵值,文件,圖形,記憶體和搜尋等應用場景的專用資料庫卻能更高效的解決問題,更為重要的是,客戶體驗會更好。
以下為Werner Vogels部落格原文:
我經常被人問到一個問題,為什麼亞馬遜要提供這麼多的資料庫產品?對我來說,答案很簡單,開發者希望他們的應用程式能夠很好的被構建和有效擴充套件,為此,他們需要能夠在同一應用程式中使用多個資料庫和資料模型。
很少有一個資料庫能夠滿足多個不同應用場景的需要,一刀切的資料庫時代已經過去,開發人員正在使用大量的專用資料庫來構建高度分散式的應用程式。開發人員正在做他們最擅長的事情:將複雜的應用程式分解成更小的部分,然後選擇解決每個問題的最佳工具。工作中的最佳工具通常因應用場景而異。
過數十年來,因為唯一的資料庫選擇只有關聯式資料庫,無論應用程式中的資料型別或功能如何,資料都被建模為關係資料,而不是應用場景驅動對資料庫的需求。關聯式資料庫是否專為非規範化模式構建,並在資料庫中強制引用完整性?當然,最關鍵的一點是,並非所有應用程式的資料模型或應用場景都與關係模型匹配。
正如我之前談到的那樣,我們構建Amazon DynamoDB的原因之一,是因為當時亞馬遜正在突破商業資料庫的極限,我們無法維持不斷增長的亞馬遜業務所需要的可用性,可擴充套件性和效能需求。我們發現大約70%的操作是鍵值查詢,其中僅使用主鍵並返回單行。在不需要引用完整性和事務的情況下,我們意識到,使用不同型別的資料庫可以更好的服務於這些訪問模式。此外,隨著Amazon.com的增長和規模的擴大,無限的橫向擴充套件需要成為一個關鍵的設計點 - 擴大規模根本不是一種選擇。這最終導致了DynamoDB,這是一種非關聯式資料庫服務,構建的目的是擴充套件關聯式資料庫的範圍。
但這並不意味著關聯式資料庫不能在當今的開發中不可用,恰恰相反。事實上,我們的客戶已經證實這一點,因為Amazon Aurora仍然是AWS歷史上增長最快的服務。我們在Amazon.com網站上看到的是超出其預期目的使用資料庫。這篇博文的核心就是學習 - 資料庫是為了某個目的而構建,將應用場景與資料庫相匹配將有助於您更快地編寫高效能,可擴充套件且功能更強大的應用程式。
專用資料庫
世界仍在變化,非關聯式資料庫的種類不斷增加。我們越來越多地看到客戶想要構建需要各種資料模型的網際網路級應用程式。針對這些需求,開發人員現在可以選擇關係,鍵值,文件,圖形,記憶體和搜尋資料庫。每個資料庫都解決了一個特定問題或一系列問題。
讓我們仔細看看每個資料庫的目的:
· 關係:關聯式資料庫是自描述的,因為它使開發人員能夠定義資料庫的架構以及資料庫中行和表之間的關係和約束。開發人員依賴關聯式資料庫的功能(而不是應用程式程式碼)來強制執行架構並保持資料庫中資料的引用完整性。關聯式資料庫的典型應用場景包括Web和移動應用程式,企業應用程式、線上遊戲。Airbnb是使用Amazon Aurora構建的高效能和可伸縮應用程式的一個很好的例子。Aurora為Airbnb提供了一種完全管理,可伸縮且功能強大的服務來執行他們的MySQL工作負載。
· 鍵值:鍵值資料庫具有高度可分割槽性,並允許在其他型別的資料庫無法實現的級別上進行水平擴充套件。諸如遊戲,廣告技術和物聯網等使用案例特別適合於鍵值資料模型,這種模型中,訪問模式需要低延遲的get/put已知的鍵值。DynamoDB的目的是為任何規模的工作負載提供一致的單位毫秒級延遲。這種一致的效能是Snapchat Stories功能(包括Snapchat的最大儲存寫入工作負載)轉移到DynamoDB的重要組成部分。
· 文件:文件資料庫對於開發人員來說是很直觀的,因為應用層中的資料通常表示為JSON文件。開發人員可以使用他們在應用程式程式碼中使用的相同文件模型格式來儲存資料。Tinder是使用DynamoDB的靈活模式模型來實現開發人員效率的一個示例。
· 圖形:圖形資料庫的目的,是使構建和執行具有高度連線資料集的應用程式變得容易。圖形資料庫的典型應用場景包括社交網路,推薦引擎,欺詐檢測和知識圖譜。Amazon Neptune是一個完全託管的圖形資料庫服務。Neptune同時支援屬性圖模型和資源描述框架(RDF),可選擇兩個圖形API:TinkerPop和RDF / SPARQL。目前Neptune的使用者正在建立知識圖,提供遊戲內推薦建議以及檢測欺詐行為。例如,Thomson Reuters正在幫助他們的客戶透過使用Neptune來駕馭複雜的全球稅收政策和法規網路。
· 記憶體:記憶體資料庫在金融服務,電子商務,網路和移動應用程式都有應用場景,如排行榜,會話儲存和實時分析,這些場景需要微秒級的響應時間,並且隨時可能出現大量流量高峰。我們提供Memcached和Redis的Amazon ElastiCache,以服務於低延遲,高吞吐量的工作負載,如麥當勞,而基於磁碟的資料儲存是無法滿足這些工作負載的。Amazon DynamoDB加速器(DAX)是專用資料儲存的另一個示例。DAX的構建是為了讓DynamoDB的讀取速度提高一個數量級。
· 搜尋:許多應用程式輸出日誌,以幫助開發人員解決問題。Amazon Elasticsearch Service(Amazon ES)旨在透過索引,彙總和搜尋半結構化日誌和指標來提供機器生成資料的近實時視覺化和分析。Amazon ES還是一個強大的、高效能的全文搜尋引擎。Expedia正在使用150多種Amazon ES域、30 TB的資料和300億個文件,用於各種關鍵任務應用場景,從操作監控和故障排除到分散式應用程式堆疊跟蹤和定價最佳化。
用專用資料庫構建應用程式
開發人員正在構建高度分散式和解耦的應用程式,而AWS使開發人員能夠透過使用多個AWS服務構建這些雲本地應用程式。
例如 Expedia,雖然Expedia的網站看起來就像是一個單一的應用程式,但在後臺,Expedia.com由許多元件組成,每個元件都有特定的功能。透過將一個應用程式(如Expedia.com)分解為具有特定任務的多個元件(例如:微服務,容器和AWS Lambda函式),開發人員可以透過增加規模和提高效能,減少操作,提高部署靈活性,並使不同的元件能夠獨立的演化來提高生產率。在構建應用程式時,開發人員可以將每個應用場景與最適合需要的資料庫進行匹配。
為了實現這一點,請看看我們的一些客戶正在使用多種不同型別的資料庫來構建他們的應用程式:
· 作為個性化搜尋的一部分,Airbnb使用DynamoDB來儲存使用者的搜尋歷史記錄以進行快速查詢。Airbnb還使用ElastiCache在記憶體中儲存會話狀態以加快網站呈現速度,並將Amazon RDS上的MySQL 用作其主要事務資料庫。
· Capital One 使用Amazon RDS儲存狀態管理的事務資料,Amazon Redshift儲存為需要聚合分析的Web日誌,並使用DynamoDB儲存使用者資料,以便客戶可以使用Capital One應用程式快速訪問他們的資訊。
· Expedia 透過使用Aurora,Amazon Redshift和ElastiCache構建了一個實時資料倉儲,用於內部市場分析和市場定價。資料倉儲使用ElastiCache for Redis執行 multistream 聯合和自聯接, 並帶有一個24小時回望視窗。資料倉儲還將處理後的資料直接儲存到Aurora MySQL和Amazon Redshift中,以支援操作和分析查詢。
· Zynga 將Zynga撲克資料庫從MySQL遷移到DynamoDB,獲得了巨大的效能提升。過去需要30秒的查詢現在只需要一秒鐘。Zynga還使用ElastiCache(Memcached和Redis)來代替它們自己管理的記憶體快取。Aurora的自動化和無伺服器可擴充套件性使 Zynga 成為使用關聯式資料庫的新服務的首選。
· 強生公司使用Amazon RDS,DynamoDB和Amazon Redshift來最大限度地減少花費在收集和配置資料上的時間和精力,並允許快速推導洞察力。AWS資料庫服務正在幫助強生改善醫生的工作流程,最佳化供應鏈並發現新藥。
就像他們不再編寫單一應用程式一樣,開發人員也不再使用單個資料庫來處理應用程式中的所有應用場景 - 他們正在使用多個資料庫。
儘管關聯式資料庫保持活躍,並且仍然適用於許多應用場景,但針對鍵值,文件,圖形,記憶體和搜尋應用場景的專用資料庫可以幫助您最佳化功能,效能和規模,更重要的是,您的客戶體驗會更好。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/11310314/viewspace-2156653/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 我們為什麼要遠離資料庫生成的ID?- Tugberk Ugurlu資料庫
- 為什麼會有這麼多種的資料庫資料庫
- 為什麼我們需要資料庫事務資料庫
- 資料市場觀察(一)我們為什麼要大資料?大資料
- oracle資料庫的ora_p程式為什麼這麼多?Oracle資料庫
- 我們為什麼要技術寫作
- 老闆今天問我為什麼公司的資料庫這麼爛,我是這樣回答的......資料庫
- 為什麼我們要熟悉這些通訊協議? 【精讀】協議
- 我們為什麼需要 DevSecOps 和製品倉庫?dev
- [譯]我們為什麼要寫 super(props)?
- 我們為什麼要從 HTTPRunner 轉向 MeterSphereHTTP
- #AWS:為什麼我們要持續投資Rust?Rust
- 我們為什麼要學Java?Java好在哪?Java
- 我們為什麼要閱讀webpack原始碼Web原始碼
- 為什麼不建議你用 MongoDB 這類產品替代時序資料庫?MongoDB資料庫
- Koala Framework是什麼?我為什麼要寫這個框架?Framework框架
- 作為AI產品經理,我們到底在優化什麼?AI優化
- 我們為什麼要學習資料結構和演算法?(一)資料結構演算法
- 為什麼 JavaScript 的 this 要這麼用?JavaScript
- 為什麼我們要選用 Elasticsearch 而不用 SolrElasticsearchSolr
- 為什麼我們要學習Microsoft Graph for Office 365ROS
- 為什麼NoSQL資料庫這麼受歡迎?SQL資料庫
- 資料庫倉庫系列:(一)什麼是資料倉儲,為什麼要資料倉儲資料庫
- 翻譯:WebAssembly簡介:我們為什麼要關心這個技術? Web
- 為什麼要選擇分散式資料庫?分散式資料庫
- 為什麼要對資料庫最佳化資料庫
- 資料庫產品用什麼抓住使用者資料庫
- 【國產資料庫名錄一覽】竟有這麼多國產資料庫產品?很多沒聽過資料庫
- 為什麼我們程式設計師工作得這麼累?程式設計師
- 為什麼我們要學習DMAIC?—舉例說明AI
- 我們為什麼要嘗試前後端分離後端
- 為什麼我們要從 NodeJS 遷移到 Ruby on RailsNodeJSAI
- 我們程式設計師為什麼要關注 JavaScript ?程式設計師JavaScript
- 聊聊分割槽Partition——我們為什麼要分割槽(下)
- 聊聊分割槽Partition——我們為什麼要分割槽(中)
- 聊聊分割槽Partition——我們為什麼要分割槽(上)
- 為什麼網際網路產品的成功率這麼低
- 為什麼我們使用的企業簽名這麼容易掉呢?