在不那麼遙遠的舊 IT 時代，有這樣一個段子——假如把資料庫們”聚在一起“開會”。
Oracle: 我們需要企業級資料庫。
MySQL: Oracle 不開源。
PostgreSQL: MySQL 的功能不夠多。
SQLite: 你可以把我嵌入到任何地方。這樣，4 種資料庫夠大家用了。
MongoDB: 為什麼我們要用 join 和模式 (schema)?
Bigtable: MongoDB 的對 web 的擴充套件性不好。
Hbase: Bigtable 不開源。....
（摘自：《外刊 IT 評論》）
這段“對話”顯然有詼諧的成分，但也對映出一個無法逃脫的現實——一個資料庫包打天下的時代過去了。俗話說，“工欲善其事，必先利其器”，那麼，我們到底需要怎樣的資料架構？又該如何選擇資料庫？在亞馬遜雲科技首期 Build On《現代化資料架構思考與實踐 -NoSQL 的前世今生解讀及架構搭建》中，資料庫產品專家呂琳、李君針對現代化資料架構這一話題展開分享並帶領大家現場完成了非關係型資料庫相關的兩個動手實驗。
01 單一資料庫無法滿足需求
在資料庫技術的發展史上，1970 年是個巨大的轉折點，這一年，埃德加·科德發表了《大型共享資料庫資料的關係模型》一文。由此，關係型資料庫一直佔據著資料庫生態圈的頂尖地位。科德本人也憑藉這項成就獲得了圖靈獎。值得一體的是，僅關係型資料庫這一個門類就前後誕生了四個圖靈獎得主。
隨著現代化應用的發展，開發者對效能、規模和可用性的要求更高。使用者量動輒百萬以上，資料量從 TB 增長至 PB，效能要求達到毫秒甚至微妙級別的延遲...... 與此同時開發者希望免去繁重、重複的運維和部署工作，將更多的精力投入到開發業務中去。單一資料庫的模式已無法滿足企業的需求。
2004 年，亞馬遜電商發生過一次很嚴重的故障，致使使用者連續幾個小時無法完成交易。當時，亞馬遜電商採用的是 Oracle 關係型資料庫，但由於關係型資料庫天然地在面對海量資料的高效率讀寫時，讀寫性效能較差，因此，儘管擁有上萬套 Oracle 資料庫，並對資料進行了分庫分表處理，在業務量劇增的情況下，系統還是崩潰了。這時的亞馬遜已然遇到了關係型資料庫的擴充套件瓶頸。
在那次重大的事故後，亞馬遜開始重新考量、構建自己的應用，並重新選擇資料庫。其實，當時作為 Oracle 全球最大的客戶之一，亞馬遜享受到的 license 折扣是極低的，但是，面向未來的爆炸式發展需求，讓他們意識到當前資料架構的不完善。在謹慎調研與設計之後，亞馬遜決定不再採用單一資料庫模式，而是將其進行拆分，同時採用 Amazon Redshift、Amazon DynamoDB、 Amazon Aurora、 PostgreSQL 等多種型別的資料庫。這樣的做法避免了僅採用關係型資料庫產生的因資料集增大而帶來的效能下降問題。在海量資料集下依舊可以保持高併發請求和持續低響應延遲，且幾乎沒有擴充套件上限。如今，亞馬遜電商系統在類似雙 11 活動規模的 Prime Day 上，每秒可能會應對超過 8000 萬次的呼叫，如果僅採用關係型資料庫，幾乎是不可能實現的。
不僅僅是在亞馬遜，網際網路行業、金融行業的很多巨頭公司，都已同時採用多種資料庫。如為全球旅行者和房東提供出租 / 租用的服務型網站 Airbnb，在關係型資料庫上選擇 MySQL 和 RDS，在非關係型資料庫上選擇 DynamoDB，同時採用 Amazon ElastiCache、Redis 進行前端的資料快取。金融行業公司 Capital One 大量使用非關係型資料庫 DynamoDB，而需要資料分析時則會用到 Amazon Redshift。
每一款資料庫都有其歷史背景，是特定時間、技術條件之下面向指定場景需求的產物，各有所長的同時也各有侷限性。因此，不同的業務型別、乃至同一業務鏈路下的不同場景特性可以按需拆分為不同的資料庫需求。並且，隨著微服務拆分地越來越細，資料庫也天然得有了拆分的保障，越來越多企業更適合、也更願意根據其需求場景來選擇專用資料庫。
所以，今天我們為大家帶來的是現代化資料架構的第一個也是最重要的一個概念——“專門構建，專庫專用”
02 如何選擇合適的資料庫？
要說最眼花繚亂的，莫過於資料庫服務的“大家族”了。在不同的資料庫間如何根據自己的應用場景進行選擇，才能讓每個場景都獲得極致的效能、可用性和擴充套件性？呂琳在分享中介紹了不同型別專用資料庫的應用場景。
他首先從開發者們最為熟悉的關係型資料庫講起。比較常用的關係型資料庫有 PostgreSQL、MySQL、MariaDB、Oracle Database 、SQL Server 等，亞馬遜雲科技的 RDS 也同時提供五種常用資料庫引擎。為什麼還要自創了 Amazon Aurora，呂琳說：“這其實源自客戶的需求。”
客戶反饋，Oracle、SQL Server 功能強大，提供企業級支援，但它們有苛刻的 License 許可機制和嚴重的繫結傾向，且費用昂貴。反之，MySQL、PostgreSQL 這樣的開源資料庫，雖然免費，但又少了功能、效能、高可用性及企業級支援。
如何才能魚與熊掌兼得？2014 年，亞馬遜雲科技推出首款專為雲打造的關係型資料庫 Amazon Aurora。Amazon Aurora 完全相容 MySQL 和 PostgreSQL，效能可以達到標準的 MySQL 的五倍，標準的 PostgreSQL 的三倍，且可按照使用量付費。在效能方面 Amazon Aurora 是一個高可用的典型案例。
但作為一款關係型資料庫，Amazon Aurora 依舊逃脫不了關係型資料庫的設計問題，即隨著資料量的增長，索引效能一定會有所下降。當面對海量資料，又要保證索引效能，企業通常會採用兩種辦法。
其一，是對關係型資料庫進行分庫分表。分庫分表能夠提升效能，增加可用性，然而，這樣的方式也會為開發者帶來很多麻煩。比如，事務問題怎麼解決？跨分辨查詢怎麼辦？如何讓冷熱資料均勻散落在各個分庫分表內？這些都需要開發者花時間去考慮。
第二種方法，就不得不談到非關係型資料庫了。非關係型資料庫儲存格式靈活、速度快、擴充套件性高、且成本相對較低。在很多特定場景下，表現強勁，比如海量寫入，精準讀取，高併發更新，對一致性要求不高等場景。亞馬遜雲科技最典型的非關係型資料庫是 DynamoDB，它的擴充套件幾乎沒有上限，且能夠避免資料集增大導致效能下降，海量資料集下依然可以保持毫秒甚至微秒級的響應時間。不僅如此，DynamoDB 還採用了無伺服器架構無需硬體配置、軟體補丁或升級就可以自動化擴充套件或縮減、連續不間斷地備份資料。
除常見的關係型資料庫和非關係型資料庫，還存在一些其他型別的資料庫，如記憶體資料庫，文件資料庫、圖資料庫、時序資料庫等，也都擁有各自適合的應用場景。呂琳一一為大家進行介紹。
記憶體資料庫：如 Amazon ElastiCache 或者 Amazon MemoryDB 等。這類資料庫可以保證資料不丟失，通常來說，Redis 的複製技術是非同步複製，可能會丟失一部分資料，但採用記憶體資料庫 Amazon MemoryDB 則不存在資料丟失的情況。
文件資料庫：如 MongoDB、Amazon DocumentDB 等。MongoDB 在中國區的接受度很高，很適合直接儲存 JSON 資料，因此，遊戲、直播等行業會天然地傾向採用它。但 MongoDB 免費版很難做到高可用，而收費版費用又很高，相比來說，Amazon DocumentDB 提供更強大的高可用和可擴充套件能力。
圖資料庫：如 Amazon Neptune，圖資料庫屬於比較新興的資料庫，主要用以記載不同事物間的相互關係。在社交網路、知識圖譜、生命科學等場景比較常用，此外在欺詐檢測、疫情防控的背後，圖資料庫也發揮了重要的作用。
時序資料庫：如 Amazon Timestream，時序資料庫主要用於處理帶有時間標籤的資料，主要運用於保險、電力、化工等行業，進行各類實時檢測、監測與分析。Amazon Timestream 提供快速、可擴充套件、完全託管的服務，與關聯式資料庫相比速度快 1,000 倍，成本僅為 1/10。
所謂尺有所短，寸有所長。因此，各種各樣的資料庫，只有在自己適合的場景，才能夠發揮最大的價值。
03 面向現代化應用的高可用、可擴充套件 NoSQL 資料庫
雖然資料庫的種類繁多，但大體一般可分為兩類，一類是傳統的 SQL，另一類是比較新興的 NoSQL。呂琳強調，這兩種資料庫並非互相替代的關係。如果需要大量 joins 或者靈活的即席查詢，那麼 SQL 一定是不二的選擇。但是，如果需要海量擴充套件、低可預期的延遲和靈活的 schema，那麼 NoSQL 才是更優的選擇。
在非關係型資料庫中，呂琳著重介紹了 DynamoDB 的基礎及最佳實踐，後續的動手實驗也是圍繞這款資料庫展開。
2007 年，亞馬遜 Dynamo 論文的發表，為後來一系列 NoSQL 理論與產品的發展提供了啟發，鋪平了理論的道路，很多 NoSQL 產品都參考了 Dynamo 系統。2012 年，DynamoDB 正式誕生。這是一款完全託管的無伺服器型別的 NoSQL 資料庫。用以解決資料庫管理、效能、可擴充套件性和可靠性等核心問題。具有很高的可擴充套件性、可用性和健壯性，適合儲存大量資料並且同時要求低延遲的應用服務。DynamoDB 提供全託管服務且操作簡單，以至於在開發者中流傳著這樣一句話“使用 DynamoDB 你什麼也不用管，只需要記得付賬單就可以了。”很多頂級企業都是 DynamoDB 的使用者，國外有 Netflix，國內如華米、隨銳。
DynamoDB 的核心元件是表、專案和屬性。表是專案的合集，專案是屬性的合集。DynamoDB 使用主鍵來表示表中的專案。分割槽鍵用來構建一個非排序的雜湊索引，使得表可以進行分割槽，從而滿足擴充套件性的需求。在一個分割槽鍵決定的雜湊索引裡，資料按照排序鍵進行排列，每個排序鍵所對應的資料行數沒有上限，除非你有本地二級索引。
本地二級索引 (LSI) 可以選擇與表不同的排序鍵，每個表分割槽對應一個索引分割槽。每個分割槽鍵可以儲存最多 10 GB 的資料，包括表分割槽和索引分割槽的資料量。
除本地二級索引，另外一種索引方式是全域性二級索引 (GSI)。全域性二級索引可以選擇與表不同的分割槽鍵以及排序鍵，且每個索引分割槽會對應所有的表分割槽。
GSI 和 LSI 該如何選擇呢？對於 GSI 來說，索引尺寸沒有上限，讀寫容量和表是獨立的，只支援最終的一致性。而對於 LSI 來說，索引儲存在表的分割槽中，每個分割槽鍵值的儲存上限是 10GB，使用的是表上的 RCU 和 WCU。
使用 DynamoDB 除了需要指定主鍵、分割槽鍵和排序鍵外，使用者只需確定訪問次數，系統會根據訪問次數預置容量。不僅如此，DynamoDB 還擁有獨特的 Token Bucket 演算法，可以將剩餘的 RCU 儲存下來，以應對突如其來的流量洪峰。
對於 NoSQL 來說，一個比較常見的問題是訪問不均衡的問題，而 DynamoDB 特有自適應容量（Adaptive Capacity ）功能，增加過熱分割槽的吞吐量，對過熱專案進行隔離。此外，DynamoDB 還提供預置容量自動伸縮和按需擴容等功能在保證容量的基礎上，最大限度降低企業成本。
分享的最後，呂琳介紹了四個有關 DynamoDB 設計最佳實踐，分別為：
● 慎重選擇 Hash Key 以實現無限擴充套件
● 如何儲存大專案
● 如何處理熱點專案
● 使用 Time-Series 表格儲存時序型資料
04 動手實驗環節
“紙上得來終覺淺，絕知此事要躬行”呂琳老師的分享讓現場的開發者對現代化資料架構有了初步的認識。隨後，開發者們在李君老師的帶領下，開始了動手實驗環節。本次 Build On 共設定兩個動手實驗。
動⼿實驗⼀ 使⽤ Amazon DynamoDB 為移動應⽤程式設計資料庫
動手實驗一假設開發者正在構建一個用來上傳照片的移動應用程式。使用者將通過開發者開發的應用程式上傳照片，其好友可以檢視他們的照片。這個應用程式是一個社交應用程式，因此使用者可能會查詢和關注好友。關注好友後，使用者將收到好友釋出新照片的通知，並能夠向好友傳送訊息。開發者設計的應用程式要能夠滿足使用者使用愛心、笑臉、豎起大拇指、戴墨鏡四種表情符號對照片做出表態的需求。
通過這個實驗，開發者學習瞭如何對 DynamoDB 表進行建模以處理應用程式的所有訪問模式，並瞭解瞭如何使用新的事務處理功能，從而快速高效地使用 DynamoDB。
動⼿實驗二 使⽤ Amazon DynamoDB 對遊戲玩家資料建模
除應用於社交場景外，DynamoDB 也是遊戲場景頗受歡迎的資料庫服務。動手實驗二假設開發者正在構建一個有 50 名玩家同時線上的大逃殺遊戲。遊戲時間通常為 30 分鐘左右，在遊戲中，開發者必須更新某特定玩家的記錄，以指明該玩家玩遊戲的時長、創紀錄的殺敵數量或者是否獲勝。滿足使用者想檢視他們玩過的遊戲、遊戲獲勝者或者想觀看每場遊戲動作重播的需求。
通過該實驗，開發者們進一步瞭解了一些核心資料建模的策略，以及如何在遊戲及其類似場景中使用 DynamoDB 構建現代化資料架構。
你是不是也想試試呢？未能親臨現場參與本次活動，並對 DynamoDB 資料庫感興趣的開發者可掃描下方二維碼註冊賬號並領取禮包，實操上述兩個動手實驗
點選閱讀原文即可下載本期 Build On 上手實操手冊，快來親自動手學習\複習課程內容吧~
掃描上方二維碼即刻註冊
