編者注：
中國的資料庫行業也迎來了一波新的熱點事件。分散式資料庫這塊新訊息不斷，也讓大家開始關注中國的分散式資料庫。首先是短短一週內，Pingcap和SequoiaDB巨杉資料庫陸續宣佈了C輪的數千萬美元融資，融資的訊息在資料庫和IT圈成功“刷屏”。此後，在杭州的雲棲大會上，螞蟻金服的Oceanbase也釋出了 2.0。對於這些新訊息，也側面反映了國產的開源分散式資料庫發展的迅速。那麼這些國產分散式資料庫，在網際網路行業中的實踐與使用上是如何呢？與傳統開源資料庫的對比如何？就由這篇文章作為去哪兒網這邊的實踐介紹。
引言：開源資料庫百花齊放新時代
MySQL目前是全球最流行，使用者最多的開源資料庫這是無可非議的事實。而同時，開源資料庫PostgreSQL也一直在不斷髮展壯大，當然還包括眾多的新一代NoSQL、NewSQL資料庫不斷湧現。
此前，本人有幸參與“MariaDB/MySQL vs PostgreSQL世紀大決戰”，現場火藥味十足。作為為MySQL戰隊的一員，我個人認為，“大決戰”可能並不準確，更多的應該是碰撞，因為有史以來，在資料庫界，兩家不同資料庫被擺到臺上公開對標，他們應該是第一次走得這麼近，我擔心的是，這樣的現象以後還會不會出現。
其實技術本身都是好的，我個人認為，我們應該本著“百花齊放、百家爭鳴”的態度來學習，來使用。如果沒有PostgreSQL，也許MySQL不會有現在這麼好的口碑，當然反過來，如果沒有了MySQL，PostgreSQL也亦因為找不到對手而感覺孤獨不少。一家是“The world's most advanced open source database”，另一家是“The world's most popular open source database”，他們本來就應該相互學習，相互進步，所以這樣的“碰撞”，以後應該還會再有，期待下一屆“開源資料庫大會”的到來。
MySQL是否是唯一選擇？
現在的事實是，MySQL確實如其所述，是“most popular”的開源資料庫，而PostgreSQL確實做到了“most advanced”，這點在“世紀大決戰”中也體現的淋漓盡致，做為“most advanced”的資料庫PostgreSQL，難免顯得有點高(級)冷(清)，因為相比“most popular”的MySQL而言，使用者確實少多了。MySQL在“popular”方面，做得確實不錯，非常成功。因為正如大家所看到的，只要用到了資料庫，絕大多數都會考慮MySQL，因為這個問題還是和我的觀念比較契合的，所以我認為，任何結果，都是有其深層次的原因的，MySQL的popular，原因可能有以下幾點：
1. 開源，這個可能無需多提，這個相比PostgreSQL，他沒有優勢，因為PostgreSQL也是開源的。
2. 簡單，MySQL入門可以說是非常簡單的，這個大家應該都有感受，只要想用資料庫，除了使用access之外，MySQL可能就是不二之選了。
3. 外掛式，外掛式也是兩面性的，一方面限制了他的發展；另一方面，靈活，功能強大，因為有很多外掛可以自己選擇，應用自如，而使用者看重更多的是後者。
4. 先入為主，在PostgreSQL想要流行起來的時候，MySQL已經流行起來了。
5. 網際網路大公司推動，在去O大潮中，因為上面的原因，大型網際網路公司的推動，首選的是MySQL，導致了MySQL的快速發展。
原因有很多，現在的結果是，MySQL確實太火了，並且再加上MGR的出現，“用MGR完事”，也許真的是這樣。
但MySQL也有其缺點，那就是他的儲存都是單點。這當然也是大型通用資料庫的通病，一般都需要通過多點冗餘來實現資料的高可用、高效能，但如果資料量再大了，即超出單盤容量（目前PCIe SSD卡最大容量達到12.8T）之後，MySQL可能就出現瓶頸了，當然這也是有解的。
我們去哪兒的解決辦法，通常都是在業務上面拆分，比如總資料量是20T，那就拆10個叢集，每個叢集都是2T的資料量，這樣就可以解決儲存的問題了，當然這都是從業務邏輯上面解決的，需要加上路由表來控制資料的儲存節點位置。這樣的解決辦法，雖然可以解決問題，但是當下可能更多人想要的是一個更advanced的解決方案，即現在很火的分散式資料庫。
理想中的解決方案是，我們無需關心資料儲存，我們只需要向一個節點上寫入，或者從一個節點上讀取即可。不但資料量可以為任意大小，當這個節點掛了，我們還可以隨時啟動另一個節點“頂上”即可實現故障轉移，這樣就實現了真正的“雲端儲存”。在這樣的“雲端儲存”中，我們不需要關心其高可用、多副本、容量、效能等問題，也不需要關心是不是存在多點寫入，讀寫節點可以隨時擴充套件，也許這樣才是我們心目中的分散式。
所以從這點來看，MGR還是存在單盤的問題，並不能解決資料量極大情況下的分散式問題。
分散式資料庫
那有沒有比較好的，類似我們心目中的分散式資料庫呢，我想是有的，至少是向這個方向在走。去哪兒網也一直在探索，所以我的要求基本有以下幾點：
1. 要相容MySQL，因為本人就是MySQL重度研究與使用者，高度認可MySQL這個資料庫的架構及使用方式等（中毒已深）。相容MySQL這個要求，其實是非常高的，我們每個人都知道。只是MySQL的語法比較亂（說到程式碼實現，可能更多的是罵了），很鬆散，如果說做到了90%的相容度，那是不夠的，最好要做到100%，這能做到嗎？我想是可以的。
2. 儲存率高，使用分散式資料庫的業務，大部分應該是儲存分析型，如果使用了分散式資料庫，還需要佔用太多的硬體資源，且儲存不了太多資料的話，那這個在成本上就非常高了，得不償失。
3. 有健全的圈子，使用中難免會碰到問題，碰到問題的時候，現在處於分散式發展的初級階段，所以社群的人比較少，而只能去求助官方，如果官方不能提供幫助（也許是沒給錢），那這樣的資料庫，可能就不具有誘惑力了，風險太大。
4. 效能夠用，在使用了分散式資料庫之後，其實已經預設接受了降低效能要求的條件，所以我們的要求只是說，效能夠用即可，不會去和單點MySQL去比，因為沒有意義。夠用就好，當然在這方面如果足夠好，那是再好不過了。
5. 少技術棧，這樣的需求是非常高的，因為技術棧太長，會加重運維人員的成本，並且在現在這樣人才難找更難招的情況下，這樣的願望是更迫切的。
符合這樣要求的分散式資料庫有嗎？
最近在開源資料庫大會上向開源社群做出分享的SequoiaDB巨杉資料庫，這個名稱應該是比較熟悉了，他們已經做了很多年的分散式資料庫，只是最近才出現在了MySQL社群。其實一個很重要的原因就是，他們終於想清楚了，或者說意識到了MySQL的重要意義，所以他們也與MySQL保持了親密關係，或者更準確的說，巨杉資料庫，成為了MySQL圈內的一員，屬於真正的MySQL體系。
SequoiaDB巨杉資料庫
根據官方網站介紹，巨杉作為中國資料庫產品，技術上，SequoiaDB的3.0版本採用了計算-儲存分離的架構，這一架構是的SQL和儲存引擎實現了鬆耦合，在資源分配和通用性上優化空間更大。其中，SequoiaDB的資料儲存引擎是巨杉完全自研的分散式JSON資料儲存引擎，是完全從零開始自研的。而資料庫所有的資料管理、分散式控制、事務、ACID功能支援等都是在SequoiaDB的分散式儲存引擎裡完成的。SQL層，目前SequoiaDB通過聯結器（sequoiasql-mysql）直接使用了MySQL的原生解析器，實現MySQL的完整相容，同時目前也支援PGSQL和SparkSQL。
1. 為什麼說巨杉資料庫屬於MySQL體系內呢？因為他做到了一點，就是100%相容了MySQL的語法，更準確的說，他成為了MySQL的一個外掛，說到外掛，我想每個人都熟悉，因為你不會覺得MySQL外掛不是MySQL體系內的。所以這點完全滿足了我的第一個需求，作為一個MySQL工作者，最喜歡看到這樣的場景了；
2. 儲存率方面，巨杉資料庫，只需要三個節點就可以了；
3. 在健全的圈子方面，我想，巨杉做為一個MySQL的外掛，這個圈子夠大了，因為MySQL Server層的問題，我們自己就可以解決，僅剩下的巨杉資料庫本身，那可能就需要去不斷的學習與分享了，但至少少了很多問題；
4. 效能方面，我們已經測試過，在只向一個IP埠讀寫（資料沒有分割槽，sdb只有一個節點）的情況下，效能基本是MySQL單點的三分之二，這是可以接受的，因為做為分散式資料庫，這樣的使用方式，必然是比不上單點MySQL的，這裡重點在測試效能損失多少，如果想提升效能，則可以增加分割槽，或者增加協調節點等方式來實現，從而可以做到最大限度的發揮他的分散式優勢；
5. 技術棧方面，這個和MySQL還是脫不了關係，對於Server層，輕車熟路，巨杉儲存引擎，也只是幾個獨立程式，架構清楚簡單，維護起來不會有太大困難。
巨杉資料庫架構設計詳解
上面是巨杉資料庫的架構圖。這裡涉及到多個模組，下面分別做一個解釋：
1. 協調節點：用來做資料的路由的，他的作用更像一箇中介軟體，他會根據資料訪問的KEY，以及編目節點，來確定資料的儲存位置。可以有多個協調節點，用來提供更高的效能；
2. 編目節點：用來儲存路由資訊的，與資料節點配合，可以最終定位資料；
3. 資料節點：用來儲存資料的；
4. sdb plugin：這就是MySQL外掛，巨杉資料庫，本身與MySQL沒有任何關係，但MySQL通過這個外掛，實現了所有訪問資料的介面，二者這才建立了關係，所以sdb plugin更多的是一個介面卡。MySQL Server與巨杉資料庫的協議轉換器。
從架構上來看，這真正的實現了MySQL的雲化儲存方案。此時的MySQL Server，自身不會儲存任何內容，其作用更多的被轉化為一箇中介軟體了。
做為一個儲存引擎，在建立一個表的時候，還需要遵守MySQL本身的規則，比如還需要建立一個frm檔案。其實個人認為，這個frm檔案，和巨杉資料庫中對應的表沒有強關聯，它只是為了“騙過”MySQL Server，讓其知道，這個表是存在的，可以正常訪問這個資料庫，那麼在騙過MySQL Server之後，就會走到儲存引擎層的訪問。
在順利通過了MySQL Server的各種考驗之後，就到了儲存引擎的訪問，因為巨杉實現了所有的儲存引擎與Server層的介面，所以儲存引擎的訪問，就會順利訪問到巨杉的sdb plugin，比如取一條資料、寫一條資料、帶條件的取資料（MySQL5.6中新增的condition push down特性）等，只要能順利將Server請求的介面返回正確的資料，那Server層就會正常的處理這些資料，最終返回給客戶端。
MySQL+SequoiaDB整體架構示意
在將資料或者請求傳給巨杉儲存引擎之前，或者將資料從儲存引擎返回給Server層的時候，這些所有的操作，與巨杉是沒有關係的，這完全是MySQL Server層的工作，這些工作包括語法分析、語義分析、查詢優化、MDL鎖、資料庫許可權、如果開了複製，則還會包括主從複製等等，當然還包括我們經常運維的一些命令，比如show processlist; information schema; MySQL庫資訊的查詢。基於這些熟悉的特徵，這樣的實現方式，給我們非常大的誘惑力。
從上面實現原理來看，從MySQL Server，到巨杉資料庫，架構應該是如上圖所示的，sdb plugin本身沒有儲存資料，所以其角色轉換為一個輕量級的中介軟體了，由sdb plugin來轉發應用的請求到協調節點，到這裡，就是巨杉資料庫的天地了，我就不再贅述了，我這裡重點要講的是本身架構的問題。
現在把MySQL Server理解為中間層，最好的架構方式就是，有多套MySQL server在執行著，應用可以隨便訪問任意一套，這樣有以下幾點好處：
1. 可以增強讀寫效能。
2. 可以實現讀寫分離。
3. 可以實現故障轉移
4. 支援多點寫入功能，在故障切換時，隨便切換無影響。
但多套中間層的情況下，就存在一個問題，即配置的同步問題，在這套架構中，配置指的更多的是其後設資料，比如表結構，也就是用來“騙過”MySQL Server的表結構，因為如果這些資訊在多個節點之間不能同步，首先MySQL Server這層就不能順利通過，也就無法訪問巨杉了。
這個問題目前的解決方案是，巨杉提供了一個指令碼，通過MySQL Server的審計功能，訂閱MySQL Server層的DDL操作，這樣在有後設資料變更的時候，自動同步到其它MySQL Server中，這樣也就實現了後設資料的同步功能。這樣實現，既熟悉，又無奈，因為這是MySQL，外掛沒有辦法提供這樣的介面來同步後設資料，只好這樣實現了。不過對於MySQL足夠熟悉時，這樣的實現也不失為一個好辦法。
我們進一步將這個架構完善一下，如下圖：
在多個MySQL Server（中間層）前面加上一個Keepalived，將VIP繫結在Server上，如果有一個down了，Keepalived會自動切換到活著的Server上面，實現了自動故障轉移。當然也可以不加這層，由業務自行去輪迴圈判斷死活來訪問MySQL Server也是可以的，因為使用Keepalived的話，存在一個問題就是VIP切換，在正常維護的時候，也會影響到業務，所以可能會產生這麼一點點的不友好。
當然，如果想做到在正常維護時對業務無任何影響的話，還是再次演進，方案如下：
這種情況下，如果MySQL Server正常維護，只需要在通用中間層中做配置，讓維護節點下線，這樣流量就不會再路由到這個維護節點了，等所有操作執行完之後，就可以正常維護了。或者如果掛了，哨兵會發現其狀態變化，哨兵會連線到通用中間層上面，做配置更改，然後就可以實現故障轉移。
不過這種架構其實沒有什麼太大必要，因為這個時候，MySQL Server非常輕量級，並且其作用已經成為了一箇中間層的角色，只有在其所在機器需要關機的時候，或者某些MySQL的引數是隻讀的情況，但又不得不修改的時候才會去維護，影響並不會太大。
至於巨杉本身架構中，很多節點的高可用如何實現故障轉移，我想這可以更多的參考他們的實現原理，拒我所知，其內容使用了raft類似的演算法，做選舉判斷狀態等，這些都是目前主流的分散式實現方法，應該是足夠可靠了，這裡不再做過多贅述了。
測試情況
小結
1. 不支援自增列，自增列在MySQL中用得比較多，但實際被使用時，都是一個無意義的列，並沒有在業務邏輯中使用，但由於他的自增屬性，導致很多業務程式在寫SQL的時候，都不會指定這個列的資料，所以對自增列做了強依賴，所以目前巨杉還沒有支援這個屬性的列，在新業務上面問題不大，對於老業務的遷移，可能在相容性上面還不夠好。不過交流之後，官方聲稱在幾個月之內可以上線。
2. 後設資料同步 ，之前已經提到過了，只能說是不完美，功能是有了。
在經過功能和效能的測評之後，SequoiaDB已經滿足了我們的要求，我們也將會在近期在合適的場景進行上線使用。
MySQL的未來肯定是光明的，我希望有更多的開源軟體能加入到MySQL這個圈子裡來，一起碰撞，一起共享，一起成長。我們也希望巨杉資料庫可以很快的建立起一個分享技術的圈子，可以讓更多人在開源的社群內受益。
王竹峰：去哪兒網資料庫總監，中國計算機行業協會開源資料庫專業委員會常務理事。擅長資料庫開發、資料庫管理及維護，一直致力於MySQL資料庫原始碼的研究與探索，對資料庫原理及實現有深刻的理解。曾就職於達夢資料庫，從事多年資料庫核心開發工作，後轉戰人人網，任職高階資料庫工程師，目前在去哪兒網負責MySQL原始碼研究與運維、資料庫管理和自動化運維平臺設計開發及實踐工作，是Inception開源專案及《MySQL運維內參》的作者，也是國內少數幾個MySQL方向的Oracle ACE之一。
SequoiaDB下載地址：download.sequoiadb.com/cn/
SequoiaDB GitHub開源地址：github.com/SequoiaDB/S…
SequoiaDB MySQL相容專案GitHub開源地址：github.com/SequoiaDB/s…