時代在召喚： HTAP Is On The Way

近些年，HTAP 正在受到人們越來越多的關(guān)注，Gartner 在 2014 年提出了 HTAP 這個術(shù)語和它的定義：

Hybrid transaction/analytical processing (HTAP) is an emerging application architecture that ”breaks the wall“ between transaction processing and analytics. It enables more informed and ”in business real time“ decision making.

在此之前，市面上基本是 OLTP 和 OLAP 數(shù)據(jù)庫的天下。

OLTP

第一個有效的面向事務(wù)的數(shù)據(jù)庫在 1970 / 1980 年代開始廣泛使用，它們后來被稱為在線事務(wù)處理 (OLTP：Online Transaction Processing) 系統(tǒng)， 事務(wù)處理對單記錄操作可靠性、準確性和速度要求非常高。

OLAP

隨著數(shù)據(jù)量的增大，特別是互聯(lián)網(wǎng)的發(fā)展，OLTP 數(shù)據(jù)庫的工作負載越來越大，同時分析能力嚴重受限，我們需要一個能非常快速地在一個或多個數(shù)據(jù)庫表中查找單個記錄、多條記錄或一種記錄總數(shù)的數(shù)據(jù)庫。OLAP 數(shù)據(jù)庫同 OLTP 數(shù)據(jù)庫在技術(shù)上也分道揚鑣。

然而，針對不同數(shù)據(jù)場景選擇對應(yīng)的 TP / AP 系統(tǒng)也帶來了相應(yīng)的難題，因為 TP 和 AP 不是一套系統(tǒng)，在搭配使用時就會有數(shù)據(jù)傳輸?shù)倪^程。在 一體化實時 HTAP 數(shù)據(jù)庫 StoneDB，如何替換 MySQL 并實現(xiàn)近百倍性能提升的文章中，我們總結(jié)了業(yè)界通過 TP / ETL或數(shù)據(jù)遷移 / AP 結(jié)構(gòu)來構(gòu)建 HTAP 系統(tǒng)存在的一些問題：

• 實時性低（TP + AP 系統(tǒng)導(dǎo)致了數(shù)據(jù)孤島，意味著 OLAP 數(shù)據(jù)庫中的數(shù)據(jù)總是過時的，根據(jù)數(shù)據(jù)量的不同，數(shù)據(jù)延遲通常從幾小時到一周）。
• 企業(yè)維護兩套數(shù)據(jù)庫系統(tǒng)，管理和維護成本很高。

Gartner 的最新報告表明，傳統(tǒng)的 TP + AP 架構(gòu)將事務(wù)和分析系統(tǒng)分開，業(yè)務(wù)實時響應(yīng)的高需求意味著使用“過時”的數(shù)據(jù)已經(jīng)不合時宜，商業(yè)時刻轉(zhuǎn)瞬即逝。我們需要創(chuàng)建一套更簡單的體系結(jié)構(gòu)，讓 TP + AP 及 ETL 過程被單個數(shù)據(jù)庫所取代，消除數(shù)據(jù)副本，將數(shù)據(jù)存儲在 OLTP 引擎中進行事務(wù)處理，然后將數(shù)據(jù)復(fù)制到 OLAP 引擎（可能多次）以進行分析。隨著軟硬件基礎(chǔ)設(shè)施和數(shù)據(jù)庫技術(shù)的不斷進步，屬于 HTAP 數(shù)據(jù)庫系統(tǒng)的時代已經(jīng)到來。

HTAP 數(shù)據(jù)庫 StoneDB 為什么選擇擁抱 MySQL 生態(tài)?

StoneDB 并不希望打造一個新的 StoneDB HTAP 生態(tài)。對于大部分數(shù)據(jù)庫用戶來說，最好的產(chǎn)品體驗就是開箱即用，在一個黑盒系統(tǒng)中完成業(yè)務(wù)的平滑遷移，最大程度的降低用戶學(xué)習(xí)成本和運維成本。而 MySQL 是世界上最流行的數(shù)據(jù)庫，擁有龐大和成熟的生態(tài)。

從 DB-Engines 排名上看到，MySQL 穩(wěn)居第二，僅次于 Oracle。（下圖來自 DB-Engines）

Shadowserver Foundation 在 5 月 31 日發(fā)布了一份全網(wǎng)的 MySQL掃描報告，超過 360 萬個 MySQL 實例暴露在公網(wǎng)。這只是暴露出來的，我們可以推斷，實際的裝機量要遠遠大于這個數(shù)字。

IPv4 掃描

IPv6 掃描

業(yè)界唯一開源的 HTAP

我們以存儲架構(gòu)為特征對業(yè)界最新的 HTAP 數(shù)據(jù)庫做一個概覽：

• 基于磁盤的行存儲 + 分布式列存儲：MySQL HeatWave
• 以行存儲為主 + IMCS （內(nèi)存列）：Oracle Database In-Memory（A dual format in-memory database）、?SQL Server、DB2 BLU
• 分布式行存儲 + 列存副本：SingleStore
• 以列存為主 + Delta Row Store：SAP HANA

從上述中可以看到，哪怕是最流行的開源數(shù)據(jù)庫 MySQL，它的 HeatWave 也不開源。

StoneDB 就是希望打破這種局面，在開源這條道路上做一個探索，做一款由我們中國人主導(dǎo)的開源 HTAP 數(shù)據(jù)庫。

MySQL 原生

StoneDB 沿用并適配 MySQL sql 層，原生 100% 兼容 MySQL 協(xié)議和語法，我們先看下 StoneDB 官網(wǎng)提供的 ?2.0 架構(gòu)圖： 架構(gòu)圖中相關(guān)術(shù)語介紹：

IMCDP：In Memory Column Data Pack 的縮寫，存儲在內(nèi)存中的列數(shù)據(jù)包。

IMCDPI：In Memory Column Data Pack Index 的縮寫，用于保存 IMCDP 的元數(shù)據(jù)，包括：

• 對象數(shù)量
• 列數(shù)量
• 映射行的信息
• 事務(wù)相關(guān)的數(shù)據(jù)

SMU：snapshot meta unit 的縮寫。

在 StoneDB 2.0 的設(shè)計中，會推出類似 MySQL HeatWave 的 In-Memory Column Store 引擎：基于磁盤的 RDBMS （MySQL 8.0）和分布式內(nèi)存列存儲（IMCS）來實現(xiàn) HTAP。

StoneDB 在不改變 MySQL 原生的 OLTP 工作負載的前提下，深度集成 IMCS 集群以加速查詢處理，事務(wù)在原生 MySQL 工作負載中執(zhí)行。另外 StoneDB 會自行判斷復(fù)雜查詢并將其下推到 IMCS 引擎進行加速處理，經(jīng)常訪問的列將被加載到 IMCS 中，列數(shù)據(jù)從行存儲中提取（由 InnoDB 并行加載到 IMCS），熱數(shù)據(jù)駐留在 IMCS，冷數(shù)據(jù)落盤。

基于 IMCS 引擎我們將實現(xiàn) AP 負載的全內(nèi)存計算：

內(nèi)存中數(shù)據(jù)組織方式：IMCDP + IMCDPI 。

數(shù)據(jù)加載方式：由 InnoDB 并行加載至 IMCS 中。

數(shù)據(jù)的更新：當 TP 中的數(shù)據(jù)發(fā)生變化的時候，實時更新到 AP 引擎中。

內(nèi)存中數(shù)據(jù)持久化及系統(tǒng)恢復(fù)：為了加速恢復(fù)的速度，我們將內(nèi)存中的數(shù)據(jù)持久化到我們的 on-disk column store 中。

高效加載 TP 數(shù)據(jù)（From InnoDB）

上圖是剛剛介紹了 StoneDB 2.0 架構(gòu)中提到的從 InnoDB 并行加載數(shù)據(jù)的示意圖。

與 HeatWave 采用的方案類似，通過并行掃描 TP 中的數(shù)據(jù)（主要是 InnoDB 表），將需要加載的數(shù)據(jù)按 partition ,chunk, vector, tile 的數(shù)據(jù)組織方式并行的加載至 IMCS 中，每個partion 中包括若干個 chunk，每個 chunk 中又包含若干個 vector，每個 vector 中包括了某列中的部分數(shù)據(jù)。同時，提供導(dǎo)入行為的監(jiān)控能力，實時感知加載進度。在加載過程中通過非阻塞，無鎖機制來實現(xiàn)高性能數(shù)據(jù)加載能力。

數(shù)據(jù)的更新

當 TP 中的數(shù)據(jù)發(fā)生變化后，將該項數(shù)據(jù)插入到 Population Buffer 中，并維護該數(shù)據(jù)的版本信息。當滿足如下任一條件的時候，會將 Population Buffer 中的數(shù)據(jù)，依據(jù)版本信息依次與內(nèi)存中的數(shù)據(jù)合并為最新的版本數(shù)據(jù)：

當我們的 Population Buffer 已經(jīng)寫滿后，會執(zhí)行一次 flush 動作，將 Population Buffer 中的數(shù)據(jù)更新到其對應(yīng)的數(shù)據(jù)中。

指定 merge 的時間，例如：200ms。

當 AP 中的負載發(fā)現(xiàn)其引用到了 TP 中的數(shù)據(jù)，其會主動的檢查 Population Buffer 是否有最新的版本。如果有則合并形成最新數(shù)據(jù)。 未來 2.0 其它的重點工作：

• 基于代價的新查詢引擎：一個負載透明，具有更加高效，準確的代價模型將是我們系統(tǒng)性能的保證；并行查詢和向量化等技術(shù)也將會得到持續(xù)的迭代。
• 分布式 Column Store AP 集群將在單機能力構(gòu)建后，重點演進。

  最后

  除了 Gartner 的原始定義，我們對 HTAP 更多視為一個集硬件、TP、AP、內(nèi)存、云原生數(shù)據(jù)庫技術(shù)、可擴展事務(wù)管理等多種功能的新興架構(gòu)，使事務(wù)處理和分析（HTAP）能夠在同一套數(shù)據(jù)庫上運行。

一個現(xiàn)代的 HTAP 數(shù)據(jù)庫應(yīng)該具備以下特性：

一致性：包含全面的 ACID 事務(wù)支持。數(shù)據(jù)密集型應(yīng)用程序可以依靠它來保證數(shù)據(jù)一致性，從而提高開發(fā)人員的速度和用戶體驗。

高可用性：無論后端發(fā)生什么，用戶都能進行 7x24 小時的訪問。有一套內(nèi)部機制來處理機器故障和網(wǎng)絡(luò)問題等瞬時和永久性故障（比如宕機/腦裂），并且提供數(shù)據(jù)復(fù)制和細粒度數(shù)據(jù)放置功能，以確保數(shù)據(jù)高可用。并且提供滾動升級機制，避免集群擴展和架構(gòu)升級等引發(fā)的停機對業(yè)務(wù)造成影響。

可擴展性：應(yīng)用云原生技術(shù)，其計算和存儲資源可以輕松擴展以應(yīng)對業(yè)務(wù)的增長。按需且實時地添加新節(jié)點，以存儲更多數(shù)據(jù)、處理更多讀取和寫入以及處理更復(fù)雜的查詢。

實時性：數(shù)據(jù)庫應(yīng)支持任何實時更新，從而實現(xiàn)細粒度索引和并行查詢執(zhí)行。為了確保及時性，數(shù)據(jù)庫架構(gòu)必須同時利用行存儲和列存儲，并基于查詢優(yōu)化器選擇最佳的數(shù)據(jù)訪問路徑。

總結(jié)

以上是生活随笔為你收集整理的StoneDB 为何敢称业界唯一开源的 MySQL 原生 HTAP 数据库的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。