大家好，我是李躍森，目前負(fù)責(zé)騰訊云TBase數(shù)據(jù)庫研發(fā)的相關(guān)工作。今天跟大家分享的內(nèi)容主要分為兩大章節(jié)：第一章，數(shù)據(jù)庫技術(shù)的基本概念和基本架構(gòu)；第二章，TBase產(chǎn)品的典型案例，以及在國產(chǎn)化上我們所做的具體工作。

數(shù)據(jù)庫產(chǎn)品分類

首先，我們來看一下數(shù)據(jù)庫的分類。數(shù)據(jù)庫分類有多種方式，接下來會介紹三種分類。

一、按照數(shù)據(jù)庫的業(yè)務(wù)場景劃分

一般我們在談?wù)摂?shù)據(jù)庫的時候，首先會問數(shù)據(jù)庫是OLAP還是OLTP？

OLAP，即在線分析型處理，這一塊其實(shí)是按照業(yè)務(wù)特點(diǎn)來劃分的。OLAP的第一個特點(diǎn)是數(shù)據(jù)量比較大，一般會要求PB級或者更大的數(shù)據(jù)量，數(shù)據(jù)量大了以后，對存儲的成本會比較敏感，對數(shù)據(jù)壓縮也會有一定的要求，OLAP業(yè)務(wù)系統(tǒng)的并發(fā)量不會特別的高。另外，OLAP場景下查詢一般都會比較復(fù)雜，每個查詢需要消耗大量的資源，會要求多個用戶之間的查詢要減少相互之間的影響，進(jìn)行資源隔離。類似產(chǎn)品還是比較多的，比如:TeraData、SybaseIQ、GreenPlum、HP Vetica、 Gauss200、 VectorWise、AWS Redshift，以及現(xiàn)在比較流行的ClickHouse等。

OLTP，即在線事務(wù)型處理。在線事務(wù)處理數(shù)據(jù)量相對較小，普遍時延要求較高，要求達(dá)到毫秒級。在吞吐量這一塊，普遍要求能夠達(dá)到百萬級以上的TPS。OLTP業(yè)務(wù)系統(tǒng)都是我們核心的業(yè)務(wù)系統(tǒng)，包括銀行、保險、電信這樣的實(shí)時在線的業(yè)務(wù)，業(yè)務(wù)特點(diǎn)決定對容災(zāi)能力有一些突出的要求，一般來講要求99.99%以上的可靠性。傳統(tǒng)上來講，我們一般講數(shù)據(jù)庫都是指：Oracle、IBM DB2、Informix、MySQL，以及PostgreSQL這樣的一些數(shù)據(jù)庫。

這兩年還興起一個數(shù)據(jù)庫概念叫做HTAP，即混合事務(wù)處理和在線分析型數(shù)據(jù)庫?；镜乃悸肥悄軌蛟趩渭簝?nèi)部同時處理OLAP和OLTP兩類業(yè)務(wù)，而且OLAP和OLTP業(yè)務(wù)之間有良好的資源隔離。典型產(chǎn)品這兩年宣傳的比較多的如TiDB，包括TBase設(shè)計之初也是這么考慮的。

二、按照時間劃分

現(xiàn)在我們一般會講Old SQL，這個所謂的Old SQL是指傳統(tǒng)的SQL數(shù)據(jù)庫。此類數(shù)據(jù)庫的典型特點(diǎn)：它是一個完整的關(guān)系模型，具備完整的事務(wù)能力。像Oracle、IBM DB2、MySQL、PostgreSQL這些是傳統(tǒng)的數(shù)據(jù)庫。

在2010年前后，No SQL數(shù)據(jù)庫在互聯(lián)網(wǎng)中大量興起，泛指一些非關(guān)系型數(shù)據(jù)庫，主要特點(diǎn)是沒有完整的事務(wù)支持，而且沒有模式的概念，普遍采用無共享架構(gòu)，根據(jù)業(yè)務(wù)進(jìn)行分區(qū)。另外在復(fù)制這一塊，使用異步復(fù)制，保持最終的一致性。典型產(chǎn)品包括Redis、HBase、MongoDB等。

最近這兩年，結(jié)合上面的Old SQL和No SQL的概念，又提出了一個New SQL的概念， New SQL其實(shí)是結(jié)合了Old SQL和No SQL的概念，它既具備了No SQL的便利性，又能夠支持傳統(tǒng)數(shù)據(jù)庫數(shù)據(jù)庫架構(gòu)，但是New SQL在關(guān)系模型的完整性上存在一些問題。

三、按照架構(gòu)

數(shù)據(jù)庫的劃分經(jīng)過多年的演進(jìn)，大概有三種架構(gòu)。

第一種是單體數(shù)據(jù)庫，所謂單體數(shù)據(jù)庫就像之前我們經(jīng)常提到的Oracle、PostgreSQL、MySQL這種單機(jī)的數(shù)據(jù)庫，單個實(shí)例能夠提供獨(dú)立的服務(wù)，主備機(jī)通過流復(fù)制來做HA，這是傳統(tǒng)的架構(gòu)。

第二種是共享存儲架構(gòu)，多個數(shù)據(jù)庫實(shí)例同時訪問一份存儲，數(shù)據(jù)是存儲在專門的存儲設(shè)備中，這里的存儲設(shè)備一般是指磁盤陣列或者類似于這樣專用的存儲設(shè)備，現(xiàn)在我們能看得到的包括Oracle RAC、SybaseIQ都是這樣的架構(gòu)。

第三種是無共享，也就是我們常說的MPP。每個DN節(jié)點(diǎn)存儲一個數(shù)據(jù)分片，在DN節(jié)點(diǎn)之上會有另外一層節(jié)點(diǎn)，這層節(jié)點(diǎn)在不同的數(shù)據(jù)庫中有不同的名字，但是它的作用其實(shí)是一樣的，都是接收業(yè)務(wù)請求，然后分發(fā)，同時對業(yè)務(wù)請求進(jìn)行返回。TeraData、GreenPlum、TBase、TDSQL、TiDB都是屬于這種架構(gòu)。

隨著云業(yè)務(wù)形態(tài)的誕生，這兩年在傳統(tǒng)的數(shù)據(jù)庫架構(gòu)基礎(chǔ)上，產(chǎn)生一種比較流行的新架構(gòu)——云原生架構(gòu)，日志即數(shù)據(jù)庫。

它會把數(shù)據(jù)庫的業(yè)務(wù)邏輯沉到底層的存儲節(jié)點(diǎn)里面去，存儲節(jié)點(diǎn)和上面的計算節(jié)點(diǎn)是進(jìn)行邏輯上的分離，其實(shí)也就是物理上的分離，另外一種叫法是計算與存儲分離。在下層的存儲集群之間，通過一致性協(xié)議來保證多個副本之間的一致性，統(tǒng)一對上層的數(shù)據(jù)節(jié)點(diǎn)提供一個可靠的存儲服務(wù)。這里補(bǔ)充說明下：數(shù)據(jù)庫節(jié)點(diǎn)就是把數(shù)據(jù)庫的業(yè)務(wù)邏輯，包括SQL解析及SQL的執(zhí)行都做到上層去。類似的產(chǎn)品現(xiàn)在也比較多，基本上幾個大的云廠商都有自己的產(chǎn)品。主要有兩個技術(shù)優(yōu)點(diǎn)，1、可以做到存儲計算分離，存儲和計算可以做到單獨(dú)擴(kuò)容，2、它可以實(shí)現(xiàn)存儲的超賣，這在云上這是一個比較有價值的能力。

這里給大家重點(diǎn)介紹一下PostgreSQL數(shù)據(jù)庫，如果是在十年以前提到PostgreSQL，大家可能都會一臉懵。經(jīng)過這幾年國內(nèi)PostgreSQL社區(qū)的推廣，PostgreSQL的認(rèn)可度已經(jīng)高了很多。

它是由圖靈獎得主石破天主導(dǎo)的一個項目，以BSD風(fēng)格協(xié)議開源。PostgreSQL的好處是源代碼可以隨意的修改和發(fā)布，甚至可以用來盈利。PostgreSQL在網(wǎng)站上聲稱是最先進(jìn)的開源數(shù)據(jù)庫，經(jīng)過這么多年的發(fā)展，PostgreSQL的整個功能上距離商業(yè)數(shù)據(jù)庫Oracle確實(shí)越來越近，作為開源產(chǎn)品也具備了一些Oracle不具備的靈活性和擴(kuò)展能力。最近幾年社區(qū)發(fā)布版本的速度是越來越快，技術(shù)思路逐漸向商業(yè)數(shù)據(jù)庫靠近，相信后面會有越來越多的業(yè)務(wù)跑在PostgreSQL上。

很多人都問MySQL和PostgreSQL兩個之間有什么區(qū)別。這邊簡單列舉了一下它們的區(qū)別。

接下來跟大家分享下TBase的整體情況，先從TBase的簡史說起。

TBase是基于PostgreSQL研發(fā)的一個分布式數(shù)據(jù)庫，最早可以追溯到2009年。當(dāng)時是拿PostgreSQL來作為我們內(nèi)部數(shù)倉的補(bǔ)充，支撐小數(shù)據(jù)量的分析。2014年開發(fā)了TBase第一個版本，內(nèi)部開始使用。2015年TBase在微信支付商戶集群里面上線后。到了2018年，發(fā)布了TBase V2，在數(shù)字廣東和云南公安上線。2019年發(fā)布了TBase的V3版本。

數(shù)據(jù)庫核心技術(shù)選型

在講架構(gòu)設(shè)計之前，先來看一下TBase面臨的業(yè)務(wù)場景。

TBase的整體物理架構(gòu)，跟前面提到的架構(gòu)是比較類似的。

TBase整體物理架構(gòu)分三個部分，圖中的左側(cè)上層GTM是事務(wù)管理器，它主要是提供全局事務(wù)的信息，同時管理全局對象。另外圖中右側(cè)上層Coordinator（協(xié)調(diào)節(jié)點(diǎn)CN），它主要提供業(yè)務(wù)訪問入口。協(xié)調(diào)節(jié)點(diǎn)中每個節(jié)點(diǎn)之間是對等的，也就是說業(yè)務(wù)訪問這三個節(jié)點(diǎn)里面的任何一個，它得到的結(jié)果都會是相同的，而且訪問這個節(jié)點(diǎn)，事務(wù)的一致性能夠得到保證。圖中中層是集群數(shù)據(jù)交互總線，把整個數(shù)據(jù)庫集群的各種連接到了一起。圖中下層是數(shù)據(jù)節(jié)點(diǎn)，數(shù)據(jù)節(jié)點(diǎn)有些是我們實(shí)際存儲數(shù)據(jù)的地方。每個數(shù)據(jù)節(jié)點(diǎn)會存儲一份本地的Local元數(shù)據(jù)，同時還有本地的數(shù)據(jù)分片。

接下來給大家詳細(xì)分享下TBase是怎么做的，重點(diǎn)分享架構(gòu)設(shè)計思路。

講分布式事務(wù)之前首先講下Sharding模式存在的問題。這里舉個例子，我們現(xiàn)在有AB兩個帳戶，每個帳戶余額是10元，兩個帳戶總額是20元，我們對這兩個帳戶之間進(jìn)行轉(zhuǎn)帳，從B往A轉(zhuǎn)5元，并發(fā)量很大的時候，如果是一個一致性保持的比較好的系統(tǒng)，那么無論我們有多少的并發(fā)，兩個帳戶的總額應(yīng)該總是20元。

在sharding模式下，事務(wù)3和事務(wù)4存在嚴(yán)重的事務(wù)不一致問題。那為什么很多業(yè)務(wù)系統(tǒng)中用了sharding的模式，卻沒有這類問題呢。主要的原因是大多數(shù)使用以上模式的業(yè)務(wù)都是互聯(lián)網(wǎng)公司的業(yè)務(wù)，互聯(lián)網(wǎng)公司的開發(fā)團(tuán)隊有比較強(qiáng)的開發(fā)能力，可以讓業(yè)務(wù)代碼處理上面遇到的問題，把數(shù)據(jù)庫作為一個簡單的數(shù)據(jù)容器來處理。但對于一些普通用戶或者普通場景的話，就不一定具備互聯(lián)網(wǎng)公司的資源和技術(shù)能力了。在TBase中，我們也是需要處理分布式事務(wù)的一致性問題，為業(yè)務(wù)屏蔽掉事務(wù)的相關(guān)細(xì)節(jié)。
這里我分享下TBase分布式事務(wù)系統(tǒng)的目標(biāo)。

首先在保證分布式事務(wù)完整性的基礎(chǔ)上能夠提供高性能、低延時、高吞吐的事務(wù)能力，并盡量使用低成本的硬件來達(dá)成我們的目標(biāo)。同時，也希望在保證這三者的基礎(chǔ)上，我們事務(wù)的處理能力能夠隨著集群的規(guī)模近似線性的增加，提供事務(wù)處理能力的擴(kuò)展性，提供包括死鎖檢測和事務(wù)故障恢復(fù)等事務(wù)保障能力。

在開始介紹TBase事務(wù)模型之前，先來看一下現(xiàn)在大家常用的分布式事務(wù)模型。

一、分布式的快照隔離

可以簡單理解是PostgreSQL使用的MVCC的分布式的實(shí)現(xiàn)，這里面主要分幾個部分。

在GTM上，要求維護(hù)一個開放的事務(wù)列表，事務(wù)列表指的是當(dāng)前這個集群里面正在運(yùn)行的一些事務(wù)。舉個例子，如果說我當(dāng)前啟動一個新的事務(wù)，然后我就會把它加到這個列表里面來。如果這個事務(wù)結(jié)束了，這個事務(wù)列表就會把這個xid從事務(wù)列表拿掉?？蛻舳嗽谂芤粋€SQL的時候，都會要求從GTM上拉取一個事務(wù)的快照，所謂的事務(wù)快照是將當(dāng)前這個事務(wù)列表里面的一個拷貝，發(fā)到我們的DN上做活躍事務(wù)的判斷。這里有以下3個問題：

• 問題1：這個活躍事務(wù)列表是一個O（N）的長度，也就是說它和當(dāng)前事務(wù)并發(fā)的個數(shù)是呈正比方式的，有多少個并發(fā)的事務(wù)在跑，這個事務(wù)的列表就有多長。
• 問題2：剛才也提到我們每個客戶端在訪問SQL的時候需要從服務(wù)器去拉取一個快照到本地去，這樣的話也就是說對GTM的網(wǎng)絡(luò)占用的比例是N的平方，也就是N的平方乘以M，M是SQL的個數(shù)。
• 問題3：剛才也提到了，事務(wù)列表是全局資源，不管是事務(wù)的啟動還是提交，甚至獲取快照都需要對這個列表進(jìn)行加速。這樣的話，基本上來講我們是在系統(tǒng)里面增加了一個全局的大鎖，這個大鎖就會成為這個系統(tǒng)的一個擴(kuò)展的瓶頸。

二、基于物理時間的并發(fā)控制

基于物理時間有兩種方式：

第一種方式是Google spanner中采用的方式，這個分布式系統(tǒng)要求提供一個全球分布式的一個分布式數(shù)據(jù)庫，達(dá)到百萬級的數(shù)據(jù)庫節(jié)點(diǎn)?；谌謺r間快照的進(jìn)行并發(fā)控制，它的全局時間快照使用的是GPS和原子鐘一起生成。全局時間版本，這個東西有一個6毫秒左右的誤差。也就是說它的一個事務(wù)在運(yùn)行的時候，最低延時就是6毫秒。第二個問題是成本比較高，需要專用硬件，每個IDC都需要有自己的原子鐘和GPS設(shè)備。

第二種方式是CockRoachDB，其實(shí)是Google Spanner的變種。主要的區(qū)別是它使用的是本地的時間來進(jìn)行控制，嚴(yán)格意義上講應(yīng)該是混合時鐘。相比之下成本會比較低廉，并且沒有中心節(jié)點(diǎn)。但是NTP精度會影響事務(wù)的時延。

三、基于邏輯時間的并發(fā)控制

現(xiàn)在大家討論的比較多的是基于邏輯時間的并發(fā)控制。

用一個TSO集群提供集群的邏輯時間戳作為版本號。這個事務(wù)模型相對來講就沒有之前提到的那幾個版本控制的問題。里面會把當(dāng)前事務(wù)里面進(jìn)行的所有的修改記錄都記錄下來，在事務(wù)提交的時候一次提交，也就是說它是一個O（N）的動作，N指的是我們在這個事務(wù)里面修改了所有的記錄的集合。而且這個過程中集群會加鎖，阻塞后面的寫入。

這里重點(diǎn)介紹TBase這一塊，TBase的并發(fā)控制，全局事務(wù)的一個控制其實(shí)是結(jié)合了最早提到的分布式快照隔離一起做的一個隔離模型。

核心部分是GTS集群，GTS集群和TSO的功能很像，也使用了邏輯時間戳的概念，這個時間戳的基線是我們自己定義的一個開始的點(diǎn)，單向遞增。

我們自己內(nèi)部定義了MVCC機(jī)制原理，對于當(dāng)前事務(wù)，記錄的gts_min已經(jīng)提交，而且事務(wù)的gts小于記錄的gts_max，我們才能看到這條記錄。

GTS是從0開始的一個單向遞增的邏輯時鐘源，通過硬件提供足夠的穩(wěn)定性保證，保證不發(fā)生偏斜。同時，GTS本身通過流復(fù)制的方式來保證自己的可靠性。性能方面，一般普通24 core的服務(wù)器可以達(dá)到1200萬的QPS，幾乎可以滿足所有業(yè)務(wù)場景的需要。

下面分享一下TBase在行存儲和列存儲這一塊的一個選擇。

行存儲的話，顧名思義，是按行存儲。也就是說在磁盤存儲的時候，我們像上面的表一樣，我們存儲的時候是先存儲完第一行，然后存儲第二行，再存儲第三行，再第四行，這樣緊密存儲。這個好處在于：每次IO的時候，可以把一行記錄的所有的列都能夠讀到這里面去，適合OLTP場景。

另外一個是按列存儲，我們把同一列的數(shù)據(jù)連續(xù)存儲在一起。比如：蜘蛛俠、超人、火箭浣熊、閃電俠這一列在磁盤上面，第二列是另外一個文件，這種存儲的好處在于：每次IO的時候，只會讀取同一列的數(shù)據(jù)，可以大大的提升聚合操作處理的效率，比較適合OLAP的場景。

在分布式場景下，我們不得不考慮另外一個問題，除了選擇的行列之外，還要考慮我的數(shù)據(jù)在集群里面如何存儲，也就是怎么把數(shù)據(jù)分片存在我們的分布式集群里面去，TBase里面叫選擇表的分布類型。

第一種是復(fù)制表，有的地方叫快表，在集群里面的指定節(jié)點(diǎn)上，每個節(jié)點(diǎn)都會有數(shù)據(jù)的完整副本，這樣的表特別適合一些變化比較小的小表，對于一些關(guān)聯(lián)插件的加速是比較有用的。

第二種是大家比較常見的是HASH分布，就是把數(shù)據(jù)打散到不同的存儲節(jié)點(diǎn)上去，明顯的問題是HASH傾斜。

第三種也是比較常見的方式RANGE分布，即按照數(shù)據(jù)的范圍來進(jìn)行分布。其實(shí)在分布式場景中，除了這種我們可以指定具體的算法進(jìn)行分布的方式之外的，還有就是在數(shù)據(jù)倉庫里面比較常用的隨機(jī)分布，不用任何算法來進(jìn)行分散，把數(shù)據(jù)全部打散到整個集群中去。TBase的分布方式主要有復(fù)制表和HASH分布兩種。

關(guān)于分布式查詢的執(zhí)行方式，在MPP這種架構(gòu)下每個DN的數(shù)據(jù)都是不完整的。為了完成一個完整的分布式查詢，有一些策略需要選擇。如果是一些單點(diǎn)的查詢就無所謂，比較難搞的是分布式的JOIN。

這里面的策略主要有兩種，一種是所謂的PUSH QUERY，通過把它的查詢下推到DN節(jié)點(diǎn)上去， SQL在DN上執(zhí)行，把數(shù)據(jù)返回給CN。另外一種方式就是PULL DATA，也就是通過把DN節(jié)點(diǎn)上的數(shù)據(jù)拉取到CN上通過CN來完成所有的計算。數(shù)據(jù)量較大的時候， PUSH QUERY效率會高很多，PULL DATA在一些數(shù)據(jù)量比較小的時候，效率會比較好。TBase里面兩種方式都會有，我們也會選擇PUSH QUERY或者PULL DATA，至于選擇哪種是根據(jù)我們的優(yōu)化器來選擇。

分布式執(zhí)行在 SQL shipping還是PLAN shipping之前該如何選擇？

SQL shipping是指我們在PUSH QUERY的時候是PUSH SQL,DN完成SQL解析和優(yōu)化執(zhí)行。這種場模式不適合復(fù)雜SQL的執(zhí)行，但架構(gòu)相對比較簡單，易開發(fā)易維護(hù)。所謂的PLAN shipping是在CN節(jié)點(diǎn)上生成整個執(zhí)行計劃，CN節(jié)點(diǎn)再根據(jù)我們的統(tǒng)計信息和數(shù)據(jù)分布來生成計劃的分片，再把這個下推到各個DN節(jié)點(diǎn)上去，這個時候DN節(jié)點(diǎn)就不會進(jìn)行二次解析，拿到執(zhí)行計劃并返回結(jié)果。這種方式優(yōu)點(diǎn)其實(shí)比較明顯的，它對SQL的優(yōu)化能力是比較強(qiáng)的，能夠在一些特別復(fù)雜條件的時候，效率會比較好。不過缺點(diǎn)比較明顯，對于一些數(shù)據(jù)量不大的場景，執(zhí)行計劃的解析和下發(fā)花了很多的時間，導(dǎo)致簡單查詢的時候，小數(shù)據(jù)量查詢效率不高。在TBase中，我們會根據(jù)我們業(yè)務(wù)的特點(diǎn)和數(shù)據(jù)的特點(diǎn)來選擇兩種中的任何一個，也就是說TBase兩個都是支持的。

在執(zhí)行計劃生成層面，我們生成執(zhí)行計劃的策略有兩種。

第一種是規(guī)則優(yōu)化(RBO)，即 RULE BASED OPTIMIZER，顧名思義就是在生成執(zhí)行計劃的時候，是根據(jù)SQL的模式，遇到了什么條件，就生成什么樣的執(zhí)行計劃給它。這種方式其實(shí)在實(shí)踐起來比較簡單，某些方面比較高效，缺點(diǎn)是彈性不足，對一些復(fù)雜場景，它很難去應(yīng)對，沒有足夠的彈性。

第二種是代價優(yōu)化(CBO)，即COST BASED OPTIMIZER，這是用的比較多的主流優(yōu)化方式。它主要會從目標(biāo)SQL諸多可能的執(zhí)行路徑中選擇成本比較小的一條作為執(zhí)行計劃，成本值是根據(jù)目標(biāo)SQL語句所涉及到的表、索引、列等相關(guān)對象的統(tǒng)計信息算出來的。它的適用性會比較好，特別適合一些復(fù)雜的場景，而且在一些復(fù)雜場景下會性能表現(xiàn)比較穩(wěn)定。缺點(diǎn)是復(fù)雜度比較高的，有一定的前置條件，包括我們統(tǒng)計信息的準(zhǔn)確度，代價計算模型的一個精確度。TBase來講的話，兩塊都會有，更多的會偏向于后面的代價優(yōu)化(CBO)。

TBase在整個設(shè)計分布式執(zhí)行方式的時候，我們有一個很明確的目標(biāo)：希望業(yè)務(wù)的SQL不需要感知集群結(jié)構(gòu)，它可以像使用單機(jī)的數(shù)據(jù)庫一樣來使用TBase。

也就是說客戶和業(yè)務(wù)在使用TBase的時候，他不用考慮分庫分表的問題，也不用考慮這個集群里面有多少個節(jié)點(diǎn)，SQL是怎么寫的，他就可以像使用普通的單機(jī)的數(shù)據(jù)庫一樣來使用TBase。為了達(dá)成這個目標(biāo)，我們使用了前面我們講到的各種各樣能夠幫助我們解決問題的技術(shù)。比如說我們在進(jìn)行查詢優(yōu)化的的時候，如果發(fā)現(xiàn)表這一列都是按照分布列來進(jìn)行查詢的，就走規(guī)則的優(yōu)化，查詢直接下推；如果我們不是按照分布列來進(jìn)行查詢的，是按照表A是分布列，表B是非分布列，這個時候進(jìn)行查詢的時候就會根據(jù)代價來進(jìn)行判斷。如果這個表B足夠小的話，會通過廣播的方式，把表B在每個節(jié)點(diǎn)上都形成一個完美的副本，拿表A進(jìn)行查詢。如果表A和表B都很大，這個時候我們就會選擇一個成本相對比較低的表來進(jìn)行重分布，選擇的方式是表B。假如說表B相對于表A要小一點(diǎn)，按照表B來進(jìn)行重分布，來完成整個查詢。這個用在上面，我提到了包括redistribution和replication，還有push down。后面兩個我們push的是PLAN。

在TBase里面，在MPP的架構(gòu)下，我們具備了并行計算的架構(gòu)基礎(chǔ)。

全并行大概分幾級，其中第一級是節(jié)點(diǎn)級的，也就是說一個SQL來了之后，我們會把這個查詢的同時發(fā)給三個節(jié)點(diǎn)，三個節(jié)點(diǎn)同時開始計算。然后在節(jié)點(diǎn)內(nèi)部的話，我們會進(jìn)行算子級的并行。比如說進(jìn)行一個Hash JOIN，我們會多進(jìn)程的完成這樣一個Hash JOIN的過程。在每一步計算的過程中，還會使用指令級的SIMD的一些指令來加速。這樣其實(shí)做到了從節(jié)點(diǎn)級到進(jìn)程級以及指令級的一個并行。

前面介紹了我們對性能進(jìn)行優(yōu)化的方式，這里講一下數(shù)據(jù)庫常見的容災(zāi)方式。

數(shù)據(jù)庫容災(zāi)方式大概分幾種：

第一種是我們傳統(tǒng)單機(jī)數(shù)據(jù)庫，包括MySQL、PG、ORACLE，常規(guī)的這種容災(zāi)方式也是通過流復(fù)制的方式，流復(fù)制的基礎(chǔ)是基于日志，或者是基于數(shù)據(jù)塊。復(fù)制方式有同步復(fù)制和異步復(fù)制，所謂同步復(fù)制是等主機(jī)返回請求之前一定要等到備機(jī)的日志可靠落地之后，它才會返回成功給客戶端。異步的話是主機(jī)事務(wù)日志落盤后，異步把日志發(fā)送到備機(jī)，不用等待備機(jī)事務(wù)的可靠落盤。同步和異步對外體現(xiàn)的主要是業(yè)務(wù)的RTO、RPO的影響。這種方式一般來講下，我們在主機(jī)上提供讀寫能力，在備機(jī)上提供只讀能力。

第二種容災(zāi)方式大家看到的比較多，主要是使用一致性協(xié)議來復(fù)制日志，也就是說每個寫入請求來的時候，它都會通過一致性協(xié)議進(jìn)行集群內(nèi)部的協(xié)商來達(dá)成最終的一致。這樣的架構(gòu)的好處是每個副本都可以寫入，但缺點(diǎn)也比較明顯，每個寫入都需要經(jīng)過若干次的網(wǎng)絡(luò)同步，效率其實(shí)要比基于流復(fù)制的容災(zāi)方式弱一些。因為它的每個副本都有完整的一個數(shù)據(jù)，而且都可以進(jìn)行導(dǎo)換，所以它的RTO表現(xiàn)會好一點(diǎn)。從這里其實(shí)我們可以看出來，數(shù)據(jù)庫容災(zāi)的本質(zhì)其實(shí)就是數(shù)據(jù)的多副本，各種方案的區(qū)別主要是在于多副本我們是怎么實(shí)現(xiàn)的。TBase多副本實(shí)現(xiàn)沒有使用一致性協(xié)議。

接下來給大家介紹下TBase運(yùn)維管控架構(gòu)，TBase作為一個分布式系統(tǒng)，整體的架構(gòu)是比較復(fù)雜。

我們需要一個運(yùn)維管控系統(tǒng)來保證整個系統(tǒng)的可靠運(yùn)行和高效的運(yùn)維。整個TBase的運(yùn)維管控系統(tǒng)如圖所示，圖中最上層是ETCD集群，即TBase的元數(shù)據(jù)管控集群。另外它提供一些控制中心的選主的能力。第二層是運(yùn)維管控中心，它實(shí)時的監(jiān)控集群的狀態(tài)，同時這里也可以去觸發(fā)一些故障處理邏輯。第三層是數(shù)據(jù)探活集群，這一層主要是有部署在每臺服務(wù)器上的Agent來完成，它會實(shí)時的去探測每個數(shù)據(jù)庫實(shí)例的健康度并進(jìn)行上報，同時它也會執(zhí)行上層的運(yùn)維管控中心下發(fā)的一些指令。最下層是數(shù)據(jù)庫實(shí)例，這一層其實(shí)是通過資源池化的方式來進(jìn)行資源隔離，同時內(nèi)部也進(jìn)行了一些容災(zāi)的控制。

這里我提一下數(shù)據(jù)庫里面比較重要的備份問題。我們?yōu)槭裁匆M(jìn)行冷備？

前一段時間發(fā)生的數(shù)據(jù)冷備被刪除，導(dǎo)致業(yè)務(wù)中斷估計大家還有印象。所謂的冷備其實(shí)也是數(shù)據(jù)庫安全的最后一套防線，我們一般什么時候用到冷備呢？經(jīng)常是在發(fā)生重大的誤操作的時候，比如說我不小心把庫刪了，或者說整個機(jī)房所有的副本都掛了，另外如果說數(shù)據(jù)做了惡意的修改或者篡改之后，需要把數(shù)據(jù)恢復(fù)到一定時間以前的數(shù)據(jù)，冷備是數(shù)據(jù)庫的最后一個保護(hù)傘，對數(shù)據(jù)庫來講是非常重要的。

冷備可能會存在的一些問題。

分布式場景下數(shù)據(jù)庫的冷備存在的問題和分布式事務(wù)存在的問題是很類似的。我們集群內(nèi)部會有多個節(jié)點(diǎn)在并行跑事務(wù)，最難搞的問題是在分布式冷備系統(tǒng)中如何找到一致性的恢復(fù)點(diǎn)。如圖，集群里有兩個節(jié)點(diǎn)DB1和DB2，冷備點(diǎn)1和4的，恢復(fù)就是一致的。冷備點(diǎn)2和冷備點(diǎn)3就是不一致的。整體一致點(diǎn)的選擇非常重要。如果選擇不當(dāng)就會造成數(shù)據(jù)的損失和不一致。

分布式數(shù)據(jù)庫里面，如何尋找一致的冷備點(diǎn)也有一些方法可以參考。

第一種是要求在做冷備的時候，通過設(shè)置事務(wù)柵欄來保證整個事務(wù)的一致性，我們會在所有的日志里面設(shè)置一致性標(biāo)簽，然后恢復(fù)的時候，指令說恢復(fù)這個標(biāo)簽就停下來，這樣可以保證整個事務(wù)的一致性。但是這里有一個缺點(diǎn)，在進(jìn)行一致創(chuàng)建的時候，必須得去阻塞或者延遲當(dāng)前事務(wù)的執(zhí)行，對系統(tǒng)的影響其實(shí)還是比較大的。TBase是通過時間戳的方式，每個事務(wù)都有一個時間戳，那么在選擇冷備點(diǎn)的時候，就可以決定說要恢復(fù)到某個具體的時間戳，通過事務(wù)的時間戳我們就可以很好的保證整個冷備恢復(fù)的一致性。

前面介紹了TBase在執(zhí)行和冷備及可靠性分析的設(shè)計，接下來介紹下TBase特有的安全能力，在支撐公司業(yè)務(wù)過程中摸索出來的一套比較有效的數(shù)據(jù)安全管理體系，我們管它叫MLS（multiple layer security）。

這個數(shù)據(jù)安全體系的基礎(chǔ)是三權(quán)分立，所謂的三權(quán)分立指的是：安全管理員、審計管理員、數(shù)據(jù)管理員三個角色在系統(tǒng)里面相互隔離。安全管理員主要是負(fù)責(zé)安全規(guī)則的制定；審計管理員主要負(fù)責(zé)審計規(guī)則的制定；數(shù)據(jù)管理員更多的相當(dāng)于我們之前的DBA的一個角色。這三個角色之間在權(quán)限上和能力上來講是完全隔離的，相互之間在功能上沒有交叉。安全管理員的安全規(guī)則會約束到審計管理員和數(shù)據(jù)管理員，然后審計管理員的審計規(guī)則會約束到安全管理員和數(shù)據(jù)管理員。接下來給大家分別介紹下：TBase的行級強(qiáng)制安全規(guī)則、列級的安全規(guī)則、數(shù)據(jù)脫敏和加密。

1、TBase的行級強(qiáng)制安全規(guī)則

行級安全規(guī)則保證在TBase中我們可以做到數(shù)據(jù)行級安全的權(quán)限控制。安全規(guī)則三元組：一個是level（安全級別），這個安全級別是從上往下兼容，也就是說我如果具有絕密級別的安全權(quán)限的話，我就可以獲取到機(jī)密、保密和公開級別的數(shù)據(jù)的一個訪問權(quán)限。第二個是Catalog/compartment（目錄控制Catalog/compartment，這是一個集合的概念。也就是說如果有了α、β和∑這三個對象整體的權(quán)限的話，我就可以單獨(dú)的去訪問只有α或者β或者∑其中一個或者幾個組合的數(shù)據(jù)。最后一個是Group（組），這個概念比較容易理解，類似于公司組織關(guān)系，上級節(jié)點(diǎn)具有下級節(jié)點(diǎn)的權(quán)限。

舉個例子，比如說上圖中的右邊是我們的數(shù)據(jù)，左邊是我們的用戶。

成都分公司總經(jīng)理能夠從級別這里看到所有的數(shù)據(jù)。但是他在目錄這個級別的話，他只能看到成都的機(jī)密級別以下的數(shù)據(jù)。同時，因為他的組里面有工程部和人力資源部，他只有這兩個，也就是說他能夠看到工程部和人力資源部的成都的數(shù)據(jù)。對于總部的人力資源總經(jīng)理的話，我們就會發(fā)現(xiàn)他能看到北京和成都的，也就是說能看到所有歸屬地的員工的人力資源里面的數(shù)據(jù)。對于董事長來講，一般董事長的級別能夠看到所有的安全級別的數(shù)據(jù)，他能看到北京和成都兩地的數(shù)據(jù)。在組的關(guān)系上來講，董事局一般是整個公司部門里面最高級的部門，所以他在組這個級別上，他就能看到他下屬所有部門的數(shù)據(jù)，也就是說對鋼鐵俠來講，他能看到整個公司全部的數(shù)據(jù)。通過這個安全規(guī)則我們就可以做到對數(shù)據(jù)做到行級的過濾、行級的保護(hù)。

2、TBase的列級安全規(guī)則

在TBase中是通過訪問控制列表來實(shí)現(xiàn)的，也就是說我們會在每一個列上加一個ACL的列表來指定這一列對誰有權(quán)限，誰沒有權(quán)限。

比如：我們在薪酬上設(shè)定說普通員工是沒有權(quán)限訪問，對蜘蛛俠或者普通員工來講的話，他看到的數(shù)據(jù)就只有他自己的數(shù)據(jù)。但是對于鋼鐵俠來講，因為鋼鐵俠是董事局的主席，他能看到這兩列所有的數(shù)據(jù)。通過行級權(quán)限控制和列級權(quán)限控制可以得出我們對表里面的數(shù)據(jù)能夠做到行和列的任意訪問的控制。

3、TBase數(shù)據(jù)脫敏和加密

脫敏和加密面對的場景有一些差別，加密主要面對的是數(shù)據(jù)文件本身的泄露，比如我的文件被別人拖走了，然后他通過代碼可以把數(shù)據(jù)解析出來。我們現(xiàn)在常見的數(shù)據(jù)庫的存儲格式基本上來講是屬于半公開的狀態(tài)。也就是說大家只要拿到了數(shù)據(jù)庫的數(shù)據(jù)文件，只要有一個數(shù)據(jù)程序就可以把它解析出來，我們要通過數(shù)據(jù)中心的加密防止泄露。脫敏主要指的是我的數(shù)據(jù)在訪問的時候，有些數(shù)據(jù)的用戶是沒有權(quán)限去看到它的明文的，但是它還用一些運(yùn)維的操作或者其他一些工作上的需要，他需要能訪問這些數(shù)據(jù)，但是他不需要真正看到這些數(shù)據(jù)，這兩個是完全不同的需求。加密在存儲層的時候，存儲的是密文，只有在執(zhí)行這個程序的時候才會對數(shù)據(jù)進(jìn)行解密和加密，然后把它反饋給用戶。對于脫敏的話，存儲的是明文，在buffer里面也是明文，只有在用戶訪問的時候，我們授權(quán)用戶、非授權(quán)用戶來進(jìn)行公平的處理。對授權(quán)用戶得到的就是完整的數(shù)據(jù)，對非授權(quán)用戶得到的數(shù)據(jù)就是脫敏以后的結(jié)果。加密和脫敏可以進(jìn)行混合的使用，也就是說我們既可以對存儲內(nèi)容加密，也可以針對不同用戶采用用戶的一個脫敏的規(guī)則，來保證我數(shù)據(jù)訪問的一個隔離。

下面針對TBase MLS透明脫敏和透明加密舉個例子。

我們有兩個脫敏和加密的規(guī)則，也就是說我們會針對非董事長用戶進(jìn)行加密的脫敏。脫敏之后的數(shù)據(jù)，我們可以指定一個任意的值來展示給這個非授權(quán)用戶?，F(xiàn)在我們對于這個非授權(quán)用戶，也就是說對于成都的分公司總經(jīng)理和總部人力資源總經(jīng)理，他們看到這兩個數(shù)據(jù)，一個是0，一個是1。但是對于董事長來講，因為他是超級用戶，他是沒有受到加密和脫敏的約束的，所以他看到的數(shù)據(jù)是正常的數(shù)據(jù)。通過這種方式我們就可以很好的來隔離系統(tǒng)里面不同等級用戶對于同樣一些數(shù)據(jù)看到的視圖，達(dá)到一個隔離的效果。

另外，跟大家分享下TBase MLS的審計能力。

TBase具備完整的審計能力：1、語句審計，對特定的語句類型進(jìn)行審計；2、對象審計，可以針對數(shù)據(jù)庫的某個對象，比如說一張表，或者一個數(shù)據(jù)庫，甚至一個索引來進(jìn)行一個審計。3、記錄用戶審計，記錄用戶所有的訪問。4、還有一個比較好玩兒的功能是TBase的一個系統(tǒng)的審計，我們可以做一些針對用戶自定義的審計規(guī)則，比如審計的時候，我們判斷如果用戶的余額大于這個值的時候，我們就會把它的審計結(jié)果記錄下來。同時我們還會自定義它的審計的一個動作，也就是說如果這個條件被觸發(fā)了之后，我們會去做什么事情。比如說上面這個例子是我們會調(diào)用一個發(fā)文件的功能來做我們的審計。

TBase客戶案例

下面介紹一下TBase的客戶案例。

TBase最早是在2016年初的時候替換了微信支付原有的分庫分表的MySQL集群。當(dāng)時大概每天只有500萬筆，后來支撐到每天數(shù)億筆。整個過程中我們保證了微信支付業(yè)務(wù)的連續(xù)性和穩(wěn)定性。

主要有幾個策略：

第一個是大小商戶策略。微信商戶系統(tǒng)，商戶業(yè)務(wù)不同于個人業(yè)務(wù)，存在大商戶和小商戶的區(qū)別。大商戶像大型的網(wǎng)購平臺，還有電商平臺，它都屬于大商戶。小商戶就是各種各樣的小店，他們的數(shù)據(jù)量不一樣的，所以我們需要對于不同的用戶量來進(jìn)行一個處理，來保證兩邊服務(wù)的質(zhì)量。

第二個是冷熱分離的策略，因為對于微信支付的系統(tǒng)來講的話，它的冷熱存活都是我們的訂單數(shù)據(jù)，都是跟錢相關(guān)的東西。這一塊來講的話，跟我們相關(guān)法律的要求，這些數(shù)據(jù)我們需要存儲四年以上。但是，其實(shí)對于其中的數(shù)據(jù)，絕大部分來講，比如說三個月以前的數(shù)據(jù)訪問量是非常低的，我們?nèi)绻际褂孟嗤拇鎯Σ呗?，我們整個集群有400多T的數(shù)據(jù)，如果都是用成本較高的SSD存儲，效率和成本之間不是最優(yōu)的結(jié)果。所以我們就需要一些針對最近3-4個月的熱數(shù)據(jù)和4個月以前的冷數(shù)據(jù)采用不同的存儲策略，來幫助業(yè)務(wù)降低成本，同時來保證我們業(yè)務(wù)的訪問效率。

第三是我們還為業(yè)務(wù)提供了一個跨城容災(zāi)的能力，來保證業(yè)務(wù)的連續(xù)性。

由于來訪問這個系統(tǒng)的業(yè)務(wù)有很多種，運(yùn)維的同學(xué)也會有潛在的不同的各種各樣的應(yīng)用程序，我們需要針對不同的應(yīng)用程序或者不同的用戶，來提供不同的數(shù)據(jù)視圖，來保證我數(shù)據(jù)整體的可靠性。這個是前面提到的第四是MLS的安全系統(tǒng)。

總結(jié)一下，微信支付整個集群大概是這么一個結(jié)構(gòu)。

圖中最上面是我們CLB，是騰訊內(nèi)部的一個負(fù)載均衡的組件。CLB下面是我們的接入節(jié)點(diǎn)，我們在內(nèi)部首先把數(shù)據(jù)會分為大商戶和小商戶，在下面可以看出來小商戶熱數(shù)據(jù)集群，小商戶冷是商戶冷數(shù)據(jù)集群，大商戶熱是大商戶熱數(shù)據(jù)集群，大商戶冷是大商戶冷數(shù)據(jù)集群。冷熱集群之間的差別在于說存儲設(shè)備是不一樣的。熱集群主要使用的是SSD的設(shè)備，冷集群使用的是普通的TS5的設(shè)備，降低存儲成本。整體來講的話，通過這種方式之后，我們就把我們整個集群的成本降低到了ICB存儲的四分之一左右，全部使用ICB存儲的四分之一。

在外部我們有一個比較大的保險公司，然后上線了200多個TBase實(shí)例在跑保險的核心業(yè)務(wù)，這里只展示了我們的部署架構(gòu)。

我們上面分為兩個平面，一個是讀寫平面，一個是只讀平面。讀寫平面，業(yè)務(wù)通過VIP來提供讀寫能力。我們的只讀平面通過業(yè)務(wù)VIP在多個節(jié)點(diǎn)做負(fù)載均衡，提供一個業(yè)務(wù)的只讀能力。然后TBase的數(shù)據(jù)在生成之后，我們還需要把這個數(shù)據(jù)同步到我們其他的一些系統(tǒng)里面去，比如說ES、INFORMIX、MONGODB或者說MySQL，甚至同步到Oracle里面去。同步到Oracle和INFORMIX里面去主要是為了保證業(yè)務(wù)切換的可靠性，也就是我們把數(shù)據(jù)再回寫回去，來保證這個切換過程中的穩(wěn)定性。需要補(bǔ)充一下，TBase在往這個后面同步數(shù)據(jù)的時候，其實(shí)我們是先通過自己的邏輯解析的數(shù)據(jù)，把數(shù)據(jù)解析成了Json格式，通過Kafka同步過去。

國產(chǎn)化能力建設(shè)

下面介紹一下TBase在數(shù)據(jù)庫國產(chǎn)化方面的工作。第一個，在國產(chǎn)化平臺上面，我們支持了國內(nèi)主要的平臺，包括華為的泰山，還有中標(biāo)麒麟。在操作系統(tǒng)這一塊的話，中標(biāo)麒麟已經(jīng)支持和UOS也在支持中。國產(chǎn)芯片這一塊， X86和ARM我們是支持的比較好的。

在國產(chǎn)化計劃這塊，一定會提到數(shù)據(jù)庫的異構(gòu)遷移，TBase現(xiàn)在已提供了完整的數(shù)據(jù)庫遷移服務(wù)。

主要分為兩部分，一部分是工具，在工具這一塊的話，我們有數(shù)據(jù)的遷移工具，數(shù)據(jù)遷移評估工具以及數(shù)據(jù)校驗的工具。同時我們還提供了專門的專家咨詢服務(wù)，專家咨詢的話，我們會有一些遷移評估，方案設(shè)計，改造建議，優(yōu)化建議等等。通過整體的解決方案，我們會把數(shù)據(jù)從原有的商業(yè)數(shù)據(jù)庫，包括Oracle、MySQL等等可以把它很可靠的同步到TBase里面來，來解決數(shù)據(jù)庫國產(chǎn)化替換的一個數(shù)據(jù)遷移的問題。

在硬件這一塊的話，現(xiàn)在我們常見的幾種硬件進(jìn)行了性能的評測，下面是評測結(jié)果。

在前面提到的X86環(huán)境下的話，我們在服務(wù)器上跑了68萬TPM。然后LinuxOne能跑127萬，測試結(jié)果跟服務(wù)器的配置有關(guān)系。說到數(shù)據(jù)庫的國產(chǎn)化替換，肯定是繞不開Oracle兼容的，Oracle兼容TBase做了相當(dāng)多的工作，包括我們的對象的支持，數(shù)據(jù)類型的支持，函數(shù)，SQL特性和存儲過程。這一塊我們后續(xù)會進(jìn)行一些增強(qiáng)和擴(kuò)展，來提升我們的兼容度。

>>>>

Q & A

Q1：分布式表的庫備份，所有的DN都要獨(dú)立備份一份嗎？

A：TBase每個DN是整個數(shù)據(jù)庫的數(shù)據(jù)的分片，所以說在備份的時候，至少每個DN是要備份一份出來的，但是它不是獨(dú)立的一份，因為在備份邏輯里面會控制保障整個集群的完整性，也就是各個DN之間，每個DN都會有一個相應(yīng)的副本存儲到冷備里面去。

Q2：冷備這塊最大一致時間戳方式，會不會因為服務(wù)器之間的時間差異造成備份不一致？

A：冷備的時間戳問題，我覺得這個不用擔(dān)心，分享中我提到有5種方式：1）分布式快照隔離；2）絕對物理時間隔離；3）硬件絕對物理時間隔離；4）本地時間隔離；5）邏輯時間戳的隔離。TBase使用的是邏輯時間戳，這個時間戳不是本地的時間戳，是TBase內(nèi)部的時間戳，我們會保證它的穩(wěn)定性和單向遞增，它不會發(fā)生反轉(zhuǎn)，也不會發(fā)生偏移，而且它有容災(zāi)的特性。即使機(jī)器發(fā)生故障，然后再把它拉起來，它也是能保證整個穩(wěn)定性的。

Q3：時間戳是個全局自增值嗎？gtid？

A：至于說這個時間戳是不是一個自增值，簡單理解上，說是自增值是沒有問題的。但是核心問題是我們需要保證它，不能讓它有全局瓶頸，不能讓它因為一把鎖，把它全局吞吐量都拉下降了。

Q4：安全控制方式上，select 如何輸入token?

A：TBase的安全控制方式更多的是通過用戶的接口，比如說安全管理員，他會有自己的一套接口來創(chuàng)建自己的密鑰，創(chuàng)建自己的安全規(guī)則。

Q5：冷熱數(shù)據(jù)分離是通過人工方式做的還是自動方式？判斷冷熱數(shù)據(jù)的標(biāo)準(zhǔn)是啥？有沒有采用存儲分層的能力自動來判斷？

A：至于冷熱分離的轉(zhuǎn)儲是存儲層的設(shè)置策略還是在云數(shù)據(jù)庫層去做，其實(shí)冷熱轉(zhuǎn)儲這一塊，冷熱的訪問邏輯和邏輯的定義是在數(shù)據(jù)庫里面定義的，但是冷熱的轉(zhuǎn)儲，是通過TBase的管控系統(tǒng)來做，這個邏輯相對來講還是比較重，我們需要有一些專門的機(jī)制來保障它的可靠性和易用性，所以TBase整個把它移到了管控系統(tǒng)里面來。

冷熱分離的方式是人工去定義的，我們根據(jù)的業(yè)務(wù)邏輯來定義哪個數(shù)據(jù)是冷，哪個數(shù)據(jù)是熱的。但是它的判斷，它下層的遷移的邏輯是自動的，只要把這個規(guī)則定義好了之后，整個系統(tǒng)會自動的運(yùn)行，不需要人為干預(yù)。

判斷冷熱的標(biāo)準(zhǔn)是什么，舉個例子，比如說微信支付是四個月的數(shù)據(jù)是熱數(shù)據(jù)，四個月之前的數(shù)據(jù)是冷數(shù)據(jù)，其實(shí)是按照時間來判斷的，我們?nèi)‘?dāng)前的時間往前面算，往前面偏移。超過了一定的閾值它就是冷數(shù)據(jù)。

關(guān)于存儲分層之后，TBase更多是從數(shù)據(jù)庫本身的能力來做。

Q6：備份工具是原生內(nèi)置的嗎？

A：TBase的備份工具不是數(shù)據(jù)庫內(nèi)置的，是我們在管控里面做的，說句實(shí)在話，冷備這一塊東西需要打交道的周邊模塊比較多。比如需要把冷備的數(shù)據(jù)同步到一個外部存儲里面，外部存儲有可能是一個磁盤陣列，有可能是一個HDFS，也有可能是一個其他的存儲，這些東西放在數(shù)據(jù)內(nèi)核里面不合適，太重了，冷備功能是我們提供的獨(dú)立工具來做的。

Q7：TBase本身就是一個數(shù)據(jù)庫引擎，它不是一個數(shù)據(jù)庫中間件？

A：TBase本質(zhì)上是一個數(shù)據(jù)庫引擎。今天我講的PPT里面，大家可以看到，整個過程中其實(shí)我都沒有提中間件，一直在講數(shù)據(jù)庫底層引擎的一個原理，比如說優(yōu)化器的原理、執(zhí)行器的原理，還有分布式優(yōu)化邏輯，以及我們的分布式事務(wù)的邏輯，其實(shí)都是引擎里面的原理。中間件一般只會做SQL解析、SQL轉(zhuǎn)發(fā)和結(jié)果的返回，很少涉及到執(zhí)行計劃。

Q8：PUSH QUERY和PULL DATA如何選擇？

A：其實(shí)PUSH QUERY和PULL DATA這個選擇沒有一個嚴(yán)格的界限，一般PUSH QUERY在數(shù)據(jù)量相對比較大的時候會比較有效一點(diǎn)，因為把QUERY下推之后，下層節(jié)點(diǎn)的執(zhí)行會過濾掉大部分?jǐn)?shù)據(jù)，拉取的數(shù)據(jù)量大大的減小。然后PULL DATA在一些簡單的查詢，表非常小的時候，把它拉回來算可能更快一點(diǎn)。這一塊選擇沒有嚴(yán)格的標(biāo)準(zhǔn)，可以根據(jù)我們的場景決定。

Q9：如果是從Oracle轉(zhuǎn)到分布式數(shù)據(jù)庫有哪些知識需要補(bǔ)充？

A：說實(shí)在話， Oracle是一個發(fā)展了三四十年的數(shù)據(jù)庫產(chǎn)品，整體的架構(gòu)和功能都非常強(qiáng)大了。分布式數(shù)據(jù)庫是一個新興的領(lǐng)域，產(chǎn)品架構(gòu)，包括它的生態(tài)也都是一直處于建設(shè)和完善中，因此在調(diào)優(yōu)、使用和數(shù)據(jù)業(yè)務(wù)的建模這一塊跟以前的Oracle還是有所區(qū)別的。從哪一塊入手，我覺得這要看你使用的是哪些分布式數(shù)據(jù)庫。如果是MPP的話，可能就需要了解一下MPP里面的關(guān)鍵點(diǎn)。比如數(shù)據(jù)的分片怎么分，跑SQL的時候，怎么去結(jié)合分布邏輯去很好的設(shè)計SQL，這個可能是在接觸分布式數(shù)據(jù)庫的時候需要考慮的一個比較重要的問題。

Q10：兩個大表分布在不同的DN，做HASH，如何保證選擇正確的執(zhí)行計劃和高效率？

A：兩個大表分布在不同的節(jié)點(diǎn)里面，我們要進(jìn)行一個查詢，如何提升它的效率。如果兩個大表，首先第一個來講，我們得搞清楚這些表進(jìn)行查詢的時候關(guān)聯(lián)的KEY有哪些。比如說如果我們都是使用這一列進(jìn)行關(guān)聯(lián)，那是不是可以在設(shè)計的時候就按照性能這一列進(jìn)行數(shù)據(jù)的分片，在進(jìn)行查詢的時候，就可以下推到每個DN節(jié)點(diǎn)來執(zhí)行，換句話說每個DN節(jié)點(diǎn)的執(zhí)行層是并行的，沒有相互之間的交互，這樣效率在分布式的時候是最高的。

如果這個表查詢的SQL非常多，一張表有一兩百個字段，但是關(guān)聯(lián)的時候，有的是按照分布KEY進(jìn)行關(guān)聯(lián)，有的不是按照分布KEY進(jìn)行關(guān)聯(lián)，這個時候就得有一些取舍。要看一下，如果按照分布KEY進(jìn)行關(guān)聯(lián)效率會最高，而且可能會比不按照分布KEY的效率高不少，那么我們會選擇優(yōu)先的把我們業(yè)務(wù)里面用到的一些頻率比較高的，要求比較高的一些SQL優(yōu)先的按照那些SQL來設(shè)計表的分布方式。然后對于其他的一些SQL，對于那些JOIN的列進(jìn)一步建索引，提升查詢效率。

另外在寫SQL的時候，盡量做到某個節(jié)點(diǎn)上進(jìn)行查詢的時候，能夠通過我們表達(dá)式的過濾掉一些無效的數(shù)據(jù)傳輸，這樣的話就可以保證一個相對比較好的效率。

Q11：學(xué)習(xí)分布式數(shù)據(jù)庫有哪些知識要補(bǔ)充？從哪里開始？

A：至于說這些數(shù)據(jù)庫知識有哪些需要補(bǔ)充，我覺得是這樣的，數(shù)據(jù)庫本身是一個比較古老的技術(shù)，如果說從哪里開始，有機(jī)會的話，從使用開始就最好了。比如說先做一些最簡單的數(shù)據(jù)庫的使用，建表、生成數(shù)據(jù)，最好有一個業(yè)務(wù)系統(tǒng)作為驅(qū)動，邊用邊學(xué)，這樣上手更快一些。

Q12：TBase代碼開源了嗎？

A：TBase的代碼已經(jīng)開源，大家有興趣的話，歡迎訪問：https://github.com/Tencent/TBase。TBase預(yù)計今年年中左右會重新推動一個新的版本出來，大家敬請期待。

---

薦：

【中國風(fēng)動漫】除了《哪吒》，這些良心國產(chǎn)動畫也應(yīng)該被更多人知道！

聲明

來源：DBAplus社群，人工智能產(chǎn)業(yè)鏈聯(lián)盟推薦閱讀，不代表人工智能產(chǎn)業(yè)鏈聯(lián)盟立場，轉(zhuǎn)載請注明，如涉及作品版權(quán)問題，請聯(lián)系我們刪除或做相關(guān)處理！