歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~
作者：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），第一時間獲取更多海量技術實踐乾貨哦~