1. 程式人生 > 其它 >從TDSQL,看分散式資料庫的技術之美

從TDSQL,看分散式資料庫的技術之美

導語 | 每一個時間段總是一個新時代,新技術層出不窮使得資料庫技術煥發新生。Spanner、CockroachDB、TDSQL等分散式資料庫正是這個時代的弄潮兒。本文由騰訊雲資料庫專家工程師 李海翔在 Techo TVP開發者峰會「資料的冰與火之歌——從線上資料庫技術,到海量資料分析技術」 的《分散式資料庫的演進》演講分享整理而成,帶大家品味分散式資料庫架構、前沿技術和TDSQL技術實踐,感受分散式資料庫的技術之美。

一、分散式資料庫架構
我今天所分享的內容主要集中在資料庫技術層面,和騰訊近十年的分散式資料庫技術發展息息相關,主要有三方面:第一是分散式資料庫的歷史發展和演進;第二是分散式資料庫裡較核心的技術內容,包括相關的內容知識點;第三是騰訊TDSQL在前沿方面所做的工作。TDSQL是一個基於HTAP的分散式資料庫系統,尤其強調強一致。2017-2018年我們提出過“全時態資料庫”的概念,當時提出實現了一個叫做HTAC的混合事務分析處叢集架構,HTAC和HTAP非常接近,在工程方面我們稱為HTAC,用一個理論的名詞來概括就是HTAP(混合事務分析處理系統),所以在那時我們就已經推出自己的原創性產品,而這個產品這兩年的演化一直專注於強一致性,在去年我們推出了兼具理論與實踐的產品,清楚解釋了“強一致”這個概念。該技術對應的產品,內部經過一段時間打磨後,載有該項技術的TDSQL將在TDSQL公有云等產品中很快推出。

  1. 分散式系統經典架構概述
    先來看第一部分,分散式資料庫的發展演進。這幅圖在說明什麼?裡面在談一些基礎架構:Shared Nothing、Shared Memory、Shared Disk、Shared Everything。這些是什麼?最早從哪裡來?硬體層面是做軟體的基礎,硬體層面的發展決定著軟體技術的發展,硬體層面把一些基本的框架搭好後,資料庫的軟體或者說應用層、系統層的軟體都會在上面疊加,就像搭積木一樣,一塊一塊地往上壘。對於資料庫內部其實也是這樣的,分模組、分層次,之後這些東西都可以搭建在一起。但是資料庫有著緊耦合性較強的特點,搭在一起後就很難拆開,但是現在做分散式資料庫的一個趨勢是要嘗試把這些東西拆分,再像搭積木一樣往上壘,哪個地方需要什麼樣的元件,就去建設這樣的元件,模組與模組之間要解耦,解耦之後更易搭建,把這個系統搭得在將來更具擴充套件性。分散式資料庫系統的底層基礎是和硬體緊密相關的。
    file

  2. 分散式系統架構經典主流技術
    我從技術的角度展示一下資料庫的代表技術。在這幅圖中,第一個人是資料庫界圖靈獎的第二位得主——關係模型的創始人科德博士,他在1970年的時候以一篇論文奠定了關係型資料庫的基礎。1974年時有兩個典型的技術誕生,一個是SQL語言,另外一個是事務處理技術。50多年前,資料庫界第三點陣圖靈獎得主James Gray開始研究事務處理,並對得到了一系列的開創性的成果,所以事務處理奠基於70年代,直至今日。同年,IBM同樣誕生了一個開創性的技術,就是我們所熟知的SQL,SQL這個概念是從IBM在做資料庫的研究起就開始提出的結構化查詢語言。
    file

再往後,是ER模型,ER模型是實體關係模型,能夠幫助我們做資料庫應用的建模。

但是,在資料庫技術的發展過程當中出現了很多模型,包括前面說的1970年之前的關係模型、層次模型,再往前的網狀模型,這些模型和ER模型產生的初衷是一樣的,都是要從資料、資料層次的角度與實體世界進行對映,以讓資料世界具備表達、計算實體世界的能力。只不過ER模型在發展過程中只被人們用於了關係建模(教科書擷取了精華展示,讀者的理解程度不再能全面深刻),但它背後包含的內容其實和關係模型、層次模型是相同的,如果我們回顧歷史還原其初衷,則能從歷史當中看到的一些基本的東西。

到了1980年,資料庫界出現基於代價的查詢優化技術,它能夠較好的選出一個近乎最優的執行計劃。此後,資料庫又演變出了基於火山模型的執行器,推動資料庫的技術進一步發展。從這副圖中可以看出,資料庫技術發展基本上是從沒有事務到有事務概念這條主線上推進的,到了1993年的時候有了AP和TP的分叉,這歸功於科德博士,他除了提出關係模型,又提出了OLAP的概念——線上分析事務處理,以前的主線就變成了OLTP和OLAP兩條分支。

隨著時光的繼續推移,2014年,有意思的事出現了,一個並不是學術研究機構而是對行業的研究機構——Gartner,推出一個概念:HTAP,期望在事務型的系統上增強分析的功能。這個概念這幾年大火,似乎在補救事務型資料庫的重事務處理弱分析能力的缺陷(概念分家,指導思想發生變化,看來還是有壞處的)。人們總是有一個美好意願,在一個系統內搞定所有的事情。這同人類的需求和不斷變化的認知存在關係。

但在這之前,2012年穀歌的Spanner系統誕生了,它標誌著人們從不要SQL到擁抱SQL擁抱資料庫的事務處理技術,演變成了New SQL系統。

file

前述這些技術,是資料庫的經典技術,無論單機資料庫還是分散式資料庫,都基於這些基礎性的技術。雖然TDSQL是一個分散式資料庫,但裡面90%甚至更多的基礎核心功能來自於單機資料庫系統,所以技術的演進其實是踏著前面的基礎而不斷演化的,分散式資料庫的技術離不開前面我們談到的關係模型、事務處理等基礎技術。因此我認為做分散式資料庫離不開單機資料庫系統,認識分散式資料庫要先從單機資料庫系統入手,單機資料庫系統實際上就有了分散式資料庫的五臟六腑,它已經比較全面。只是分散式資料庫在基礎技術之上,因系統架構的變化,有了一些新挑戰。

下面,我們以MySQL的資料庫系統架構為例,來分享單機資料庫系統包含了哪些模組和元件。
file

左上角的SQL是一個入口,它執行完的結果在這個箱子裡轉了一圈後將結果返回使用者,進入到資料庫系統裡。左邊的是MySQL Server,右邊是它的儲存引擎,實際上整個資料庫可以分為三層:左邊的Server,右邊的儲存引擎,儲存引擎下面和作業系統緊密結合的是和外部檔案相關的一部分內容。Server在接收使用者的SQL語句並解析,就像編譯器,對於SQL語句做解析得到一棵語法樹,這棵語法樹經過查詢優化器的轉換變成邏輯查詢計劃,再變成物理查詢計劃,過程中會做很多優化,就像子查詢優化,表示式怎麼去重、化簡等工作。再往後它就要交給執行器去執行,執行器實際上和儲存系統是緊密繫結的,儲存系統的兩大部分,一部分是執行器,各種SQL語句的執行,DDL、DML、DQL等,它的執行過程當中又受到橫向的事務處理與它正交的組合,在事務處理系統的控制之下,各種SQL語句高併發地執行,並經過各種模組。

模組從底層往上看,資料庫系統最底層的是一個檔案,因為它要存在作業系統上,而作業系統上是以檔案為單位來組織資料的,所以大家可以看到最底層的是一些物理檔案,物理檔案有它的格式,格式上就有資料庫自己定義的各種資料格式。資料可以分為兩部分,一部分是使用者資料,一部分是資料庫系統自身要維護的日誌資料,資料可以讀入寫出有物理的IO產生,其要和儲存引擎,也就是執行器加儲存系統打交道。資料被讀入後進入記憶體,不同的資料庫有其自己特定的資料格式,這需要access解析格式,初始面對的是一個一個物理頁面,把它們先載入到快取區裡,然後做格式的轉化,物理頁面被解析成一個一個的記錄和列,便於上層對它進行計算。當這些解析完成後,比如有兩個客戶端連進來,那就有讀寫同樣資料的可能,因此有併發存在,就可能會產生資料異常,事務處理系統這時候就要發生作用——避免資料異常、保證資料的一致性,經過計算之後再把結果通過SQL Server向上返回。作為一個分散式資料庫系統而言,它離不開這個執行過程,也離不開這裡面所包含的基礎模組和元件。

資料庫系統是發展和逐漸演進的。實際上早期做單機資料庫的大家都熟悉主從架構,MySQL的主從架構是基於邏輯和物理混合的,但更多是偏向邏輯地做主從架構的資料傳輸。而後純粹的單機資料庫系統推進了一步,成為近似於分佈的,物理節點已經變成多個,但是一主多備,多備只能去做讀,還不是純粹的分散式資料庫系統,所以資料庫系統實際上架構的發展分成兩代,第一代是純的單機系統,第二代是分散式系統,介於第一代和第二代之間就有這麼一個過渡性的階段,我把它稱之為1.5代,但是它還歸屬於單機資料庫系統,所以有了這樣一個主從架構。典型的每一個數據庫都做了基於物理日誌的,像Oracle、PG流複製等,但MySQL基於邏輯日誌這樣的格式去做主從結構的。

時光推移到七八年前,亞馬遜的Aurora系統誕生,它本質上還是主從架構、一主多備式的,進步的地方在於做成了一個雲上的存算分離的系統。所以1.5時代的產品,典型的代表是類似於早期的主從+Aurora這種架構,這是一個過渡時代。再往後我們會進入到真正的分散式資料庫時代,它典型的標誌是什麼?是多寫,在每一個節點上都平等地對待,可以在每一個節點上寫,這裡面的技術就又有多種,有的是偽的分散式,其把事務的所有寫操作集中在單一的節點上去做,真的分散式是利用分散式併發訪問控制演算法,在每一個節點上去做資料一致性的保障。
file

小結
資料庫基本架構的演進就是經歷了這麼一個過程,總結一下,反過來從技術角度來看究竟是什麼因素在推動分散式資料庫系統的演進。其實資料庫系統有一些內在的、本質性的需求在推動它,我們以前說資料庫系統裡面有“三高一易”,高可靠、高可用、高效能、易用性等等,這些基礎因素在推動著分散式技術不斷地向前發展,到後來演化成分散式資料庫系統的時候,對於水平擴充套件的要求提上日程,所以我的第一個總結是針對擴充套件,不僅是垂直擴充套件,而且要水平擴充套件,所以對於擴充套件性下的多讀多寫場景,使得分散式資料庫的結構變成純粹的每一個節點都是對等的結構。在分佈系統裡要講究可用性,包括資料層面的可用如共識協議下的資料多副本機制、也包括整個系統功能層面的可用。如果以較少的投入獲得高的效能,那就可以對外支撐更多的業務,成本就會更低。所以對於資料庫內在原生的要求從單機資料庫系統到分散式資料庫系統一直沒有發生過變化。

最後,分散式資料庫的挑戰、問題在哪裡?我以一個目錄結構列出了這些內容。該目錄結構分為兩部分,左面部分是資料處理技術其自身對資料庫的內在驅動需求,右面部分是基於資料庫所處的外部環境對於資料庫的驅動因素。大家可以觀察目錄所列的這些基本因素,以瞭解分散式資料庫的相關技術點。資料庫內在的需求其實有分散式和儲存架構相關的,資料分佈、儲存管理、多副本、存算分離、多讀多寫、查詢優化、MPP。這個思路其實和我剛才所分享的脈絡是一脈相承的,又和高可用、和事務處理相關,這些都是分散式資料庫的內在需求,驅動著資料庫技術繼續不斷地前進。

file

從外面的來看,新硬體、智慧資料庫、雲端計算,這些是計算對於資料庫系統的要求;HTAP,還有下一代所謂的New SQL,資料庫也在不斷地演進,此過程中還會產生一些新的技術和內容。所以做分散式資料庫,大部分就是基於單機資料庫系統,再做一些和分散式相關的事。分散式相關的事情大概是我前面提到的那些主流技術,這張目錄結構把沒有包括的基本核心內容都包含了。

其中,特別說明一點,是去中心化。做分散式資料庫一定要考慮去中心化,也就是各個節點之間是對等的,考慮一個併發訪問控制演算法的時候,這個演算法是不是去中心化的?它們之間的關係是不是對等的?都是要考慮的。