小資料量使用者場景使用KunlunDB的價值

前言

在一個公司或者部門的新業務發展的起步階段，其使用者的資料量通常並不大，比如只有數十GB以內，一個MySQL主備複製叢集就可以輕鬆搞定。那麼這種情況下，使用KunlunDB有什麼價值呢？其實仍然有巨大的價值，本文就全面地回答這個問題。

高可用性

Kunlun-storage Fullsync的高效能強同步功能，確保了每個kunlun-storage shard的高可用能力。

同時，KunlunDB的cluster_mgr模組會自動完成主節點探活，自動&手動選主，自動切換到新主節點等工作，使得崑崙資料庫的具備完善的自動高可用能力，無需使用者干預。

相比於MySQL Group Replication或者semisync replication，KunlunDB具有更高的效能和更短的延時，並且對計算資源消耗更低。

原因如下：

• MGR需要在Flush事務的binlog之前持鎖等待備機確認（ACK）收到事務的binlog，這樣就會長時間阻塞所有與這些正在等待ack的事務有事務鎖衝突的所有活躍事務，從而降低了系統併發處理能力，並且延長了那些被阻塞的事務的執行時間，影響了業務系統的響應速度。而Kunlun-storage Fullsync做after-commit等待，等待備機收到binlog的確認之前，已經釋放了它持有的事務鎖，所以不會因為等待備機應答而阻塞那些與之衝突的事務。

• 同時，fullsync在等待備機ACK期間不需要佔用工作執行緒，而semisync和MGR都需要佔用工作執行緒，這就導致MySQL需要啟動更多的工作執行緒應對業務負載。每一個工作執行緒都會消耗CPU時間片，記憶體以及需要OS管理它們的狀態，這些都是對計算資源的消耗。

• 由於這些技術優勢，kunlun-storage fullsync在sysbench等效能測試中比MGR有最多達到5倍的效能優勢。

高效能

不僅kunlun-storage比MySQL有更好的replication效能，而且KunlunDB在資料分析，查詢處理等方面具備一系列高效能和可擴充套件能力，具體如下。

• 讀寫分離

計算節點執行只讀查詢語句（即select語句）時，可以自動向儲存叢集的備機節點傳送select查詢獲取資料，來執行select查詢語句。

這個行為不需要使用者干預，這樣使用者程式就不需要修改即可使用該功能。當然，使用者也可以在一個連線中或者全域性層面關閉此功能。通過在備機執行只讀查詢可以降低主節點的負載。

不過需要注意的是，有些只讀查詢並不能傳送到備機，比如更新了一個表之後在同一個事務中查詢這個表的資料，此時為了確保查詢到最新的資料，避免產生不一致的查詢結果，這個select語句預設就不能傳送到備機去執行，除非使用者降低了一致性級別強制讀取備機的可能舊的資料。

也就是說讀寫分離技術並不總是能分攤主節點的負載，這對於任何分散式資料庫或者分庫分表中間價都是這樣。

• 並行select查詢

KunlunDB支援並行select查詢，包括計算節點內的並行查詢處理，計算節點與儲存節點之間的並行查詢和儲存節點內部的並行查詢。

這三個層面的並行處理能力大大提升了KunlunDB的查詢效能，特別是對資料分析類的複雜查詢效能提升巨大。

計算節點內的並行是指多個執行緒執行查詢計劃的特定節點。在kunlun-server的一部分查詢處理功能具備並行查詢能力，包括NestedLoopJoin，HashJoin，MergeJoin，Append，Aggregate等節點；這部分並行能力是繼承自PostgreSQL。

計算節點與儲存節點之間的並行：是指計算節點可以非同步傳送SQL語句讀寫儲存節點的目標資料，這樣含有目標資料的所有儲存節點就會並行執行收到的SQL語句；這是KunlunDB從最初公開發布的0.6版本就具備的能力，也是我們自研的技術。

儲存節點內的並行：當計算節點有多條只讀select語句傳送到同一個儲存叢集時，計算節點會開啟多個連線到這個目標儲存節點，在每個連線中執行一個select語句，這些select語句在這個儲存節點中是並行執行的。

這樣，計算節點就可以利用到儲存節點的更多的計算資源同時服務同一個查詢請求。這個功能在崑崙資料庫1.0版本中會發布，也是我們自研的技術。

• 資料分析功能

無論一個KunlunDB叢集有幾個storageshard，使用者都可以部署若干個計算節點專門用於資料分析類查詢的處理，這些計算節點使用讀寫分離技術從這些storage shard的備機節點獲取資料來執行分析語句，因而不會影響OLTP 負載的效能。

KunlunDB的計算節點支援完備的資料分析功能，通過了所有TPC-H, TPC-DS的效能測試，這是MySQL不具備的能力。

具體來說，kunlun-server支援所有的window function，grouping sets, cube，rollup等功能，而MySQL只支援rollup和一部分window function功能。

KunlunDB的全叢集多級並行查詢處理能力，帶來資料分析類查詢的效能飛躍。

• 充分利用硬體資源

使用最簡單的一個MySQL一主兩備的叢集，需要3臺機器，但是這3臺機器中只有主節點可以承擔寫入負載，其CPU和IO負載通常比備機較高。

而使用KunlunDB後，在3臺機器使用對等部署模式部署一個KunlunDB叢集，這個叢集有3個儲存shard，每個機器都有其中一個shard的主節點和另外兩個shard的一個備節點（如下圖），這樣就把計算和寫入負載以及應用發起的連線總數平均分攤到3臺機器中，充分利用每一臺機器的計算資源，實現叢集整體更高的吞吐能力和效能。

全面而靈活的叢集管理功能

• 可程式設計的基礎叢集管理API

KunlunDB支援完備的叢集管理功能，包括自動的叢集備份和全域性一致性的恢復，水平彈性擴容，增刪啟停計算節點，增刪儲存叢集和儲存節點，重做備機，自動或者手動的主備切換，業務無感知的Online DDL等等。

並且所有這些功能都有對應的API介面，因此外部軟體系統可以可程式設計的方式操作和使用KunlunDB的叢集管理功能，例如可以非常方便地整合到使用者的資料庫叢集管理介面中。

• 預留水平擴容能力

隨著使用者業務規模的增長，一個KunlunDB叢集即使當前使用一個儲存shard，以後也可以自動的應用無感知的方式水平彈性擴容到多個儲存shard，只要使用者給叢集分配了更多的伺服器節點即可，不需要DBA的其他干預。這樣使用者就不需要擔心如何應對資料規模在未來不斷的增長。

自動的水平彈性擴容期間，崑崙資料庫叢集並不會鎖表，不影響應用程式執行。

• 圖形化的執行監控和故障診斷及告警

KunlunDB各模組的執行日誌，慢查詢日誌和其他日誌檔案中包含叢集各模組豐富的執行時資訊，這些日誌被崑崙資料庫用於圖形化的半自動的故障診斷，幫助DBA迅速準確地定位問題。

同時，藉助prometheus+grafana的流行的監控系統組合，實現了叢集節點監控。還可以以簡訊、電話等多種形式做告警，通知DBA及時處理問題。

資料庫遷移工作量

從其他資料庫系統遷移到KunlunDB，灌入資料這部分使用第三方工具即可完成。

通常難度和工作量比較大的是對應用系統的改造，在這方面我們做了大量工作幫助使用者輕鬆地從MySQL和Oracle Server遷移到KunlunDB。

• MySQL相容性

KunlunDB支援PostgreSQL和MySQL兩種連線協議，在每一種協議中都可以傳送KunlunDB支援的任何SQL語句。

這樣，就可以利用到比MySQL更加廣泛的資料儲存管理和利用能力，例如KunlunDB的OLAP分析能力，效能遠遠優於MySQL。

同時，KunlunDB支援MySQL的私有DML語法，詳見這篇文章（KunlunDB對MySQL私有DML語法的支援）。

對於MySQL 特有的（也就是沒有定義在SQL標準中的）SQL函式，我們會按需增加支援，這包括除了GIS函式和JSON函式之外的所有MySQL特有函式。增加一個這樣的函式難度很小，我們後續也可能會抽調資源統一把所有此類函式在崑崙資料庫計算節點中實現出來。

這樣，原本使用MySQL的應用軟體不需要任何程式碼修改或者重新編譯，可以直接連線到KunlunDB。

• Oracle相容性

KunlunDB繼承了PostgreSQL對Oracle資料庫的相容性，包括支援PL/SQL和SQL-2003的絕大多數功能。

其他Oracle特有功能，使用者需要完成應用側程式碼修改（通常需要修改少量儲存過程和SQL查詢語句），並且可以藉助一些第三方工具簡化和提速這些工作。

如果應用程式原本使用ODBC或者JDBC連線Oracle資料庫，那麼不需要任何程式碼修改就可以連線到KunlunDB；否則還需要修改應用側程式碼，使用相應的程式語言針對PostgreSQL的客戶端庫來連線到KunlunDB。

-END-