時(shí)代在召喚： HTAP Is On The Way

近些年，HTAP 正在受到人們越來越多的關(guān)注，Gartner 在 2014 年提出了 HTAP 這個(gè)術(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

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

OLAP

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

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

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

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

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

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

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

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

IPv4 掃描

IPv6 掃描

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

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

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

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

StoneDB 就是希望打破這種局面，在開源這條道路上做一個(gè)探索，做一款由我們中國人主導(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 的縮寫，存儲(chǔ)在內(nèi)存中的列數(shù)據(jù)包。

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

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

SMU：snapshot meta unit 的縮寫。

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

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

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

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

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

數(shù)據(jù)的更新：當(dāng) TP 中的數(shù)據(jù)發(fā)生變化的時(shí)候，實(shí)時(shí)更新到 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 中，每個(gè)partion 中包括若干個(gè) chunk，每個(gè) chunk 中又包含若干個(gè) vector，每個(gè) vector 中包括了某列中的部分?jǐn)?shù)據(jù)。同時(shí)，提供導(dǎo)入行為的監(jiān)控能力，實(shí)時(shí)感知加載進(jìn)度。在加載過程中通過非阻塞，無鎖機(jī)制來實(shí)現(xiàn)高性能數(shù)據(jù)加載能力。

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

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

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

指定 merge 的時(shí)間，例如：200ms。

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

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

  最后

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

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

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

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

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

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

總結(jié)

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

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