導語 | 每個時間段老是一個新時代,新技術層出不窮使得數據庫技術煥發新生。Spanner、CockroachDB、TDSQL等分佈式數據庫正是這個時代的弄潮兒。本文由騰訊雲數據庫專家工程師 李海翔在 Techo TVP開發者峯會「數據的冰與火之歌——從在線數據庫技術,到海量數據分析技術」 的《分佈式數據庫的演進》演講分享整理而成,帶你們品味分佈式數據庫架構、前沿技術和TDSQL技術實踐,感覺分佈式數據庫的技術之美。
點擊可觀看精彩演講視頻html
我今天所分享的內容主要集中在數據庫技術層面,和騰訊近十年的分佈式數據庫技術發展息息相關,主要有三方面:第一是分佈式數據庫的歷史發展和演進;第二是分佈式數據庫裏較核心的技術內容,包括相關的內容知識點;第三是騰訊TDSQL在前沿方面所作的工做。TDSQL是一個基於HTAP的分佈式數據庫系統,尤爲強調強一致。2017-2018年咱們提出過「全時態數據庫」的概念,當時提出實現了一個叫作HTAC的混合事務分析處集羣架構,HTAC和HTAP很是接近,在工程方面咱們稱爲HTAC,用一個理論的名詞來歸納就是HTAP(混合事務分析處理系統),因此在那時咱們就已經推出本身的原創性產品,而這個產品這兩年的演化一直專一於強一致性,在去年咱們推出了兼具理論與實踐的產品,清楚解釋了「強一致」這個概念。該技術對應的產品,內部通過一段時間打磨後,載有該項技術的TDSQL將在TDSQL公有云等產品中很快推出。算法
先來看第一部分,分佈式數據庫的發展演進。這幅圖在說明什麼?裏面在談一些基礎架構:Shared Nothing、Shared Memory、Shared Disk、Shared Everything。這些是什麼?最先從哪裏來?硬件層面是作軟件的基礎,硬件層面的發展決定着軟件技術的發展,硬件層面把一些基本的框架搭好後,數據庫的軟件或者說應用層、系統層的軟件都會在上面疊加,就像搭積木同樣,一塊一塊地往上壘。對於數據庫內部其實也是這樣的,分模塊、分層次,以後這些東西均可以搭建在一塊兒。可是數據庫有着緊耦合性較強的特色,搭在一塊兒後就很難拆開,可是如今作分佈式數據庫的一個趨勢是要嘗試把這些東西拆分,再像搭積木同樣往上壘,哪一個地方須要什麼樣的組件,就去建設這樣的組件,模塊與模塊之間要解耦,解耦以後更易搭建,把這個系統搭得在未來更具擴展性。分佈式數據庫系統的底層基礎是和硬件緊密相關的。數據庫
我從技術的角度展現一下數據庫的表明技術。在這幅圖中,第一我的是數據庫界圖靈獎的第二位得主——關係模型的創始人科德博士,他在1970年的時候以一篇論文奠基了關係型數據庫的基礎。1974年時有兩個典型的技術誕生,一個是SQL語言,另一個是事務處理技術。50多年前,數據庫界第三位圖靈獎得主James Gray開始研究事務處理,並對獲得了一系列的開創性的成果,因此事務處理奠定於70年代,直至今日。同年,IBM一樣誕生了一個開創性的技術,就是咱們所熟知的SQL,SQL這個概念是從IBM在作數據庫的研究起就開始提出的結構化查詢語言。緩存
再日後,是ER模型,ER模型是實體關係模型,可以幫助咱們作數據庫應用的建模。可是,在數據庫技術的發展過程中出現了不少模型,包括前面說的1970年以前的關係模型、層次模型,再往前的網狀模型,這些模型和ER模型產生的初衷是同樣的,都是要從數據、數據層次的角度與實體世界進行映射,以讓數據世界具有表達、計算實體世界的能力。只不過ER模型在發展過程當中只被人們用於了關係建模(教科書擷取了精華展現,讀者的理解程度再也不能全面深入),但它背後包含的內容其實和關係模型、層次模型是相同的,若是咱們回顧歷史還原其初衷,則能從歷史當中看到的一些基本的東西。安全
到了1980年,數據庫界出現基於代價的查詢優化技術,它可以較好的選出一個近乎最優的執行計劃。此後,數據庫又演變出了基於火山模型的執行器,推進數據庫的技術進一步發展。從這副圖中能夠看出,數據庫技術發展基本上是從沒有事務到有事務概念這條主線上推動的,到了1993年的時候有了AP和TP的分叉,這歸功於科德博士,他除了提出關係模型,又提出了OLAP的概念——在線分析事務處理,之前的主線就變成了OLTP和OLAP兩條分支。性能優化
隨着時光的繼續推移,2014年,有意思的事出現了,一個並非學術研究機構而是對行業的研究機構——Gartner,推出一個概念:HTAP,指望在事務型的系統上加強分析的功能。這個概念這幾年大火,彷佛在補救事務型數據庫的重事務處理弱分析能力的缺陷(概念分家,指導思想發生變化,看來仍是有壞處的)。人們老是有一個美好意願,在一個系統內搞定全部的事情。這同人類的需求和不斷變化的認知存在關係。架構
但在這以前,2012年穀歌的Spanner系統誕生了,它標誌着人們從不要SQL到擁抱SQL擁抱數據庫的事務處理技術,演變成了New SQL系統。併發
前述這些技術,是數據庫的經典技術,不管單機數據庫仍是分佈式數據庫,都基於這些基礎性的技術。雖然TDSQL是一個分佈式數據庫,但裏面90%甚至更多的基礎核心功能來自於單機數據庫系統,因此技術的演進實際上是踏着前面的基礎而不斷演化的,分佈式數據庫的技術離不開前面咱們談到的關係模型、事務處理等基礎技術。所以我認爲作分佈式數據庫離不開單機數據庫系統,認識分佈式數據庫要先從單機數據庫系統入手,單機數據庫系統實際上就有了分佈式數據庫的五臟六腑,它已經比較全面。只是分佈式數據庫在基礎技術之上,因系統架構的變化,有了一些新挑戰。框架
下面,咱們以MySQL的數據庫系統架構爲例,來分享單機數據庫系統包含了哪些模塊和組件。分佈式
左上角的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這種架構,這是一個過渡時代。再日後咱們會進入到真正的分佈式數據庫時代,它典型的標誌是什麼?是多寫,在每個節點上都平等地對待,能夠在每個節點上寫,這裏面的技術就又有多種,有的是僞的分佈式,其把事務的全部寫操做集中在單一的節點上去作,真的分佈式是利用分佈式併發訪問控制算法,在每個節點上去作數據一致性的保障。
數據庫基本架構的演進就是經歷了這麼一個過程,總結一下,反過來從技術角度來看到底是什麼因素在推進分佈式數據庫系統的演進。其實數據庫系統有一些內在的、本質性的需求在推進它,咱們之前說數據庫系統裏面有「三高一易」,高可靠、高可用、高性能、易用性等等,這些基礎因素在推進着分佈式技術不斷地向前發展,到後來演化成分佈式數據庫系統的時候,對於水平擴展的要求提上日程,因此個人第一個總結是針對擴展,不只是垂直擴展,並且要水平擴展,因此對於擴展性下的多讀多寫場景,使得分佈式數據庫的結構變成純粹的每個節點都是對等的結構。在分佈系統裏要講究可用性,包括數據層面的可用如共識協議下的數據多副本機制、也包括整個系統功能層面的可用。若是以較少的投入得到高的性能,那就能夠對外支撐更多的業務,成本就會更低。因此對於數據庫內在原生的要求從單機數據庫系統到分佈式數據庫系統一直沒有發生過變化。這是我分享的第一部分。
第二部分,咱們來看看分佈式數據庫系統裏面的技術層面會包含一些什麼樣的內容。事務型分佈式數據庫系統裏面最核心的,必定是事務處理技術。數據庫的操做通過抽象之後就有兩種,一種是讀操做,一種是寫操做,當有了併發存在的時候,至少有兩個事務讀寫一樣數據項的時候,就可能產生數據異常。
左邊的圖在說當讀寫在兩個事務的正交之下,就是2×2四種狀況,四種狀況裏只有讀和讀不會產生數據異常,其餘的組合都會產生數據異常,這是數據異常產生的緣由。由於有併發讀寫相同的數據項,事務處理就是要解決這樣的問題。事務處理有ACID四個特性,其中的C是一致性,I是隔離性,其實C和I是相同的內容,就像硬幣的兩個面,保證一致、保證隔離,隔離級別弱一點,一致性會差一點,會容許一些數據異常存在,也就是右邊這部分表示的,一些特定的數據異常現象會發生。
這幅圖總結了部分數據異常現象,但實際上數據異常不僅是這麼一點點,TDSQL在作的一項工做是:系統化地研究數據異常到底有多少種。目前爲止人類都不可以解釋清楚數據異常到底有多少。
SQL標準定義了四種數據異常、四種隔離級別,James Gray在裏1995年的一篇論文定義了八種數據異常、八種隔離級別,在這種狀況下,若是忽然又發現第9個數據異常,按照SQL標準,它應該被放在這兩個體系下的哪個隔離級別之下?這樣的問題在目前是不能回答的,而這也是TDSQL在作分佈式數據庫研發過程中所遇到的、所要解決的問題,只有回答了這樣的問題以後,一個系統才能真正作到強一致,所幸咱們目前對這樣的一個基礎問題有了明確的答案,而且秉持騰訊開源精神,把這項研究結果開源到了3TS系統(Tencent Transaction Processing Testbed System)。
解決數據異常的一些技術就是併發訪問控制算法,而併發訪問控制算法又有不少,好比基於封鎖的、基於時間戳的、基於樂觀機制的等等。TDSQL開源的系統是作基礎技術研究的,即騰訊事務處理實驗牀,咱們的系統叫作3TS,取剛纔我說的那幾個詞裏面的第一個字母T,因此有三個T,就是3TS。
而解決分佈式數據庫系統裏面和事務相關的技術,比較重要的還有一種數據異常——讀半已提交。讀半已提交這樣的數據異常是基於物理分佈的系統上產生的,在一個節點上某個數據項已經提交了,轉帳的另外一個節點上的還沒提交,這時來第二個事務去讀這兩個節點,必定能讀到已提交的那個節點上的數據,可是讀不到未提交節點上的數據,也就是在未提交節點上所讀到的數據是舊的數據,舊的數據和已提交的新數據兩者之間不能保證數據一致性,因此會產生稱之爲讀半已提交的數據異常,這就是分佈式數據庫在事務處理層面即一致性方面要解決的問題。
但分佈式數據庫系統面臨的不僅這些問題。由於數據庫從一個集中式系統擴展變成了每個都邏輯獨立的子系統,但對外它的行爲還像一個物理單一的數據庫系統要表現的同樣,這就面臨着新的挑戰。單機數據庫系統上作事務處理要保證ACID,分佈式系統裏面也要保證ACID,可是分佈式系統裏面要有分佈式一致性,如:線性一致、順序一致、因果一致,還有讀後寫、寫後讀等等,而這兩個碰到一塊兒就會產生新的問題,這是分佈式系統要解決的。
不僅是上面說起的問題,咱們面對的問題更爲複雜。例如,以下這張圖概況了各類分佈式一致性的概念,很複雜,這裏面大約有近60種分佈式一致性,光把這幅圖弄清楚、把每一種一致性弄清楚,已經不容易了,再和事務的ACID結合,難度就會更大。
業界對於分佈式事務的一致性,是有研究的。以下圖,我大概解釋一下這幅圖的內容:左上角事務一致性,左下角分佈式一致性,右上角有個隔離級別下的事務一致性問題,這是數據庫裏要處理的事情,但恰恰就在該圖這個紅色方框,分佈式一致性和事務處理裏面結合的這些地方目前爲止沒有相關的理論和技術來支撐,而這些也正是TDSQL在作分佈式數據庫系統當中致力於解決的問題。對比業界谷歌的Spanner,Spanner作到了真的強一致,這是目前我看到的惟一的強一致系統,惟二是TDSQL。Spanner作到了線性一致加ACID數據一致性的融合,業界實際上早有這個概念叫作嚴格可串行化,它能在全局層面保證分佈式系統下數據的一致性,這纔是真的強一致(請注意,這裏強調全局,即從任何一個節點看去讀取數據,你們都能讀到同樣的結果,不可能不一樣節點得到不一樣的觀察結果)。
可是若是對Spanner作一個測試或者理論推導,會發現Spanner系統的事務處理性能很是差。Spanner能用到什麼地方?就是用到非實時性廣告系統數據的處理上面,可是你們據說過Spanner用到過金融系統裏面嗎?沒有,此種背景下,就對TDSQL構成新挑戰了,由於TDSQL要用到金融系統業務裏面,咱們既要保證正確性,又要保證性能。
而作分佈式數據庫還面臨着作高併發執行器須要的技術MPP。
從一開始咱們就提到了數據庫基於硬件系統搭建,受限於硬件,做爲分佈式數據庫,還面臨什麼問題?咱們在研究它和新硬件有什麼關係,剛纔蓋老師談到了Oracle21c,21c作了持久化內存和數據庫的結合,但它是單機的結合,而TDSQL要作和分佈式系統的結合。好比早期和SSD這樣的硬件結合,如今和持久化內存、和RDMA結合,都是咱們在作的事情。
全部這些事情都有一個外在的需求驅動,就是數據量的變化。數據量的變化有幾個層面,第一個很重要,但你們可能並無徹底感覺到,就是元數據。對於一個分佈式數據庫系統來說,元數據會劇增,也會對數據庫提出一些新的挑戰,不只如此,數據庫系統裏面還有什麼?咱們知道你們都在談AI for DB,這時AI系統必定須要大量的數據,這大量的數據就要有一個存儲,有些系統是把AI所需數據存儲在數據庫以外,而咱們在考慮,可否存儲在數據庫以內?若是能又以什麼形式存儲?這都是做爲分佈式技術要研究、考慮的基礎問題。
因此分佈式數據庫包含了比較多的內容:事務處理數據量的存儲層面、計算層面等方面的問題,基於這些需求,咱們展開了基礎研究,作了TDSQL的HTAC系統,裏面包含多種多樣內容。這是咱們系統的基礎架構圖,它看起來像一個單機系統,可是裏面會有不少小的細節,能夠看出其是一個分佈式系統。
在這個系統裏會包含多種多樣的技術,其中核心的就是我剛纔談到的和事務處理相關的——怎麼保證強一致。
而根據咱們的研究,發現數據異常有無數個,無窮盡的東西,怎麼去認知?這又造成新的挑戰。TDSQL在作的一項工做事就是對數據異常歸類,把數據異常分紅有限的若干種,對它進行認知,基於這樣的認知就能夠定義什麼叫隔離級別、什麼叫一致性,怎麼去影響、看待現有全部的併發訪問控制算法,怎麼和分佈式一致性去結合,這都是TDSQL在研的一些基礎技術,也是剛纔談到的一致性技術裏面的基礎內容。
接下來分享下咱們作出的工做。左上角是學術界的認識,左下角是業界的現有產品對於強一致的支持程度,右下角是咱們得出來的結果,咱們把左上角那棵樹變成了右下角的一張網,意思是把樹上不少看似沒有關聯關係的節點交織在一塊兒聯繫起來,這裏面就涉及到強一致性相關的技術內容。
基於剛纔的技術,咱們研發出了多級一致性技術,即多種級別的可串行化技術,使得在分佈式系統下,可串行化又能夠分爲多種級別。咱們在谷歌雲上買了Spanner服務,對比了Spanner,在GreenPlum上實現了多級一致性技術,又在MIT開源的一個系統上對比了多種併發訪問控制算法,實驗結果代表,TDSQL的性能都更好(該技術在2020年的DTCC上作過公開分享)。
最後總結,分佈式數據庫的挑戰、問題在哪裏?我以一個目錄結構列出了這些內容。該目錄結構分爲兩部分,左面部分是數據處理技術其自身對數據庫的內在驅動需求,右面部分是基於數據庫所處的外部環境對於數據庫的驅動因素。你們能夠觀察目錄所列的這些基本因素,以瞭解分佈式數據庫的相關技術點。數據庫內在的需求其實有分佈式和存儲架構相關的,數據分佈、存儲管理、多副本、存算分離、多讀多寫、查詢優化、MPP。這個思路其實和我剛纔所分享的脈絡是一脈相承的,又和高可用、和事務處理相關,這些都是分佈式數據庫的內在需求,驅動着數據庫技術繼續不斷地前進。
從外面的來看,新硬件、智能數據庫、雲計算,這些是計算對於數據庫系統的要求;HTAP,還有下一代所謂的New SQL,數據庫也在不斷地演進,此過程當中還會產生一些新的技術和內容。因此作分佈式數據庫,大部分就是基於單機數據庫系統,再作一些和分佈式相關的事。分佈式相關的事情大概是我前面提到的那些主流技術,這張目錄結構把沒有包括的基本核心內容都包含了。
其中,特別說明一點,是去中心化。作分佈式數據庫必定要考慮去中心化,也就是各個節點之間是對等的,考慮一個併發訪問控制算法的時候,這個算法是否是去中心化的?它們之間的關係是否是對等的?都是要考慮的。
最後,若是你們對核心的基礎技術感興趣,能夠關注咱們3TS的系統,它的研究目標主要包括:好比分佈式事務處理怎麼去作,它和性能擴展性、安全性、一致性等等這些的關係是什麼,怎麼評價這個分佈式數據庫系統,數據異常有多少(咱們回答了數據異常有無數個,但能夠歸類爲有限種),併發訪問控制算法怎麼改進等技術。
期待和各位朋友深度交流。謝謝你們。
騰訊雲數據庫專家工程師,負責騰訊TDSQL研發工做。中國人民大學信息學院工程碩士企業導師,CCF數據庫專委會委員,DTCC(中國數據庫技術大會)專家委員會委員。出版有《數據庫查詢優化器的藝術:原理解析與SQL性能優化》、《數據庫事務處理的藝術:事務管理和併發訪問控制》、《大數據管理》。申請與受權專利50+,VLDB等頂會論文若干篇。參與包括國家863重大專項、核高基、工信部、科技部等多項目。獲北京市科技進步一等獎。