作者：李浩

編輯/設(shè)計：宇亭

當(dāng)我們選擇一款 HTAP 數(shù)據(jù)庫時，總是先被其相關(guān)文檔里所描述的優(yōu)異性能所吸引。卓越的性能是我們選擇一款產(chǎn)品的出發(fā)點，因為我們希望該款產(chǎn)品能夠解決我們業(yè)務(wù)中的痛點。而大家使用 HTAP 產(chǎn)品的出發(fā)點就是希望該款數(shù)據(jù)庫能夠解決我們在事務(wù)處理過程中的實時分析痛點。不過，性能優(yōu)勢只能算作我們選擇一款產(chǎn)品的考量因素之一，實際上，公司層級去選擇一款HTAP產(chǎn)品時，還需要額外考量一些其他的因素，本篇文章，StoneDB首席架構(gòu)師李浩給大家分享一下選擇 HTAP 產(chǎn)品的六大關(guān)鍵考量因素。

在 TP 產(chǎn)品非常成熟的今天，各類 TP 類型數(shù)據(jù)庫早已在各行各業(yè)中支撐著業(yè)務(wù)系統(tǒng)的高速發(fā)展。隨著業(yè)務(wù)系統(tǒng)越來越復(fù)雜，所產(chǎn)生的數(shù)據(jù)量也在飛速增長。同時，對于這些數(shù)據(jù)的實時分析需求也日益迫切。然而，當(dāng)前的解決方案卻無法滿足實時分析的需求。例如：如果直接在TP數(shù)據(jù)庫上進行分析，雖然可以滿足實時性要求，但其分析的性能基本無法滿足要求，并且在進行分析時會占用大量的計算資源和 IO 資源，從而影響到 TP 性能。因此，傳統(tǒng)的做法是將分析任務(wù)放在業(yè)務(wù)低峰時候（通常是半夜進行，因此大家經(jīng)常會看見 T+1的說明情況）。

HTAP 的出現(xiàn)則解決了這個實時數(shù)據(jù)分析的痛點。HTAP，即Hybrid Transaction/Analytical Processing，一套系統(tǒng)可以同時解決 TP 需求和 AP需要。如果你的業(yè)務(wù)對于 TP 業(yè)務(wù)所產(chǎn)生的數(shù)據(jù)需要進行實時的 AP 分析，那么 HTAP 將會是你很好的選擇。
Gartner 預(yù)計在 2024 年左右，HTAP 市場將會走向成熟。從最早 2014 年概念的提出到最近這幾年，國內(nèi)外對于 HTAP 已經(jīng)從概念走向具體的產(chǎn)品落地。早期大家炒炒概念還可以接受，但顯而易見，現(xiàn)在的市場越來越明確地走向產(chǎn)品質(zhì)量和方案落地的競爭。
無論國內(nèi)外的 SnowFlake（Unistore）、Google（AlloyDB）、Oracle（HeatWave）還是國內(nèi)的 TiDB、OceanBase、StoneDB 等都推出了其各自的 HTAP 產(chǎn)品并且在積極的落地到生產(chǎn)系統(tǒng)。那么面對越來越多的 HTAP 產(chǎn)品，我們該如何選擇一款適合自己業(yè)務(wù)的 HTAP 數(shù)據(jù)庫產(chǎn)品呢？我們選擇一款 HTAP 數(shù)據(jù)庫又需要從那些方面進行考察呢？本篇文章中，StoneDB將給出一些自己的思考，需要說明的是，本篇作為產(chǎn)品選擇篇，我們不從技術(shù)架構(gòu)和具體的實現(xiàn)上進行討論，而是主要從業(yè)務(wù)需求端的角度來作分析。對于硬核的技術(shù)實現(xiàn)角度，我們將在《什么是真正的 HTAP？實踐篇》的下一章進行討論。

業(yè)務(wù)場景

首先，我們從業(yè)務(wù)場景的角度來討論如何選擇一款HTAP數(shù)據(jù)庫，主要有以下四個維度：

1.1、業(yè)務(wù)類型
業(yè)務(wù)所在的領(lǐng)域決定了產(chǎn)品底層技術(shù)棧的選擇。這個很好理解，比如電商這個業(yè)務(wù)場景所需要的技術(shù)棧和產(chǎn)品特點與傳統(tǒng)制造、CRM 等所關(guān)注的側(cè)重點就完全不一樣——電商關(guān)注高并發(fā)、低延時、數(shù)據(jù)一致性和秒殺場景等等，而傳統(tǒng)制造商則對海量多樣化數(shù)據(jù)的處理和如何有效挖掘數(shù)據(jù)價值這些方面更加關(guān)注。
在不同的業(yè)務(wù)類型下，選擇一款 HTAP 產(chǎn)品需要重點考察的是——這個業(yè)務(wù)類型需要哪一部分能力為主：TP 能力為主亦或是 AP 能力為主。
對于電商系統(tǒng)需要更加注重其在 TP 方面的關(guān)鍵能力，例如：事務(wù)、數(shù)據(jù)一致性等等；而對于CRM系統(tǒng)，經(jīng)銷存等等對TP能力則不會那么嚴(yán)苛，其可能更加看重AP的能力，在 TP 能力滿足其基本業(yè)務(wù)需求的情況下，哪款產(chǎn)品的 AP 能力更強，業(yè)務(wù)側(cè)可能會更傾向于選擇該款產(chǎn)品。
而現(xiàn)有 HTAP 產(chǎn)品從技術(shù)實現(xiàn)路線上，基本可以分為這么兩類路線，其決定產(chǎn)品的基因：即側(cè)重于 TP 還是 AP？
路線1：以成熟的TP系統(tǒng)為基礎(chǔ)，在其上進行AP能力的擴展。現(xiàn)有大部分 HTAP 數(shù)據(jù)庫產(chǎn)品均采用該種策略。為什么采用該種策略？其原因是顯而易見的，TP 系統(tǒng)發(fā)展到現(xiàn)在其相較于 AP 系統(tǒng)，更加成熟。例如：國內(nèi)外的 OB，StoneDB，TiDB，Oracle MySQL Heatwave 和 Google AlloyDB 等；路線2：在 AP 系統(tǒng)的基礎(chǔ)上擴展其處理 TP 的能力。例如：Snowflake 等。這種路線，比較困難，但是成熟的科技公司會有更多的資源去做這個事兒，難度大，但是做出來了，也會是一大利器。

1.2、端到端的解決方案能力：
對于業(yè)務(wù)開發(fā)相關(guān)人員，一個新產(chǎn)品或者解決方案的引入，自然希望不會給其帶來額外的工作負(fù)擔(dān)，并且最好能夠與其原有的技術(shù)棧相兼容，這樣對于原有業(yè)務(wù)系統(tǒng)的改動要求最少。但也不完全就是為了讓干的活兒更輕松一些，因為，對于一個在線運行的系統(tǒng)，其對于穩(wěn)定性的要求非常高，而新組件的引入往往會讓整個業(yè)務(wù)的不穩(wěn)定因素增大。因此，如果不能夠保持原有的技術(shù)棧，則需要提供端到端的解決方案。例如：原系統(tǒng)采用的 ClickHouse 或者?ElasticSearch，如果需要替換為 OB 或者StoneDB，那么需要考慮原系統(tǒng) ClickHouse 或者 ElasticSearch 上下游相關(guān)模塊接口兼容性，數(shù)據(jù)同步到 CK 或者 ES 的方式等等，這些解決方案都要提供出來。
1.3、數(shù)據(jù)實時性要求：
數(shù)據(jù)實時性的高低同樣也會影響到產(chǎn)品的選擇。當(dāng)前現(xiàn)有的 HTAP 數(shù)據(jù)庫在 TP和 AP 之間的數(shù)據(jù)同步策略實現(xiàn)機制不盡相同。例如：有些云廠商通過 MySQL+Binlog+ClickHouse 的組合方式提供 HTAP 服務(wù)，從用戶的角度看似乎該服務(wù)具備了HTAP的能力，但實際上完全不是那么回事兒——因為通過 Binlog 這種方式會有很多弊端，這里可以參考我們之前的兩篇文章；又如有廠商通過 TP+Redo+Raft+AP 這樣的組合構(gòu)成 HTAP 產(chǎn)品，其相較于前一種在數(shù)據(jù)的實時性上有了較大的提升，但也只是提供數(shù)據(jù)的最終一致性，同樣數(shù)據(jù)的實時性還是得不到保證；有的廠商則采用了基于 LSM-tree 實現(xiàn)的行列混存，這種可以基本保證對于數(shù)據(jù)實時性的要求；而像 MySQL Heatwave 和 StoneDB 則提供了基于內(nèi)存計算的強實時性的方案。
HTAP 數(shù)據(jù)庫在產(chǎn)品具體實現(xiàn)的時候，其選擇的存儲方案會直接到影響架構(gòu)的選擇：是一體化的架構(gòu)？還是 TP 系統(tǒng)疊加 AP 系統(tǒng)的方案？架構(gòu)的選擇則會直接決定數(shù)據(jù)同步策略和數(shù)據(jù)實時性的高低。
1.4、技術(shù)能力：
產(chǎn)品背后其公司所代表的技術(shù)實力也是業(yè)務(wù)方選擇一款產(chǎn)品的考量因素，例如：我們在下文第六點中給出的觀點。??

性能

考量完業(yè)務(wù)場景相關(guān)的因素后，接下來需要考量的一個重要因素就是性能。不同于TP系的 Benchmark TPC-C 或者 AP 系統(tǒng)的?Benchmark?TPC-H，對于HTAP 的性能測評一般不再使用這兩個傳統(tǒng)的方式來進行衡量。

當(dāng)前大家更多地使用 TPC-H 來對其 AP 的能力進行評估，該種方法可以對其系統(tǒng)有一定的評價作用，但也存在著一定的弊端，那就是?TPC-H 無法全面地衡量一款 HTAP——因為 HTAP 數(shù)據(jù)庫的系統(tǒng)中會同時存在兩類負(fù)載：TP負(fù)載和AP負(fù)載。兩類負(fù)載需要同時使用系統(tǒng)的CPU資源、IO 資源和網(wǎng)絡(luò)資源等等。對資源的競爭會導(dǎo)致兩類負(fù)載的相互干擾。因此，為了更好的衡量 HTAP 數(shù)據(jù)庫，無論是學(xué)術(shù)界還是工業(yè)界，都逐漸提出了一些適用于HTAP數(shù)據(jù)庫的 Benchmark 系統(tǒng)，具體可以參考我們之前的文章：《如何給一個 HTAP 數(shù)據(jù)庫做基準(zhǔn)測試？》
這里也簡單提一下，除了具體的性能指標(biāo)，例如：TPS、QPS、吞吐量等等，資源隔離性也是我們的重要考量。而資源隔離通常有兩種方式：（1）通過系統(tǒng)手段（軟件）隔離。例如，通過 Cgroup 的方式進行資源的管理；（2）通過物理手段進行隔離。例如，依據(jù)不同的負(fù)載類型 Route 到不同引擎上，將 AP 查詢路由到列存引擎節(jié)點上，這樣可將 TP 負(fù)載和 AP 負(fù)載運行于不同的節(jié)點上，從而做到真正的物理隔離。

運維

運維的難度也需要我們認(rèn)真考量。數(shù)據(jù)庫的運維不同于其它基礎(chǔ)系統(tǒng)，其對于 DBA 的綜合素質(zhì)有比較高的要求。在系統(tǒng)長時間運行的過程中會遇到各種數(shù)據(jù)庫的使用、功能、性能等等問題。解決這些問題除了需要數(shù)據(jù)庫、操作系統(tǒng)和業(yè)務(wù)等多方面的知識，同樣也需要相關(guān)運維工具的支持。運維手段和運維工具可以高效的支持 DBA 的運維工作。復(fù)雜的系統(tǒng)形態(tài)，會導(dǎo)致 DBA 的運維工作量增大，最直接的影響就是難以快速定位問題，增加了解決問題的耗時。

生態(tài)

生態(tài)是選擇一款 HTAP 數(shù)據(jù)庫的一個重要因素。當(dāng)前有兩類生態(tài)：PostgreSQL 和 MySQL。選擇哪一種生態(tài)，會直接影響到后續(xù)圍繞數(shù)據(jù)庫所構(gòu)成的整個技術(shù)棧。同時，業(yè)務(wù)也會從其自身的特點選擇相應(yīng)的技術(shù)路線。例如：如果業(yè)務(wù)系統(tǒng)是基于 JSON 和 GIS 能力的話，那么多數(shù)的業(yè)務(wù)開發(fā)者可能更傾向于選擇 PostgreSQL 生態(tài)；如果是電商業(yè)務(wù)則更多的會選擇 MySQL 生態(tài)。
具體來講，生態(tài)中的周邊工具、中間件和解決方案的完整性和豐富性非常重要。除工具、方案外，社區(qū)參與的人數(shù)（不管是對開源的 HTAP 數(shù)據(jù)庫，還是對于商業(yè)或云上的 HTAP 服務(wù)，都需要考量該使用該服務(wù)的人群數(shù)量），更多的社區(qū)參與人數(shù)往往意味著社區(qū)比較活躍，那么，我們使用者遇到的一些問題就可以得到快速的響應(yīng)。
生態(tài)的繁榮也從另外一個側(cè)面反映出該技術(shù)路線獲得了相當(dāng)多的上下游廠商的支持。

成本

成本是一個無法繞過的話題，一般企業(yè)/組織內(nèi)的管理者對于成本的關(guān)注度往往是多于其他項的。如果想要使用一款 HTAP，需要考量的成本主要包括以下幾個方面：硬件成本、替換（遷移）成本、運維成本等：

5.1、硬件成本：
其中最主要包括：計算成本和存儲成本。在 StoneDB 實際的產(chǎn)品 POC 過程中，遇到很多客戶實際的業(yè)務(wù)數(shù)據(jù)量在 100GB-1TB 內(nèi)。如果采用一些現(xiàn)有的其他國產(chǎn) HTAP 產(chǎn)品，由于這些產(chǎn)品對最小集群有要求，從而使得這些小廠商在使用 HTAP 服務(wù)時，必須付出比較高的集群硬件成本，這個是他們不愿意接受的。特別地，當(dāng)需要替換現(xiàn)有MySQL數(shù)據(jù)庫的時候，目前的一些國產(chǎn) HTAP 數(shù)據(jù)庫，基本都存在 MySQL 語法兼容性的問題，這導(dǎo)致遷移到新的業(yè)務(wù)系統(tǒng)上需要進行大量的修改，從而造成整體成本的飆升。如果廠商比較在乎這一部分的成本的話，StoneDB 就是很好的選擇了。
5.2、替換成本：
需要能夠提供對于原系統(tǒng)的平滑遷移能力。對于業(yè)務(wù)侵入改動最小，業(yè)務(wù)無需做修改即可平滑遷移到新的數(shù)據(jù)庫平臺。
5.3、運維成本：
在第三點中我們討論運維問題，這里就不再詳細(xì)討論了。運維成本將會是系統(tǒng)穩(wěn)定后，最主要的支出成本。

LTS?支持性

對于LTS（Long Term Support，長期支持版）支持性，這里又可以從兩個方面來討論。（1）商業(yè) HTAP 數(shù)據(jù)庫（2）開源 HTAP 數(shù)據(jù)庫無論對于商業(yè)數(shù)據(jù)庫還是開源數(shù)據(jù)庫都面臨某個版本的生命周期問題。
商業(yè)數(shù)據(jù)庫相對來說，其售后服務(wù)有保障，但同時商業(yè)數(shù)據(jù)庫又面臨閉源和售后服務(wù)需要支付昂貴的服務(wù)費用等問題。而開源數(shù)據(jù)庫，其 LTS 的支持除了需要社區(qū)支持以外，也需要由其背后的公司來進行保證。我們也很容易發(fā)現(xiàn)，一個成功的開源數(shù)據(jù)庫項目背后，通常都有一個成功的商業(yè)公司支撐。
因此，無論是選擇哪類 HTAP 數(shù)據(jù)庫，都需要注意所選擇的產(chǎn)品的 LTS 支持性的問題。
好了，以上就是我們總結(jié)的選擇一款 HTAP 數(shù)據(jù)庫需要考量的六大因素，也即：業(yè)務(wù)場景、性能、運維、生態(tài)、成本和 LTS 支持性，希望對于這六點的分析能給大家在做 HTAP 產(chǎn)品選型時提供幫助。