從Amazon DynamoDB的十年演進,看NoSQL資料庫與雲的融合創新
Dynamo 資料儲存的成功激勵了 亞馬遜機器學習副總裁 Swami Sivasubramanian (右上)、 Amazon.com 首席技術官 Werner Vogels (右下)和同事撰寫 Dynamo 研究論文,並在 2007 年 ACM 作業系統原理研討會(SOSP 會議)上分享。Dynamo 論文被認為是 NoSQL 的開篇之作。Amazon DynamoDB,雲託管 NoSQL 資料庫服務於10年前的今天走上歷史舞臺。
Amazon DynamoDB在大型非關係資料庫和雲服務的10年演進
10 年前的今天(2012 年 1 月 19 日),亞馬遜雲科技推出了 Amazon DynamoDB 。
Amazon.com 首席技術官 Werner Vogels 在一篇技術部落格中寫道:“十年前的今天是非常激動人心的一天,因為我們釋出了 Amazon DynamoDB,這是一種快速、高度可靠且具有成本效益的 NoSQL 資料庫服務,旨在用於網際網路規模的應用程式。 Amazon DynamoDB 代表的是亞馬遜在大型非關係資料庫和雲服務技術領域 15 年持續投入的成果。 ”
“幾年前,我們發表了一篇關於亞馬遜 Dynamo 分散式儲存技術的論文,併成為了首批非關係資料庫的雛形。” Vogels 繼續說道, “最初的 Dynamo 設計基於一強大的核心分散式系統原則,最終產生了一個超可擴充套件和高度可靠的資料儲存系統。而它的下一代演進產品 Amazon DynamoDB 是一項新的雲服務,它繼續以這些原則為基礎,並建立在我們多年大規模執行非關係資料庫和雲服務(如 Amazon SimpleDB 和 Amazon S3)的經驗之上。我很高興看到亞馬遜所有的探索和經驗都以易於使用的託管服務的形式提供給我們的客戶。”
和 Werner 一樣,彼時還是一名亞馬遜研究工程師,從事分散式系統技術的設計、實施和分析相關的工作的 Swami Sivasubramanian(現任亞馬遜雲科技資料庫、資料分析、機器學習副總裁)是同為 2007 年 Dynamo 論文的合著作者之一,且是 Amazon DynamoDB 開發的主要貢獻者。
“ 在資料和機器學習方面,我們正在經歷一個驚人的文藝復興時代。 ”而 Amazon DynamoDB 釋出十年後,Swami 表示,“我們現在生活在這樣一個時代,您可以將資料實際儲存在這些資料庫中,並快速開始在 Amazon S3 中構建您的資料湖,然後您可以立刻開展資料分析,甚至在幾周甚至幾天就能通過 Amazon SageMaker 實現人工智慧賦能。這令我感到震驚。我們現在有機會幫助客戶更快地從他們的資料中獲得洞察力” 。
Swami 認為, “這是一個真正讓我興奮的使命,因為客戶真的希望將他們的資料用於工作以實現資料驅動的決策。 越來越多的 CIO 和組織意識到這將是最知情的人的生存,而那些將他們的資料用於工作的人不僅會生存下來,而且會茁壯成長。 ”
為紀念 Amazon DynamoDB 推出 10 週年,我們向 Swami 詢問了三個關於 Amazon DynamoDB 的起源、前身以及未來的問題。
提問
Qustions
&
解答
Answers
Q1:您是 2007 年 Dynamo 論文的合著作者。當時,該行業正在過渡到橫向擴充套件與縱向擴充套件的架構方法。您能告訴我們有關 Dynamo 的起源故事嗎?
Swami: 提到 2007 年,我必須從 2004、2005 年回顧開始。即使我正在攻讀博士學位(Swami 於 2006 年從阿姆斯特丹自由大學獲得電腦科學博士學位),我也在考慮我將在哪裡工作。 最終說服我以研究工程師實習生的身份加入亞馬遜,是因為我看到了亞馬遜正在快速成長,突破規劃的界限。
我承認我作為一個局外人有點懷疑。那時,亞馬遜雲科技甚至還不存在。但是當我加入時,很快就有了一個“瞬間”——亞馬遜是一家電子商務公司,但實際上它是一家也從事電子商務的科技公司。看到亞馬遜必須發明如此多的新技術來支援其電子商務工作量,這對我來說是一個有趣的啟示。
作為一名實習生,我在 Amazon.com 擔任工程師,在假期流量高峰期間,由於資料庫事務死鎖問題,我們經歷了嚴重的擴充套件失敗。這個問題是由我們當時使用的商業供應商的關係資料庫引起的。一群工程師聚在一起編寫了我們所說的 COE(correction of errors document),這是一份錯誤更正文件,我們在其中說明發生了什麼、我們學到了什麼、我們如何解決問題以及如何避免再次發生。
我不知道是我太天真還是隻是對只有 20 歲的實習生有信心,但我問了一個問題‘我們為什麼要為這種負載使用關係資料庫?這些工作負載不需要 SQL 級別的複雜性和事務保證。
這讓我們開始重新思考如何設計底層資料儲存。當時還沒有一個可伸縮的非關係資料庫。這就是我們著手搭建 Amazon Dynamo 原始版的原因,也是我們撰寫論文的原因。Amazon Dynamo 並不是我們當時唯一在思考研究的架構。我們意識到我們還需要一個可擴充套件的儲存系統, Amazon S3 就誕生於此,我們還意識到我們需要一個更易於管理的關係資料庫,能夠進行自動複製、故障切換和備份/恢復,這也是我們建立 Amazon RDS 的初衷。
我們最初寫 Dynamo 論文時定了一條規則,即 “在我們開發原始設計時不要釋出” ,而是首先讓 Dynamo 在支援多個 Amazon.com 服務的生產環境中執行,這樣 Dynamo 論文將是一種端到端的撰寫與經驗背書。Werner 和我對此感覺非常強烈,因為我們不希望僅僅撰寫一篇學術論文。這就是為什麼當 10 年後那篇論文獲得ACM的時間考驗獎(由 ACM 主辦的 The SIGOPS Hall of Fame Award,從 2016 年開始評選過去十年科技圈最具影響力的論文名人堂)時,我感到非常自豪。
Q2:Amazon DynamoDB 的起源故事是什麼?過去十年該技術是如何發展的?
Swami: Amazon DynamoDB 背後的想法來自於與 SmugMug 和 Flickr 的執行長 Don MacAskill 等客戶的討論。其實,他們就是最早帶有網際網路屬性的公司,而在當時像這樣的網際網路公司也在快速走向市場。線上使用者數量呈爆炸式增長,資料模式不固定,追求快速交付,輕運維,是他們的特徵。將所有資料儲存在一個盒子中的傳統關係資料庫模型無法很好地擴充套件,它迫使使用者重新分片他們的關係資料庫,然後管理所有的分割槽和重新分割槽等等。
這對我們來說並不新鮮。這些挑戰是我們構建原始 Amazon Dynamo 的原因,當時它還不是一項服務,還是一個由亞馬遜工程師操作的軟體系統。在我們的一次客戶諮詢會議上,Don 說:“你們都啟動了 Amazon Dynamo,並展示了可擴充套件的非關係資料庫系統的可能性。為什麼我們不能將其作為外部服務?”
當時,所有高階亞馬遜雲科技高管都在場,這也是我們當時問自己的一個問題。Don 不是唯一需要它的客戶,越來越多的客戶想要那種無需處理分割槽和重新分割槽的可擴充套件資料庫,而且他們還想要極高的可用性。逐漸的,我們開始認真思考構建一個不受 SQL 限制的可擴充套件雲資料庫。
Amazon DynamoDB 與原始 Amazon Dynamo 不同,因為它實際上是通過幾個原始 Amazon Dynamo 元件搭建了一易於使用的雲服務。 我們的客戶不再需要配置叢集,通過建立一個表(Table)儲存資料,就可以實現並無縫縮放;他們不必任何操作,甚至無需安裝單個庫來操作資料庫。
Amazon Dynamo 到 Amazon DynamoDB 的這種演變非常重要, 因為我們真正以前所未有的方式擁抱雲 ,以及它的彈性和可擴充套件性。
我們於 2012 年 1 月 18 日推出它,一經推出就大受歡迎。Don MacAskill 的公司和其他幾家公司開始使用它。從釋出之日起,不僅彈性,而且個位數的延遲效能都與客戶產生了非常好的共鳴。我們進行了相當多的創新,從協議層一直到 SSD 儲存的底層儲存層,以及我們啟用的各種其他功能。最早的生產專案之一是有一個有趣用例的客戶;他們在做超級碗(Super Bowl:全國橄欖球聯盟決賽,全美直播的體育界春晚)廣告。
因為 Amazon DynamoDB 非常有彈性,它可以無縫地擴充套件到每秒 100,000 次寫入 ,然後在超級碗結束後縮減,這樣他們就不會再產生額外成本。
這在技術領域也是個大事件,現在我們司空見慣的橫向擴充套件與彈性,對當時的資料庫來說還不具備這樣的想象空間。但是 Amazon DynamoDB 為雲而構建的架構使所有這些橫向擴充套件用例成為可能 ,這也是 Amazon DynamoDB 現在支援多個高流量 Amazon 站點和系統(包括 Alexa、Amazon.com 和所有 Amazon)的履行中心的原因之一。
去年,在我們 66 小時的 Prime Day 期間,這些來源進行了數萬億次 API 呼叫,而 Amazon DynamoDB 以個位數毫秒的效能保持了高可用性,達到每秒 8920 萬個請求的峰值。
自 2012 年以來,我們增加了許多創新,不僅是因為它的基本可用性、耐用性、安全性和規模,而且還因為它的易用性功能。
我們不止步於鍵值儲存,還支援基於雜湊的分割槽和基於範圍的分割槽,並且我們增加了對二級索引的支援,以支援更復雜的查詢功能——同時不影響規模或可用性。
我們現在還支援通過適用於 Amazon DynamoDB 的 Amazon Kinesis Data Streams 捕獲可擴充套件的流式資料。我堅信任何資料庫的工作都不應該是一個孤島,更不可能是死衚衕。它應該生成變化的資料流,然後使用它來將其連線到分析應用程式或其他資料儲存。
我們繼續在備份和恢復等功能上進行全面創新。對於像 Amazon DynamoDB 這樣具有數百萬個分割槽的大型資料庫系統,進行備份和恢復並非易事,許多偉大的創新都致力於讓客戶輕鬆體驗這種體驗。
我們還添加了 建立全域性表(Global Table) 的功能,以便客戶可以實現資料庫負載的全球覆蓋的同時,具備本地讀寫效能。然後我們增加了使用 Amazon DynamoDB 進行事務的能力,所有這些都著眼於您如何繼續保持 Amazon DynamoDB 圍繞可用性和可擴充套件性的使命。
最近,我們還致力於更強的成本優化。客戶通常需要長期儲存資料,雖然這些舊資料可能很少被訪問,但它必須保持高度可用。
例如,社交媒體應用程式的終端使用者很少訪問較舊的帖子和上傳的影象,但應用程式必須確保在請求時可以立即訪問這些工件。這種不經常訪問的資料可能會給客戶帶來巨大的儲存費用,因為它們的數量不斷增長,並且儲存這些資料的成本相對較高,因此客戶在這些情況下通過編寫程式碼將較舊、訪問頻率較低的資料從 Amazon DynamoDB 移動到成本較低的儲存來優化成本 Amazon S3 等替代品。
因此,在最近的 re:Invent 大會上,我們推出了 Amazon DynamoDB Standard-Infrequent Access 表類 ,這是一個新的經濟高效的表類,用於儲存不經常訪問的資料,同時保持 Amazon DynamoDB 的高可用性和效能。
我們將保持 Amazon DynamoDB 的最初願景作為指引,持續創新,以幫助客戶提供更易於查詢的用例、進行復雜的全域性事務複製的能力,同時繼續管理成本。
Q3:未來 10 年會帶來什麼?
Swami: 當我們十年前開始使用 Amazon DynamoDB 時,客戶才剛剛開始更好地理解雲本身——它的好處以及他們可以做什麼。
現在,我們生活在這樣一個世界中,就客戶如何 IT 應用程式而言,雲是新常態,而規模也是新常態,每個應用程式都要基於不確定性構建。Amazon DynamoDB 本身將在這個持續的旅程中,我們將繼續代表客戶進行創新。我們將繼續朝著端到端的現代化資料戰略使命邁進。因為正如我之前提到的,“沒有資料庫是孤島”。
客戶不再只想在他們的資料庫中儲存和查詢資料。然後,他們想要分析這些資料以創造價值,無論是更好的個性化或推薦引擎,還是可以使用機器學習執行預測分析的預測系統。
將點對點連線起來,並繼續使 Amazon DynamoDB 更安全、更可用、更高效能和更易於使用,這將是我們永無止境的旅程。
*本文由特約撰稿人整理,並由dbaplus社群轉載
回看人類歷史上每一次技術跨越,生產力變革永遠不會缺席。發展了50餘年的“資料庫”軟體,它的下一個必然變革方向——“雲原生資料庫”也已經悄然走到了第十個年頭。
未來十年,雲原生資料庫領域的創新將遠遠超越過去十年。我們究竟應該從怎樣的視角審視過去的技術積累,並積極為未來的技術變革浪潮作好準備?期待與您一起相約 亞馬遜雲科技 雲原生資料庫線上大會 ,深度探討雲原生資料庫的最佳實踐。
掃描下方二維碼
免費報名,線上參會
↓ 點這裡瞭解會議詳情及報名
- 日均PB級資料分析,B站基於Iceberg的湖倉一體架構實踐
- 實戰搭建MySQL高可用架構,手殘黨表示都會了!
- 萬字經驗帖:不具備這9種能力,建議不要做SRE
- 融合Zabbix和Prometheus,打造無短板視覺化的監控不難!
- 備戰618,省時省力的全鏈路壓測系統怎麼搭?
- 醒醒吧,你根本不適合用事件驅動架構
- 保障穩定性與高可用的處理流程大全
- 那個沒被雲原生幹掉的運維,轉頭就做了SRE……
- 總結出這套資料庫遷移經驗,我花了20年……
- 兩小時 Elasticsearch 效能優化,直接把慢查詢幹團滅了……
- 適配金融業:IT運維管理體系數字化轉型探索與實踐
- 晉升遇瓶頸,奮戰一線的技術人該停下來看看這些……
- 3種方法 3種選型,用分散式鎖還怕啥併發問題呀?
- 基於ES的開源分散式SQL資料庫,CrateDB適用於哪些場景?
- 2022Gdevops廣州站:聚焦運維、資料庫、金融科技應“雲”而生的技術創新
- 搞定這8個Kafka生產級容量評估,每日10億 請求輕鬆拿捏!
- 從Amazon DynamoDB的十年演進,看NoSQL資料庫與雲的融合創新
- 多起宕機事故發生,竟都歸咎於最初的失敗設計……
- 效率提升10倍,網易遊戲面向終態的應用交付實踐
- 去哪兒網MySQL日誌分析實踐,80%資料丟失都給你救回來!