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

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

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

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

一般我們?cè)谡務(wù)摂?shù)據(jù)庫(kù)的時(shí)候，首先會(huì)問數(shù)據(jù)庫(kù)是OLAP還是OLTP？

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

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

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

二、按照時(shí)間劃分

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

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

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

三、按照架構(gòu)

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

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

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

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

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

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

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

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

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

接下來(lái)跟大家分享下TBase的整體情況，先從TBase的簡(jiǎn)史說起。

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

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

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

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

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

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

講分布式事務(wù)之前首先講下Sharding模式存在的問題。這里舉個(gè)例子，我們現(xiàn)在有AB兩個(gè)帳戶，每個(gè)帳戶余額是10元，兩個(gè)帳戶總額是20元，我們對(duì)這兩個(gè)帳戶之間進(jìn)行轉(zhuǎn)帳，從B往A轉(zhuǎn)5元，并發(fā)量很大的時(shí)候，如果是一個(gè)一致性保持的比較好的系統(tǒng)，那么無(wú)論我們有多少的并發(fā)，兩個(gè)帳戶的總額應(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)隊(duì)有比較強(qiáng)的開發(fā)能力，可以讓業(yè)務(wù)代碼處理上面遇到的問題，把數(shù)據(jù)庫(kù)作為一個(gè)簡(jiǎn)單的數(shù)據(jù)容器來(lái)處理。但對(duì)于一些普通用戶或者普通場(chǎng)景的話，就不一定具備互聯(lián)網(wǎng)公司的資源和技術(shù)能力了。在TBase中，我們也是需要處理分布式事務(wù)的一致性問題，為業(yè)務(wù)屏蔽掉事務(wù)的相關(guān)細(xì)節(jié)。
這里我分享下TBase分布式事務(wù)系統(tǒng)的目標(biāo)。

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

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

一、分布式的快照隔離

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

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

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

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

基于物理時(shí)間有兩種方式：

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

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

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

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

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

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

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

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

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

下面分享一下TBase在行存儲(chǔ)和列存儲(chǔ)這一塊的一個(gè)選擇。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

冷備可能會(huì)存在的一些問題。

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

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

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

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

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

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

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

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

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

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

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

比如：我們?cè)谛匠晟显O(shè)定說普通員工是沒有權(quán)限訪問，對(duì)蜘蛛俠或者普通員工來(lái)講的話，他看到的數(shù)據(jù)就只有他自己的數(shù)據(jù)。但是對(duì)于鋼鐵俠來(lái)講，因?yàn)殇撹F俠是董事局的主席，他能看到這兩列所有的數(shù)據(jù)。通過行級(jí)權(quán)限控制和列級(jí)權(quán)限控制可以得出我們對(duì)表里面的數(shù)據(jù)能夠做到行和列的任意訪問的控制。

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

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

下面針對(duì)TBase MLS透明脫敏和透明加密舉個(gè)例子。

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

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

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

TBase客戶案例

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

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

主要有幾個(gè)策略：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>>>

Q & A

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

A：TBase每個(gè)DN是整個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)的分片，所以說在備份的時(shí)候，至少每個(gè)DN是要備份一份出來(lái)的，但是它不是獨(dú)立的一份，因?yàn)樵趥浞葸壿嬂锩鏁?huì)控制保障整個(gè)集群的完整性，也就是各個(gè)DN之間，每個(gè)DN都會(huì)有一個(gè)相應(yīng)的副本存儲(chǔ)到冷備里面去。

Q2：冷備這塊最大一致時(shí)間戳方式，會(huì)不會(huì)因?yàn)榉?wù)器之間的時(shí)間差異造成備份不一致？

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

Q3：時(shí)間戳是個(gè)全局自增值嗎？gtid？

A：至于說這個(gè)時(shí)間戳是不是一個(gè)自增值，簡(jiǎn)單理解上，說是自增值是沒有問題的。但是核心問題是我們需要保證它，不能讓它有全局瓶頸，不能讓它因?yàn)橐话焰i，把它全局吞吐量都拉下降了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Q12：TBase代碼開源了嗎？

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

---

薦：

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

聲明

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