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

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

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

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

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

在TBase里面，在MPP的架構下，我們具備了并行計算的架構基礎。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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