鑽石舞台

作者|祁國輝

責編|韓 楠

前面簡單講了一下OLTP和OLAP，因為它們的側重點不同， 自然對數據庫和軟硬件系統有了不太一樣的要求。

而OLAP類的系統， 都會有一個巨大的體量， 100TB只是開始， PB級別的系統比比皆是，這時候再追求磁盤速度就有點強人所難了。

有了這樣的需求， 自然也會催生出對應的產品。OLTP領域，因為一般都是企業核心數據，數據庫會進一步向高穩定、高並發、高可靠的方向推進， 企業的投資也會更大。Oracle、Mysql 基本上在這個領域處於主導地位。

相對而言， OLAP領域的空間更大一些， 選擇的因素也會更多樣化， 有通過海量數據預處理來實現快速報表生成的， 有利用大量硬件並發處理的MPP數據庫， 當然某種角度上， Hadoop 也是一類OLAP的應用， 採用的大量集群來實現海量數據處理。

但，萬事無絕對。

更有甚者， 有些業務自帶大量的統計查詢， 舉個例子，為了要求手機號碼實名制， 甚至控制一人多號的情況發生。

當一個人去開設新的手機號碼時， 首先需要統計該身份證下在全國範圍內有多少個電話號碼，另外還需要查之前的號碼是否有欠費等行為，如此等等，不一而足， 我印象中， 曾經有一個用戶鑒權過程，包含多達40+項的驗證 。

更不提， 還有大量的新興企業， 還在快速的原始積累， 市場拓展， 沒有時間和精力去架構企業級的數據倉庫系統。

就像每次去吃西餐，我們發現面前赫然擺着好幾副刀叉和勺子， 大多數人是沒法分辨到底應用用哪個叉子吃沙拉？哪個叉子切牛排？西餐禮儀固然重要， 但是絕大多數時間吃西式簡餐的時候， 我們還是一副刀叉吃完全程。

因為剛提到的這種場景屢見不鮮， 所以就催生出一個在OLAP和OLTP之間的灰色地帶，該如何處理的問題。架構師們一般都傾向於尋找一個平衡點， 切分OLTP和OLAP， 這樣有利於將來的整個企業架構，更加清晰可持續發展。

不過站在業務的角度， 是希望用最簡單的方法， 直接解決這些接踵而至的即時分析需求。因此HTAP應運而生。

基於這樣的共識和定義， 我們也需要進一步去理解HTAP中的一些關鍵技術點， 把握了這些技術點， 我們才可以對HTAP有深入的了解。

◆內存/閃存技術

首先，就是內存/閃存技術。隨着技術的發展， 摩爾定律一直在推動着IT技術的飛速發展， 計算機的內存從 KB 到了 TB， 閃存的容量也在不斷地刷新，雖然這使得一些老牌程序員非常失落， 他們認為只有認真考慮過 640k 內存使用的程序員，才是真正的程序員。

但是，這些新的技術使很多之前的不可能變成了可能，目前最新技術， 閃存容量已經突破單片容量 2TB， 這對於很多企業的核心數據庫來說， 已經綽綽有餘了。怎樣利用內存/閃存技術進一步突破數據處理效率， 自然也是技術人員孜孜以求的目標。

那既然內存都這麼大了， 為什麼不把所有的數據都存在內存里， 那不是就一下解決所有問題了嗎？究其原因， 還是有幾個相關的考慮：

首先是數據持久化的問題， 大家都知道， 內存是通過電路來實現數據存儲的。當內存掉電， 所有內容會消失，下次加電，數據需要重新裝載， 對於企業的核心數據， 一方面， 不能接受這樣的風險， 另一方面，數據加電之後的數據裝載也需要很長時間， 比如100TB的數據加載進內存， 然後內存中重新建立索引， 怎麼也需要幾十分鐘的時間， 這就是一個硬傷。

歷史上曾經出現過不少純內存的產品， 就是這個原因，一直都沒有占領企業核心應用領域。

不過， 隨着新技術的發展， 曙光乍現， 最新的PMem 技術， 可以保證加載在PMem中的數據， 掉電後不丟失， 相信幾年之後， 這個領域還會有新的驚喜。

另外一個方面是，就是下面說的列式存儲技術。

◆列式存儲

因為OLTP和OLAP的訪問模式不一樣， 對於OLTP來說， 基本上每次訪問都是某行數據的全部內容， 但是對於OLAP來說， 更大幾率是每次查詢分析只涉及部分列， 所以在這種情況下， OLAP應用採用列式存儲， 能夠進一步提升查詢的效率。

對比之後，就可以看出， 對於統計匯總中的列式存儲， 會大大減少查詢時的掃描數量， 從而大幅提升性能。

◆數據複製技術

因為我們的OLTP數據還是在行式數據中存儲，所以，我們需要有一種手段， 保證用戶的每一筆數據操作， 在OLTP系統中完成之後，都需要儘快地體現在列式存儲中， 這樣才能使得用戶看到及時的統計數據。

這個時候，就會有一個小小的問題， 因為每次轉換都是有額外的開銷， 我們都知道列式數據庫的優勢在於數據查詢， 弱點在於數據的update， 而每次轉換都有可能導致列式數據庫的update。

另外一點， 看HTAP的架構， 會有兩種， 一種是在現有系統之上， 通過增加內存來實現在原系統之上的HTAP支持， 另外一種是通過日誌等手段， 同步到另一批機器上，實現分系統的HTAP， 這種技術帶來的時延就會更大，我們都知道， 本地內存存取的速度和網絡訪問的速度，是有巨大的差異。

這種架構下， 數據複製後，帶來的數據延遲就會遠遠大於第一種方式， 但是相應帶來的好處就是有更好的隔離度和擴展性。

◆查詢路由和資源調度

數據準備好了， 那應用程序怎麼知道什麼時候用行存？什麼時候用列存？如果這需要應用程序自己選擇， 那和前面舉的例子， 吃西餐時的選叉子一樣，還是不能解決問題。

所以在這裡， 所有的數據庫廠商都會有比較一致的價值觀， 就是透明實現路由切換。當用戶的SQL 進來之後， 由系統的優化器來分析， 這個SQL 是需要OLTP操作還是OLAP操作， 因為目前的數據庫，基本都採用了基於成本的優化器， 很容易分辨出應用的訪問模式， 在分析完成之後， 系統會自動把SQL 路由到對應的數據存儲中，進行執行， 當數據處理完成之後， 再返回給用戶。

談到自動調度， 那就不得不說資源調度的問題， 當一個系統同時處理OLTP和OLAP的時候。尤其在資源不夠充分的情況下， 如何根據需求來動態決定資源分配，就是一門藝術， 比如通常情況下， 我們都需要OLAP不阻塞OLTP， 查詢分析的優先級是低於業務處理的優先級， 但是如果是一個突發的決策需求， 如何儘快完成？

能否通過自動策略， 實現OLTP和OLAP之間的動態平衡， 這對於 OLAP和OLTP在同一台機器上的HTAP 就是一個問題。而對於OLTP和OLAP分開在不同機器的HTAP， 就天然不存在這種資源爭用的問題

◆動態加載和數據壓縮

數據是無限的， 內存是有限的， 那怎麼最大限度地發揮內存中列式存儲的優勢呢？ 這個時候就有兩個方向， 可以在一定情況下來緩解這個問題。

1.列式數據動態加載。一般而言， 對於那些數據需要加載在內存中的列式數據中，來加速查詢和報表， 這個是可以通過人工來指定， 特定的表， 或者特定表的某個分區。但是如果能夠由數據庫系統來自行決定呢？

首先數據庫可以根據歷史SQL的執行情況， 來預估出一個內存容量大小對於系統加速的對比曲線， 這樣用戶就可以找到一個最佳的平衡點。

更進一步， 甚至可以容許系統在運行的過程中， 自行決定把一些很少用到的數據移出內存， 把一些沒有命中的數據從磁盤加載到內存中， 以避免出現查詢的時候緩存擊穿的問題。這個技術存在一定的風險， 目前還不是特別完善。

2.列式數據的壓縮。我們都知道， 當數據以列式來管理的時候， 單個列中重複數據的出現幾率會遠大於行式存儲， 所以內存中的列式存儲， 天然具備可壓縮的能力， 所以在內存的列式數據庫中， 採用壓縮， 也是提高空間利用率的一大法寶。

下面我們根據不同的場景，來看看幾種最常見的HTAP場景。

◆一快破萬法， O記神器 Exadata

把Exadata 拿來做HTAP， 也許會有人持有不同意見， 但是因為Exadata天生利用了大量的軟硬件結合和內存技術， 而且能夠在同一個系統中，同時支持高並發數據更新和海量數據查詢，說它是HTAP並不過分。

天下武功， 唯快不破。我們之所以提出HTAP， 都是在預算有限的環境下，採用多種技術結合的方式，來實現揚長避短， Exadata的Smart Scan ， 混合列壓縮， 內存， Pmem， 閃存和硬盤的多級存儲技術， 給用戶帶來了極高的性能，極大的便利性。

一言以蔽之， 如果你不想那麼複雜， 又有足夠的投資， Exadata 應該是最好的選擇， 誰用誰知道。具體特性就不贅述了。

◆不換手機不換號， 一鍵上5G

對於那些在原來業務系統上， 通過在內存中開闢一塊空間， 在內存中進行列式存儲以加速 OLAP 應用的產品，用戶可以對應用不做任何修改 ， 也不需要更換硬件平台；應用系統無感升級， 用戶 SQL 通過優化器自動路由到相應的存儲的技術， 代表產品有 Oracle 的 DBIM 和 SQL Server。

對於這種技術， 我經常和客戶做這樣一個比喻，就是不換手機不換號， 一鍵上5G。

在這裡我們吧，可以簡單地以 Oracle DBIM 為例， 來深入了解一下這種技術。

首先， 所有數據在硬盤上是以傳統行式進行存儲的， 這個是最基本的。

除了傳統的內存中的 Buffer Cache 之外，Oracle DBIM 在內存中單獨開闢了一個部分， 叫做 In-Memory Column Store， 在這片區域中， 數據是以列的方式進行存儲的， 用戶的查詢會在優化器的干預下，自動路由到相應的區域。

進一步， 我們看一下這片內存中的數據存儲格式。

所有的數據的DML操作， 為了保證數據的完整性和一致性， 都是先通過行式處理進行保存， 保存完畢之後， 再同步到in memory 區域。而在in-memory中的數據是由兩部分組成， 第一部分是列式存儲IMCU， 另外一部分記錄最新數據變化的SMU。

對於列式數據的查詢是遍歷IMCU和SMU之後的組合結果， 當數據增量達到一定的值， 就會進行合併。

在合併的時候， 首先標記當前IMCU為舊數據， 然後結合IMCU和SMU的數據， 生成新的IMCN， 同時生成空的SMU， 而舊的IMCU 會在不再使用或者空間不足的時候，自動刪除， 這樣就避免了新的數據進來之後， 對列式數據存儲的頻繁更新。

但是， 即使採用這種技術， 合併的時候還是會有額外開銷， 當數據刷新量巨大的時候， 會造成OLAP性能的抖動。

◆兄弟齊心， 其利斷金

上面這種方式的優點在於架構變化小， 但是缺點在於硬件需求加大， 因為在同一個系統中， 首先要額外的內存。另外， OLTP和OLAP混合， 會造成資源的衝突和爭用。在X86化大行其道的今天，出現了新的架構。

方法就是保持原始系統不動， 在相鄰增加一批計算資源專門負責 OLAP 計算， 然後通過日誌傳輸等技術， 把數據同步到相鄰的 OLAP 集群中，OLTP 系統將會在遷移耗費資源的 OLAP 請求後，性能和穩定性有大幅提高， 同時 OLAP 集群可以採用分布式技術，實現橫向的擴展。

代表產品，就是 MySQL 的 Heatwave 和 StoneDB 的 Tianmu， 我們以 Heatwave 為例， 簡單看看其中的技術要點。

HeatWave 本身是 InnoDB 的子引擎， OLTP 系統的數據， 會利用 binlog 投遞到HeatWave 集群， 而查詢優化器會自動把用戶的 OLAP 查詢路由到 HeatWave 中進行執行。

HeatWave 目前 Oracle 只在Cloud 上部署銷售， 希望本地部署的用戶， 其實可以考慮其他國內的開源 HTAP 產品（比如 StoneDB 等）， 原理上都是一致的。

StoneDB 代碼已完全在 Github 開源，歡迎關註：

https://github.com/stoneatom/stonedb

StoneDB 官網：

https://stonedb.io/

如何給一個 HTAP 數據庫做基準測試？

研發分享 | StoneDB 如何給 Tianmu 引擎增加 delete 功能 調研篇

StoneDB 團隊成員與 MySQL 之父 Monty 會面，共話未來數據庫形態

爆肝整理5000字！HTAP 的關鍵技術有哪些？

解讀《Benchmarking Hybrid OLTP&OLAP Database Systems》

深度乾貨！一篇 Paper 帶您讀懂 HTAP

可掃碼添加小助手

加入 StoneDB 開源社區用戶群

與數百位資深數據庫行業人員深入交流

共同進步