近些年，HTAP 正在受到人們?cè)絹?lái)越多的關(guān)注，Gartner 在 2014 年提出了?HTAP?這個(gè)術(shù)語(yǔ)和它的定義：

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.
——Defined by Gartner

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

HTAP is On The Way

OLTP

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

OLAP

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

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

• 實(shí)時(shí)性低（TP + AP 系統(tǒng)導(dǎo)致了數(shù)據(jù)孤島，意味著 OLAP 數(shù)據(jù)庫(kù)中的數(shù)據(jù)總是過(guò)時(shí)的，根據(jù)數(shù)據(jù)量的不同，數(shù)據(jù)延遲通常從幾小時(shí)到一周）。

• 企業(yè)維護(hù)兩套數(shù)據(jù)庫(kù)系統(tǒng)，管理和維護(hù)成本很高。

  
  

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

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

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

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

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

MySQL 原生

StoneDB 沿用并適配 MySQL sql 層，原生 100% 兼容 MySQL 協(xié)議和語(yǔ)法，我們先看下 StoneDB 官網(wǎng)提供的 ?2.0 架構(gòu)圖：

架構(gòu)圖中相關(guān)術(shù)語(yǔ)介紹：

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

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

• 對(duì)象數(shù)量

• 列數(shù)量

• 映射行的信息

• 事務(wù)相關(guān)的數(shù)據(jù)

SMU：snapshot meta unit 的縮寫(xiě)。

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

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

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

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

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

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

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

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

與 HeatWave 采用的方案類似，通過(guò)并行掃描 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)度。在加載過(guò)程中通過(guò)非阻塞，無(wú)鎖機(jī)制來(lái)實(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ù)：

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

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

（3）當(dāng) AP 中的負(fù)載發(fā)現(xiàn)其引用到了 TP 中的數(shù)據(jù)，其會(huì)主動(dòng)檢查 Population Buffer 是否有最新的版本。如果有則合并形成最新數(shù)據(jù)。

• 基于代價(jià)的新查詢引擎：一個(gè)負(fù)載透明、具有更加高效、準(zhǔn)確的代價(jià)模型將是我們系統(tǒng)性能的保證；并行查詢和向量化等技術(shù)也將會(huì)得到持續(xù)的迭代。

• 分布式 Column Store AP 集群將在單機(jī)能力構(gòu)建后，重點(diǎn)演進(jìn)。

  
  

國(guó)內(nèi)獨(dú)一家

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

• 基于磁盤(pán)的行存儲(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

  
  

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

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

總結(jié)

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

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

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

高可用性：無(wú)論后端發(fā)生什么，用戶都能進(jìn)行 7x24 小時(shí)的訪問(wèn)。有一套內(nèi)部機(jī)制來(lái)處理機(jī)器故障和網(wǎng)絡(luò)問(wèn)題等瞬時(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ù)的增長(zhǎng)。按需且實(shí)時(shí)地添加新節(jié)點(diǎn)，以存儲(chǔ)更多數(shù)據(jù)、處理更多讀取和寫(xiě)入以及處理更復(fù)雜的查詢。

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

如果您對(duì)我們的數(shù)據(jù)庫(kù)感興趣，歡迎通過(guò)下方鏈接快速體驗(yàn)~

StoneDB 開(kāi)源倉(cāng)庫(kù)

https://github.com/stoneatom/stonedb

高日耀StoneDB PMC、HTAP 內(nèi)核架構(gòu)師

畢業(yè)于華中科技大學(xué)，喜歡研究主流數(shù)據(jù)庫(kù)架構(gòu)和源碼。8年的數(shù)據(jù)庫(kù)內(nèi)核開(kāi)發(fā)經(jīng)驗(yàn)，曾從事分布式數(shù)據(jù)庫(kù)CirroData 、RadonDB 和 TDengine 的內(nèi)核研發(fā)工作，現(xiàn)擔(dān)任 StoneDB 的內(nèi)核架構(gòu)師及 StoneDB 項(xiàng)目 PMC。

END

編輯 &校對(duì)：郭葉君、王學(xué)姣