歡迎大家前往騰訊雲+社區，獲取更多騰訊海量技術實踐幹貨哦~

作者：jasonys，隸屬於騰訊技術工程事業群數據平臺部，負責TBase數據的技術研發和架構設計，有超過10年的數據庫內核開發設計經驗，完成多種數據庫的架構設計和開發。

2017年PGXZ改名為TBase，以發布會的方式正式對外進行了發布，經過團隊小夥伴們的努力，TBase V1版本到目前在公司外部市場上的客戶包括了政務，公安，消防，電信，金融等行業的十幾家客戶。TBase以其功能強大，運行穩定，和強大的互聯網基因得到客戶的普遍認可。在和外部客戶的接觸中，聽到了很多贊美的聲音，也有不少希望TBase能夠解決客戶更多痛點的期望。

2017年中TBase團隊結合客戶的需求和數據庫技術的最新發展趨勢，經過相當長時間的規劃和討論，在PostgreSQL最新版本V10.0的基礎上規劃了TBase V2版本，希望能夠代表騰訊最新最強的數據庫技術，來滿足客戶的需求，解決客戶業務運行中的痛點。

在接下來的8個多月裏，數平小夥伴們夜以繼日，終於完成TBase V2核心的開發，這個凝結了數平小夥伴們數百個晝夜辛勤工作的版本終於要和大家見面了，很高興能能在這裏給同學們介紹TBase V2的核心概念和架構。

TBase V2核心概念

TBase V2的重要的技術特性和概念，主要包括以下幾個方面：

企業級：企業級特性包含以下幾個方面：

• 用戶友好的事務特性：業務無需關註數據庫的事務特性，數據庫內核支持完整的分布式事務，保證事務的ACID。
• 用戶友好的數據庫特性：主鍵，外鍵，序列，約束，分區表，存儲過程，觸發器，子查詢等企業級的特性完整支持。
• 用戶友好的SQL接口：當前TBase V2能夠兼容SQL2003標準，同時還能夠兼容常見的ORACLE語法，可以方便ORACLE深度用戶的遷移，當前在外部已經有ORACLE遷移的案例。
• 用戶友好的分布式查詢能力：良好的分布式查詢支持能力，數據庫內核能夠高效的處理分布式JOIN。

NewSQL數據庫：相對傳統的數據庫產品，TBase能夠做到高效的在線線性擴容，在集群規模發生變化的時候不會影響到業務的運行。

HTAP能力： Hybrid Transactional/Analytical Processing，即事務和分析混合處理技術，這個技術要求本來資源訴求矛盾的兩種業務類型在同一個數據庫中完成處理。TBase V2經過專門的設計完美的做到了HTAP，同時具備了高效的OLAP能力和海量的OLTP處理能力。

下面是我們測試的事務測試模型TPCC的benchmark測試結果，系統在每分鐘完成的事務量超過310萬，更大規模集群的測試還在進行中，從當前的架構設計來看，在硬件允許的情況下，系統的事務吞吐量會隨著集群規模準線性提升：

下面這張圖展示了TBase在行存儲模式下和業界MPP數據倉庫標桿在OLAP測試集合TPCH 1Tbenchmark下的對比情況：

通過這張圖可以直觀的看到TBase的OLAP分析能力，TBase在22個用例中每個用例的耗時都優於我們的競品，部分用例耗時大幅度的超過對方。

通過HTAP技術，業務可以在單一的TBase集群中同時處理OLTP類交易和OLAP類分析。通過HTAP，可以大幅度的減少業務系統的復雜度，降低運維成本。

高數據安全：

在和客戶交流的過程中，多個行業的客戶都提到了數據安全的訴求，TBase團隊結合客戶的需求和業界先進的數據庫安全解決方案設計了TBase V2的數據安全體系。這個體系主要包含以下幾個方面：

• 三權分立：把數據庫系統dba的角色分解為三個相互獨立的角色，安全管理員，審計管理員，數據管理員，這個三個角色之間相互制約，消除出系統中的上帝權限，從系統角色設計上了解決了數據安全問題。
• 強制安全規則：結合業界先進的數據庫安全解決方案，TBase V2提出了強制安全規則解決方案，通過安全管理員制定的強制安全規則，可也做到行級可見和列級可見，進而限制用戶看到的數據，對不同的用戶做到權限的行列混合控制，有效的杜絕數據越權查看，保證關鍵數據的安全性。
• 透明數據脫敏管理：對於金融，安全等對數據安全有特殊要求行業，經常會有數據脫敏的訴求，但是現有的解決方案很多都需要有業務的參與，要求業務深度的參與，有一定的門檻。TBase針對這個痛點進行了專門的設計，做到業務的透明脫敏，業務只需要根據自己的業務規則結合TBase的脫敏語法，設計業務邏輯。TBase內部就可以做到數據的脫敏，同時結合上面提到的強制安全規則，安全管理員可以做到指定數據脫敏的針對用戶，最終達到高安全級別的用戶看到的是非脫敏的數據，低安全級別的用戶看到的是脫敏後的數據。
• 審計能力：在與客戶交流的過程中，眾多客戶都提到了數據庫審計的訴求，TBase V2在設計的過程中，結合業界標桿的審計標準設計了自己的審計系統，在內核中實現了審計的核心功能，做到在兼顧高精準的審計粒度的同時還能保證系統的性能。同時針對一些業務中遇到的問題，設計專門的解決方案，做到審計結果的實時通知。

多租戶能力：

TBase提供集群級和集群用戶級兩個級別的多租戶能力。通過集群級的多租戶能力，可以幫助業務快速的建立一個數據庫私有雲，幫助客戶快速提供基於TBase的DRDS服務。集群級的多租戶能力架構如下圖：

除此之外，TBase數據庫集群內部還提供基於節點組node group的集群內多租戶解決方案，做到數據庫集群內部的業務和資源隔離，多個業務在Tbase內部相互隔離的運行。下圖APP1，APP2，APP3同時在一個數據庫集群內部運行，相互之間通過group進行隔離，互不影響。

TBase產品架構

上面總體上介紹了TBase V2的技術特性，第一次接觸TBase的同學還是有點不明所以，為了方便小夥伴們的理解後面的內容，這裏把TBase整體架構介紹下。V1和V2在整體架構上是類似的:

集群中有三種節點類型，各自承擔不同的功能，通過網絡連接成為一個系統。這三中節點類型分別是：

• Coordinator：協調節點，對外提供接口，負責數據的分發和查詢規劃，多個節點位置對等，每個節點都提供相同的數據庫試圖；在功能上CN上只存儲系統的全局元數據，並不存儲實際的業務數據。
• Datanode：處理存儲本節點相關的元數據，每個節點還存儲數據的一個分片。在功能上，DN節點負責完成執行協調節點分發的執行請求。
• GTM:全局事務管理器(Global transactionmanager.)，負責管理集群事務信息，同時管理集群的全局對象，比如序列，除此之外GTM上不提供其他的功能。

通過上面的架構，TBase提供了一個具有友好接口的數據庫集群。這個數據庫集群架構上具有如下優點：

• 寫可擴展 (Write-scalable)：可以部署多個CN，並且同時向這些節點發出寫操作。
• 多主節點 (Multi-master )：系統的每個CN節點都可以發起寫入操作，並都可以提供統一完整一致的數據庫視圖；
• 數據自動同步（Synchronous)：對於業務來說，在一個CN節點的寫入操作會立刻呈現在其他的CN節點上；
• 數據透明（Transparent）：是指數據雖然存在於不同的DN節點中，業務在通過CN查詢數據庫時，還是可以像使用普通的數據庫一樣編寫SQL語句，不必關心數據位於具體的節點，TBase數據庫內核自動完成SQL的調度執行，並保證事務特性。

TBase V2特性詳解

V2 OLAP能力提升：

說到OLAP能力的提升，首先要講下TBaseV1和V2在處理OLAP類請求時的差異，V1和V2在處理OLAP請求時的差別主要有執行方式和DN節點之間是否相互通信兩個方面：

執行方式：V1中執行OLAP類請求時CN下發到DN的是SQL語句，DN負責SQL語句的規劃和執行，然後向CN上報結果，CN完成結果的匯總。V2中，CN收集集群的統計信息，對OLAP類的查詢規劃集群級的分布式查詢計劃，並下發到各個DN上進行執行，也就是說CN下發的是執行計劃，DN只負責執行而已。

DN之間是否交換數據：V1中，DN之間相互沒有通信通道，無法進行數據交換。V2版本在DN節點之間建立了高效數據交換通道，可以高效在DN節點之間交換數據。

差異如下圖所示：

在V2 OLAP框架的基礎上，我們開發了一整套完整高效的多線程數據傳輸機制，在運行OLAP查詢時，這套框架保證數據可以高效的在節點之間完成同步，大幅的提升OLAP處理效率。

在算法層面，基於PG10具備的多核並行執行能力，我們在集群環境下系統性的重新設計了常用的JOIN，AGGRATE算法，得以充分發揮現有硬件的性能，在同樣的集群規模下，測試OLAP benchmark TPCH 1T，在行存儲模型下，平均性能超過業界標桿2到5倍。

OLTP能力優化提升：

GTM是TBase集群中負責處理事務信息的模塊，它的處理能力直接決定了系統的事務吞吐量。而且GTM是系統中唯一的單點，它的處理上限直接影響到系統處理能力的天花板。

為此我們對GTM進行了專門的優化和設計。主要集中在以下四個方面：

• 網絡帶寬的優化，取消系統的集群快照，改為邏輯時鐘來判斷事務的集群可見性，大幅減少對GTM的網絡帶寬的占用，同時還降低了GTM的CPU占用。
• CPU使用率的優化，通過線程資源復用的方式大大，減少GTM的線程數據，減少系統調度CPU占用率，大幅的提升GTM的處理效率。
• 系統鎖的優化，在系統吞吐量達到百萬級時GTM原來使用的系統互斥鎖占用了絕大多的CPU，我們編寫了用戶態的互斥鎖，使得CPU使用率只有原來的十分之一，提升了系統的處理能力上限。
• 免鎖隊列的使用，使用免鎖隊列取代原來的帶鎖隊列，減少系統的鎖使用，大幅提升系統的處理效率。

除此之外我們還提出了具有專利的分布式事務一致性技術，來保證在全分布式環境下的事務一致性。通過上面的這些優化，TBase單機群的TPCC事務處理能力得到大幅度的提升，而且處理能力會隨著集群規模準線性提升。下面是我們在60臺集群規模下測試的tpcc結果，最大吞吐量達到310W每分鐘，此時系統DN,CN資源吃緊，但是GTM資源仍有相當多的剩余，因此隨著集群規模的增加，系統的吞吐量還可以繼續提升。

TBase V2 HTAP處理能力：

在講TBase的HTAP能力之前，先分析下當前市面上主流分布式數據庫架構在HTAP方面的能力，我們這裏不討論諸如Exadata，HANA之類的一體機解決方案。

首先講下在互聯網公司常見的sharding分布式架構：

這種架構通過物理上的分庫分表把多個單機數據庫實例使用中間件提供統一的數據庫訪問接口，達到分布式數據庫的效果。這種架構在處理簡單的SQL請求時具備一定的競爭力，但是對於處理復雜的分布式join和子查詢等復雜SQL往往力不從心，因此不太擅長從事HTAP類的業務處理。

第二種架構，經典的MPP架構，典型的產品是PivotalGreenplum，這種架構中只有一個單Master節點，使用主用數據節點提供查詢服務，該架構為OLAP而生，因為單Master的問題，系統的處理能力受限於master的處理能力，而且系統鎖最小粒度為表級，直接影響到事務的處理能力，這種架構只適合用來處理OLAP類業務，不適合處理OLTP類業務。

上面講了sharenothing的架構，後面分析下share everything架構，這個架構如下：

典型的產品有Sybase IQ，Oracle RAC。Sybase IQ作為一款經典的數據倉庫產品，曾經風靡一時，現在數倉的很多概念和解決方案在Sybase IQ中都能找到實現，由於在設計之初就定位為一個數據倉庫產品，因此架構上沒有考慮處理事務類請求，只能用來處理OLAP類請求。

對於ORACLE RAC，作為當前還是很火的數據庫產品，在處理OLAP和OLTP請求方面都有不錯的表現，但是因為本身以及配套硬件昂貴的價格和擴容時復雜而冗長的流程，被很多的客戶抱怨。

分析完了業界的解決方案，基本得出一個結論，我們需要一個可以同時高效處理OLTP和OLAP業務，而且兼顧易用性和低成本的HTAP分布式解決方案，現有的解決方案很難滿足我們的需要。除了基本的能力，還有一個需要註意的問題是，OLTP類請求關註時延和吞吐量，而OLAP關註時延，兩者因為關註點的不同在資源使用模型上完全不同，因而如何在同一個集群內部同時高效處理這兩種業務並很好的做到資源隔離成為一個棘手的問題。

TBase團隊在綜合考慮了以上的各種因素後，仔細的設計了TBase的HTAP解決方案，整體架構如下：

TBase把HTAP分為兩種場景：

CASE 1，OLAP和OLTP訪問不同的業務數據，在這個場景下，我們可以使用TBase的group隔離技術，在天然滿足物理隔離的基礎上讓TBase分別發揮高效的OLAP和海量OLTP能力。

CASE 2，OLAP和OLTP訪問相同的數據，在同樣一份數據上需要同時進行OLTP和OLAP兩種操作，而且還需要同時保證兩者的效率。此時為了達成資源的隔離，TBase使用DN主機運行OLTP業務，使用專門的OLAP備DN節點運行OLAP業務，達成天然的資源隔離的效果。

TBase安全架構介紹

TBase團隊在和客戶交流的過程中，多個行業的客戶都對數據安全提出了訴求，TBase針對業務的痛點並結合數據庫行業領先的數據庫理念設計了TBase的安全體系。

TBase數據安全體系以數據庫三權分離為基礎，把傳統DBA的權限分解為安全管理員，審計管理員，數據管理員。在安全規則領域針對安全管理員增加了安全規則和數據透明脫敏規則，在審計方面結合業界審計標準和業務的場景需要，增加了對象審計，用戶審計，以及細粒度審計。除此之外的數據管理員則履行之前DBA的數據管理和數據庫運維職能。

下面對這幾個部分進行下介紹。

安全架構之--TBase三權分立：

TBase的安全體系分為以下幾個層次，首先在系統的角色上進行了分解，把備受詬病的DBA超級權限進行了分解，分為了安全管理員，審計管理員，數據管理員，這個做法業界叫做“三權分立”，如下圖：

這個三個角色可以對應到美國的三權分立的政治體制：

安全管理員（立法權）：

? 制定強制安全訪問策略。

? 強制安全訪問策略由安全員獨立完成。

? 系統所有用戶都要遵守強制安全訪問策略。

審計管理員（司法權）：

? 系統所有操作都被記錄，包括安全員，管理員的操作。

? 審計策略由審計管理員單獨制定。

? 審計員本身的操作也會強制記錄，不可修改。

數據管理員（行政權）：

? 具備自主訪問控制權。

? 不可幹預審計員和安全員的動作

通過這三個角色的劃分，從根本上杜絕了系統的安全死角，安全管理員負責整體安全規則的制定，通過這種方式來約束系統中的所有角色。審計管理員負責指定審計規則，審計系統中包括審計管理員在內的所有角色，做到系統所有操作的可追溯。而數據管理員則負責數據庫的日常運維。三者之間相互約束，相互監督。

TBase安全架構之—強制訪問規則：

強制訪問規則聽起來有點抽象，我這裏拿一個具體的例子來講，一個公司的員工信息如下表：

對於公司的董事長來說，我們給他的安全規則是看到系統的所有的數據，因此他看到這張表裏面的數據是這樣的，完整的數據而且沒有經過處理：

安全規則規定工程部總經理只能看到工程部自己員工的相關數據，因為薪酬和員工私人信息是高安全級別數據限制對他開放，因此他看到的這張表的數據是這樣的：

對於工程部員工張三來說，系統通過訪問規則限制他只能看到自己的數據，因此他在系統中通過select看到的數據是這個樣子：

這裏張三可以看到自己的薪酬數據。

TBase提供了完整的安全規則SQL命令來讓安全管理員可以很方便的定義安全規則，通過這些安全規則就可以做到數據行列混合訪問控制。

TBase安全架構之—透明數據加密和脫敏：

經常有客戶會給我們提安全相關的問題，一個問題是：數據業務托管在某個服務商那裏，表中的有些列的內容不想讓服務商看到，但是服務商為了運維他們的業務又需要知道表結構，問我們有沒有很好的技術手段來解決這個問題。另外一個常見的問題是：如果數據庫文件被人拖走了，我們如何保證數據的安全性。針對這一類的需求我們設計了TBase的透明加密和脫敏系統，來全放方位保證用戶數據的安全性。

針對這些數據安全類的需求，TBase設計了數據的透明加密和透明脫敏特性。透明加密和透明脫敏功能可以單獨使用也可以組合使用。區別和原理如下：

透明加密：主要是預防數據文件泄漏後發生的數據泄漏，因此我們在存儲層的文件中存儲的是加密後的數據，對與上層業務訪問來說，業務讀取到的都是明文。

透明脫敏：透明脫敏是強制訪問規則的一部分，因此脫敏規則是針對具體的數據庫角色建立的。對於授權用戶來說，可以正常的讀寫數據庫表中的數據，對於非授權用戶來說，他只能看到數據脫敏後的結果，這樣可以有效的防止非授權被非法讀取。

透明加密+透明脫敏：這種方式下，在磁盤上存儲的是密文，可以防止數據文件泄漏後用戶數據的泄漏，同時還通過強制安全規則來避免非授權的數據訪問，做到存儲層和業務層兩個緯度的數據安全。

這裏還拿上面的數據做為例子，假如透明脫敏安全規則約束薪酬，個人信息，家庭住址，年齡四個列對DBA進行數據透明脫敏，那麽DBA在查詢這張表時，看到的數據就是這樣的：

從圖中可以看到，脫敏後的數據都被顯示成了系統默認值，DBA是不能看到這個列的值，而且也沒有其他的辦法來試探這個列的真實值。

TBase安全架構之—審計：

結合業界先進的解決方案和做法，我們把TBase的審計分為以下幾種：

• SQL審計：對特定的SQL語句進行審計，與具體的對象沒有關系。只針對具體的SQL類型。語法格式如下：

sql_statement_shortcut即SQL審計的內容，這裏重點介紹下，ALL包含了下表的審計項，基本上是DDL statements。下面是審計statement列表。

• 對象審計，審計指定對象的指定SQL類型，也就是在指定對象上細化上面的審計情況。動作如下圖。

TBase的審計采用獨特的設計架構，審計運行的過程中，對系統的性能影響很小。細粒度審計，這種審計方式比較靈活，可以對數據設置過濾條件，如果滿足條件的數據被訪問了就會觸發審計動作，審計動作可以是系統的標準動作，也可以是用戶的自定義動作，比如告警，發短信，發郵件之類的。

TBase的審計采用獨特的設計架構，審計運行的過程中，對系統的性能影響很小。

TBase V2d多租戶能力

TBase作為一個企業級的分布式數據庫，還提供了企業常常用到的多租戶能力，讓客戶可以在一個數據庫環境運行多個業務，TBase負責多個租戶之間的隔離，做到業務之間的相互無影響。

TBase的多租戶整體架構如下：

TBase的多租戶管理分為三個層級，最底層是資源管理層，這一層管理基礎的物理機，並對物力進行資源切片和池化以及各個分片之間的隔離，同時還負責對上層的資源分配和釋放。

第二層是租戶管理層，這一層負責租戶內部的權限管理，每個租戶內部都有一個完整的三權分立體系，每個租戶可以對應多個項目，每個項目對應一個集群，集群對物理資源的存放位置不感知。每個租戶只可以看到自己相關的項目和集群。

最上面一層是系統管理，這一層負責租戶和集群的創建，並管理整個平臺的資源分配和釋放，這一層可以看到整個平臺的租戶和集群，以及物理機的狀態信息。

在系統提供的集群級多租戶外，在單個TBase集群內部，還提供了基於節點組的集群內部多租戶解決方案能力。例如如下圖：

在一個數據庫集群內部，三個APP業務使用不同的節點組和各自單獨的CN來做到資源的隔離，完美的實現集群內部的多租戶。

通過上面兩種解決方案，業務可以根據自己的需要搭建合適的多租戶環境，快速部署業務。

TBase V2 在線彈性擴容：

對於一個分布式系統來說，彈性擴容是一個剛性的訴求，TBase在這一塊也不含糊，TBase V1時引入shardmap以及shard表，通過shard表TBase可以提供在線線性擴容能力。

在V1內核中中shard記錄按照分配的順序存儲，有可能同樣shardid的記錄並沒有連續存儲，擴容業務流程為了完成擴容過程，對底層進行了不少的適配，流程較冗長。

V2內核在存儲層引入了shard聚簇的概念，也就是shardid相同的記錄在底層連續存儲，大大簡化上層業務流程的設計，同時大幅的提升了擴容的效率。

TBase V2 分區表：

TBaseV1中我們引入了集群分區表，這個分區表的性能相比社區的分區表，性能在OLTP場景下提升了1-3個數量級，尤其在子表數量眾多的時候性能提升尤為明顯。整體結構如下：

社區的性能對比：

在這個架構中：

Coordinator: 負責縱向分表，不感知表分區(橫向分表)的邏輯。

DataNode：負責橫向分表，根據分表字段將一張邏輯表劃分為多張物理表。

TBaseV2也具備這個性能優異的內置分區表功能。然而，除此之外V2還從PG 10.0繼承了社區的RANGE和LIST分區，通過新增加的這兩個分區類型，業務在建立分區表時有了更豐富的選擇。

TBase V2 的其他新特性：

• Hash索引支持Crash Safe：

PG10在這個版本中正式引入了Hashindex的XLOG機制，也就是說我們可以放心的使用Hash索引了，對於等值查詢和IN等操作，有了一個相比btree更優的選擇。

• 表達式高效運算：

PG10中為了支持JIT，把表達式的計算方法從之前的傳統執行器換成了展開執行，表達式的執行效率相比之前大大提升。團隊專門做過一個比較，我們把典型的表達式運算做了一個JIT DEMO和PG10的內核表達式展開進行了性能比較，發現PG10的測試結果並不比JIT生成的程序性能差。

• 多核擴展性增強：

事務擴展性：PG從9.6開始陸續推出了多個OLTP事務增前特性，包括XLOG並行落盤優化和系統快照機制優化，從我們團隊測試的情況來看，從24核的服務器到96核服務器，事務吞吐量可以做到準線性的提升。也就是說在TBase V2下，無論是24核的常見服務器，還是更多核的高端服務器，TBase都可以充分的發揮設備的潛力，把資源充分利用起來。

多核並行執行：PG9.6開始引入並行執行框架，到PG10已經可以做到aggregate，hash join，merge，seqscan，bitmap scan等算子的並行優化。在這些並行能力的支撐下，TBase V2對於海量數據的OLAP分析類操作更是如魚得水。

此文已由作者授權騰訊雲+社區發布，原文鏈接：https://cloud.tencent.com/developer/article/1125646?fromSource=waitui

歡迎大家前往騰訊雲+社區或關註雲加社區微信公眾號（QcloudCommunity），第一時間獲取更多海量技術實踐幹貨哦~

守護客戶數據價值：企業級NewSQL HTAP分布式雲TBase架構詳解