前言

IT時代的縮影基本被CPU、作業系統、資料庫這三大核心領域，支撐了半個世紀人類的商業科技文明。本文講到美團點評資料庫的演變，首先從資料庫的簡史講起。把資料庫劃分成三個時代，分別就是關係型資料庫時代，NoSQL時代，NewSQL時代。下面分別講下每個時代資料庫發展的訴求和過程。

• 關係型資料庫時代

說到關係型資料庫，就要從1970年E.F.Codd的《A Relational Modelof Data forLarge Shared Data Banks》的論文開始講起。該論文奠定了關係模型的理論基礎，Codd的同事DonChamberlin對Codd的論文和關係運算進行轉換，發明了簡單易用的SQL語言，並且在之後的發展中成為所有關係型資料庫的標準。這種高階的非過程化程式設計介面語言，成為了距離資料庫最近的語言，將電腦科學和人類理解認知完美的銜接在了一起。

1970 年關係模型建立之後，IBM公司在SanJose實驗室增加了更多的研究人員研究這個專案，這個專案就是著名的System R。該專案結束於1979年，完成了第一個實現SQL的DBMS。

1973年加州大學伯克利分校的Michael Stonebraker 和EugeneWong利用System R已釋出的資訊開始開發自己的關係資料庫系統Ingres。LarryElision和他的同事看到商機，開發出第一個商用大型關係型資料庫Oracle（之後將近半個世紀Oracle一直都是關係型資料庫的領頭羊），之後IBM也推出了DB2、MichaelStonebraker開發了Postgres並放在BSD版權下，後來演變成了Postgres SQL，87年微軟和Sybase合作，開發出了MS SQL和Sybase。

到了2000年後，另一款明星產品MySQL由於其自由開放、輕量，被google等網際網路公司普遍使用，並逐步進入大家的視野從而火爆起來。

• NoSQL異軍突起

首先NoSQL是一個比較模糊的概念，而且在不同階段這解讀出來的含義也不一樣，網上有一個比較有意思另類解讀（下圖），不同的解讀本身也釋放出NoSQL這個技術的螺旋、搖擺的發展態勢。在本文裡，我們把NoSQL泛指非關係型資料庫。

關係資料庫很強大，但是它並不能很好的適用所有的應用場景。尤其以社交、搜尋為代表的網際網路業務產生海量資料時，關係型資料庫在擴充套件性（需要負責技術sharding來實現）、高昂的表變更成本、高併發容量、寫入延遲等方面都面對很多挑戰。

NoSQL資料庫種類繁多，但是一個共同的特點都是去掉關係資料庫的關係型特性。資料之間無關係，這樣就非常容易擴充套件。同樣NoSQL在海量資料讀寫效能方面，也優勢明顯，同時提供了靈活的資料模型。

NoSQL的產品很多，但引領這顧潮流的主要有Amazon的DynamoDB、google的bigtable，後來Facebook開源了Cassandra，以及基於bigtable設計的hadoop Hbase，bigtabl開源實現的Hypertable，以及支援文件事務Mongodb、普遍用於快取的redis及redis cluster。值得一提的是美團點評內部有一個很優秀儲存系統Cellar，兼記憶體與持久化的分佈。

在NoSQL盛行之初，人們似乎能看到了NoSQL取代關係型資料庫的時代，可事與願違，使用NoSQL需要從應用業務去把關係資料庫重新實現，而且資料庫的功能被向儲存方向進一步弱化。這裡面的一個代表事件就是DIGG採用Cassanrda遭遇失敗，大家重新理解了關係模型的SQL是最方便和資料互動的語言，所以開始妥協，於是大部分NoSQL開始嘗試支援關係資料庫(這時候主流變成了Not only SQL)。可是就又回到瞭如果讓關係資料庫具有擴充套件性、效能這條老路上來，於是忍了很久的另外一批人就重新站了出來，出現了”No，SQL!“的口號，於是NewSQL又粉墨登場。

• NewSQL粉墨登場

NewSQL沒有標準定義，作者認為是要滿足以下幾點：1，可擴充套件性、高效能；2，具有NoSQL對海量資料的儲存能力；3，支援關係型資料庫關鍵特性，比如原子性、一致性、隔離性和永續性等。

分散式關係資料庫並不是新的名詞，未來某一個階段分散式資料庫也一定會佔據資料庫的主導位置，這個相信大家不會有太大爭議，但問題在於它的實現難度，如果在CAP之間進行平衡和彌補，目前這方面的理論、實踐應該說都還在初級階段。

至於NewSQL的起源，我覺得要從Google說起。2011 年，Google 發表了 Megastore 的論文，Megastore是谷歌一個內部的儲存系統，它的底層資料儲存依賴Bigtable（基於NoSQL實現），但它實現了類似關係型的資料庫模型，不同資料中心之間、分片（Entity Group）之間使用Paxos協議複製，跨分片的事務採用兩階段提交。這種支援事務的儲存系統在google內部很受歡迎，但Megastore也有一些噪點，比如延遲比較大，於是google在新的儲存檔案系統Colossus和新的硬體基礎上研發了更大的分散式系統Spanner，它具有可擴充套件、多版本、全球分散式複製。與Spanner配套，google研發分散式SQL引擎F1，實現F1+Spanner的分散式組合。在Spanner的論文引導下，社群也有開源的實現，其中比較有代表的是CockroachDB和國內人氣產品TIDB+TIKV。

分散式的前提需要將儲存進行分片，也很自然的引導了計算與儲存的分離，在加上GBU的發展，使大家可以將更多的計算下推到儲存，並且隨著雲端計算的發展支援，一些大雲廠商開始利用自身的硬體優勢，開始量身設計新一代雲資料庫，引導這種潮流的是AWS的Aurora，Aurora使用一個共享儲存系統來實現資料庫的一致性，依照log is database的理念，最大化的降低了應用的延遲。Aurora後面會單獨介紹，和這個比較類似的還有阿里最新公佈的polardb，據說華為也在做同樣的事情。

美團資料庫架構演變

MySQL架構演變

美團的資料庫架構是一個比較典型的MySQL+NoSQL演變之路， 最初是簡單的M-S架構，讀寫都在主庫上，也是最簡單易用的階段。

後來開始按照重要程度、業務歸屬等維度開始DB拆分，同時進行硬體的升級，主要是SAS->SSD，當然資料庫引入了cache，主要是redis和memcache。

我們會對主要的資料庫根據真實流量進行壓測，來確定拆分的容量尺度。下面用一個案例來說明：左縱座標是QPS（對應藍線），表示吞吐量情況；右縱座標是99%（可配置）的響應時間（對應紅線），表示響應時間；橫座標是當前流量的放大倍數，橫座標淺藍色代表30ms之內的空間（30ms是業務可接受最大的DB響應時間）。通過這個容量圖表，我們可以比較清晰的知道資料庫當前讀流量最大可支援的倍數。

然後開始解決讀寫分離的問題，最早在引入proxy方案前，我們也短暫使用兩個DNS進行分離。

在後來就是分庫分表，當年還覺得Sharding是個挺牛的東西，現在看來全是成本和眼淚。

Sharding後，資料的分發和彙總成了問題，當年的解決方案比較現實，是在APP和DB直接加上一層，爭論在於這一層更貼近誰？下圖是當年做的一些比較。

從DB對應用透明的角度來看，我個人更推薦proxy方案。不過當年在美團內部，兩個方案都存在，一段時間內主流的方案還是proxy，後來因為網路單點及鏈路過多的問題又轉向JDBC層。

其實不管是proxy還是JDBC層，成本沒有多少變，痛點解決了一部分，也同時引入了一些問題：

舉兩個例子，比如一個全域性ID問題，這個方案在公司內部也經過多次演義，嘗試過MySQL自增主鍵、引入redis序列等，各有各的問題；還有業務多維度、AP業務資料同步，美團內部也是重複做過一些輪子，比如canal、databus、佇列方式、pumer等。

美團的NoSQL

美團目前使用比較廣泛的是基於tair基礎上研發的Cellar，這裡我們主要闡述一些基本特性。分散式KV儲存系統，底層支援Leverldb、rockdb、mdb、rdb等引擎，各節點直接通過raft進行復制；支援異地容災、無損資料遷移，元資訊存在單獨節點，並且通過新增observer的形式實現路由查詢能力擴充套件、客戶與中間節點分離。

MySQL與Cellar的主要對比：

最後拋一個問題，如果說MySQL+Cellar≈ 美團主流資料庫架構，那麼頭腦風暴一下，MySQL（server層）+Cellar （儲存層）≈ ？歡迎大家積極討論～

歡迎大家加入雲端計算交流QQ群，群號：469243579 ～