開源分佈式數據庫SequoiaDB在去哪兒網的實踐

編者注：

中國的數據庫行業也迎來了一波新的熱點事件。分佈式數據庫這塊新消息不斷，也讓你們開始關注中國的分佈式數據庫。首先是短短一週內，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/SequoiaDB

SequoiaDB MySQL兼容項目GitHub開源地址：github.com/SequoiaDB/sequoiasql-mysql