從架構上看OB與TIDB擅長的業務領域

這兩年分散式資料庫比較火，金融行業客戶上資料庫產品的時候，大多數都選擇了分散式資料庫。實際上並不是說集中式資料庫不能承擔金融的核心業務，因為對於大多數銀行業務來說，目前的集中式資料庫完全是能夠承擔其負載的，實際上郵儲銀行等銀行業選擇了openGauss作為核心系統的資料庫。很多銀行選擇分散式資料庫，最主要的還是考慮了高可用的問題。因此目前很多國產集中式資料庫也在準備推出類似ORACLE RAC的元件，從而補上集中式資料庫在關鍵業務執行環境中的一個短板。

實際上集中式資料庫與分散式資料庫在不同場景上是各有勝場的。在我們以前進行的一項測試中，對於一些核心業務表，如果設計了多個二級索引。對於集中式資料庫，二級索引對於資料併發寫入和修改的影響並不大，而對於分散式資料庫，影響就很大了。這主要是因為分散式資料庫的全域性索引維護成本因為多節點與網路延時的存在而被放大了。因此一些交易在分散式資料庫上的延時要略高於在集中式資料庫上。分散式資料庫因為可以橫向擴充套件，能夠承受更高併發的交易量，並不能降低單個交易的延時。今年年初的時候，有一家商業銀行曾經和我討論過，他們想拆掉RAC,改為HA架構，從而降低核心交易延時中GES/GCS帶來的負面影響。和分散式資料庫一樣，RAC可以提高總的交易併發量，而當系統沒有瓶頸的時候，並不能提高單個交易的效能。

對於分散式資料庫也是如此，不同架構的優缺點十分明顯，某些分散式資料庫存在某方面的缺陷是因為架構問題，是較難解決的，因此瞭解某個分散式資料庫屬於哪種架構，有哪些優點和缺點十分重要。讓你的應用特點與分散式資料庫架構的優點相吻合，才是你的最佳選擇。今天我們用當前最熱門的國產分散式資料庫TiDB和OceanBase來做一個分析，因為這兩種程式碼自主率都比較高的分散式關係型資料庫正好分別採用了兩種不同的架構。

分散式資料計算最主要有兩種形式，一種是分割槽SHARDING，一種是全域性一致性HASH，根據這種分散式資料計算的種類不同，衍生出存算分離和存算一體這兩種分散式資料庫架構。進一步再分出一系列子類別，比如對等模式，代理模式，外掛模式等。

存算一體SHARDING模式的分散式資料庫最為典型的是Oceanbase。下面是OB的架構圖：

每個Observer是一個計算儲存一體化的獨立服務，帶有SQL引擎，事務引擎和儲存引擎，並儲存一部分分片資料(分割槽)。OB採用的是對等模式，客戶端連線到任何一個OBSERVER都可以全功能使用資料庫。OBSERVER會自動產生分散式執行計劃，並將運算元分發到其他參與協同計算的OBSERVER上，完成分散式計算。管理整個叢集的RootService只在部分Observer中存在，並全域性只有一個是主的，其他都是備的。實際上每個OBSERVER就組成了一個完整的資料庫子集，如果所有的資料都儲存於一個OBSERVER上，我們的訪問方式類似於一個集中式資料庫。

這種架構下的資料分割槽採用了高可用，一個資料寫入主副本(Leader)後會自動同步到N個備副本，OB採用Paxos分割槽選舉演算法來實現高可用。其備副本可以用於只讀或者弱一致性讀(當副本資料存在延遲時)，從而更為充分的利用多副本的資源。實際上不同的分佈資料庫的主備副本的使用方式存在較大的差異，有些分散式資料庫的備副本平時是不能提供讀寫的，只能用於高可用。

大家看到這裡，可能覺得OB的架構不錯，各種問題都考慮的比較周到了。不過還是那句話，沒有完美的分散式資料庫架構，SHARDING儲存需要分佈在各個SHARDING分割槽中的分割槽表要有一個SHARDING KEY,根據SHARDING KEY來做分片處理。SHARDING模式雖然應對一般的資料庫操作是沒問題了，不過如果一條複雜的查詢語句中沒有關於SHARDING KEY的過濾條件，那麼就沒辦法根據SHARDING KEY去做分割槽裁剪，必須把這個運算元分發到叢集中儲存這張表的分割槽的所有OBSERVER上，這種情況被稱為SHARDING資料庫的讀放大。

另外一方面，在OB資料庫中建立一張表的時候需要考慮採用哪種模式，是建立為分割槽表還是普通的表，如果建立表的時候不指定是分割槽表，那麼這張表只會被建立在一個OBSERVER中，無法在叢集內多節點橫向擴充套件。另外如果有多張表要進行JOIN，如果要JOIN的資料分別屬於不同的OBSERVER管理，那麼這種JOIN是跨網路的，其效能也會受到一定的影響。為了解決這個問題，OB提供了TABLE GROUP的功能，可以讓分割槽屬性類似的分割槽表或者經常JOIN的單表的資料存放在相同的OBSERVER中，從而避免上面所說的多表JOIN的效能問題。這種模式對於資料庫使用者來說似乎變得麻煩了，不過就像開車一樣，如果要能夠發揮出車輛的最大效能，手動模式可能是最好的。

既然存算一體的SHARDING模式有這種缺陷，那麼能不能採用存算分離的方案呢?大家來看TIDB的架構：

TIDB是採用完全的存算分離的，計算引擎TIDB和儲存引擎TIKV是分離的，因此TIDB不存在存算一體的SHARDING分散式資料庫的這種讀放大的問題。似乎TIDB要技高一籌，完美的解決了OB等SHARDING資料庫的問題，不過事實上沒有那麼簡單。

首先是那就是計算節點的本地緩衝問題。因為大型分散式計算環境下實施緩衝區融合成本極高，因此每個TIDB節點只能有本地緩衝，不能有全域性緩衝。因此在TIDB的SQL引擎上是沒有全域性DB CACHE的，TIDB的資料緩衝只能建立在TIKV和TIFLASH上。SQL引擎->DB CACHE->儲存路徑->資料儲存介質這種傳統資料庫的資料讀取模式變成了SQL引擎->本地區域性緩衝->儲存路徑(網路)->儲存節點緩衝->儲存介質這種模式。這種模式對於一些小型的需要超低延時的OLTP業務並不友好。為了解決這個問題，採用此類架構的資料庫系統，就必須採用更快的儲存介質和低延時的網路架構，從而解決缺乏全域性DB CACHE支援的問題。當然這個問題也並不是不能解決的，透過更為細緻的運算元下推，採用類似ORACLE的SMART SCAN等技術，可以解決大部分問題。

存算分離也是一個雙刃劍，消除大多數SHARDING方式儲存資料的弊端也是有代價的。所有的讀寫操作都必須經過網路，不像OB那樣，如果是本地資料讀寫不需要經過網路。因此每個單一的讀寫操作，TiDB都必須承受網路延時的放大。不過TiDB的這種延時放大是穩定的，不會像OB那樣，同一條SQL，時快時慢(經過網路肯定要比讀取本地資料慢一些)。

TiDB的完全存算分離的架構，很好的解決了Sharding架構的讀放大問題，這種架構避免了不必要的讀放大，但是也讓資料讀寫的平均延時因網路而受到了一定的影響，得失之間也是有所取捨的。TiDB也在透過計算引擎的最佳化來減少其負面影響。比如對於不變更的歷史資料，TiDB也引入了計算節點本地讀緩衝機制來提升效能，同時透過運算元儘可能早的向TiKV和TiFlash下推來利用分散式資料庫的併發能力來提升效能。

另外很重要的一點是TiDB的存算分離架構用增加網路延時的效能犧牲換來了使用者使用的簡化，我們基本上可以像使用集中式資料庫一樣來使用TiDB，建表的時候想建分割槽表就建分割槽表，想建普通表就建普通表。全域性索引，本地索引也和集中式資料庫一樣簡單。這對於一些應用水平不高的使用者來說是十分重要的。因為大部分分散式資料庫上的效能問題並不是資料庫本身的問題引起的，而是因為應用開發商不合理的設計資料結構，以及不合理的表分割槽與資料分佈引起的。

因為採用截然不同的架構，OB和TiDB在不同的應用場景下的表現會有所不同。對於一些簡單的小交易為主的業務來說，因為OB資料庫的SHARDING架構，受益於各級緩衝，在這些小交易的延時方面，可能OB較為有優勢。而對於一些經常有大型寫事務的場景，因為TiDB可以從計算節點更加快速的下推運算元而比OB更有優勢，而OB必須將運算元分解到各個OBSERVER上，交給OBSERVER再往下寫資料，其效率肯定是有所損失的。

一些大型的表掃描和多表關聯查詢也是如此，因為兩種不同的架構，在效能上也會表現的不同。當執行計劃類似的情況下，TiDB的分散式執行計劃被分解的粒度更細，並直接下推到TiKV和TiFlash上，而OB需要將運算元分別推送給其他OBSERVER，再由OBSERVER下推，在互動上也多了一層。這是架構的差異導致的直接差異，享受好處的同時肯定也需要承受一些缺陷。

實際上對於複雜的查詢，起決定因素的還是CBO最佳化器的水平，作為兩個國產分散式資料庫的頭部企業，在這方面大家各有勝場。實際上並不是某一條SQL某個資料庫勝過其他競品，就說明這個資料庫的最佳化器做的比競品好。就像前幾天我在測試一條OB4的SQL的執行計劃時，發現其已經完成了對一個複雜HASH JOIN的自動改寫，因此執行效率遠高於基於PG最佳化器改造的國產資料庫。我的比較僅僅是針對這條SQL而已，並不說明OB的SQL引擎就一定比其他資料庫好。實際上最佳化器都是在不斷的應用中發現問題，不斷的打補丁打出來的。Oracle的最佳化器就是在幾十年的不斷補丁中最佳化出來的，我們的國產資料庫也必然需要經過這樣的過程。我想只要發現了我上回實驗的那個問題，有實力的國產資料庫廠商很快就能解決那個問題。

正是因為上面的原因，因此如果你的企業應用十分複雜，資料量十分大。那麼在你從類似OB/TiDB這樣不同架構的分散式資料庫中做選擇的時候，一定要把你比較複雜的SQL拿出來做些測試，再來完成你的選擇。因為對於大多數應用來說，這些分散式資料庫在架構上的缺陷還是不會造成太大的影響的，而如果某些SQL因為執行計劃無法最佳化而導致你必須改寫應用就比較麻煩了。

分散式資料庫與應用的對比實際上是十分複雜的，今天我們僅僅從存算分離的架構上做了一些簡單的分析。實際上還有很多問題沒有涉及，比如說資源管理、多租戶、HTAP等特性。因為架構不同，資料庫對不同型別的應用支援是會略有不同的。不過實際上對於大多數應用來說，這些差異並不是不可逾越的鴻溝，並不是某種應用必須選擇某個資料庫產品才能跑起來。資料庫選型只是一次選擇，如何用好一個資料庫產品，是需要長期積累的，不同資料庫廠商的售後支援能力，服務客戶的態度，第三方服務能力可能是資料庫選擇的更重要的考慮因素。