作者：李浩

責編：宇亭

當我們選擇一款 HTAP 資料庫時，總是先被其相關文件裡所描述的優異效能所吸引。卓越的效能是我們選擇一款產品的出發點，因為我們希望該款產品能夠解決我們業務中的痛點。而大家使用 HTAP 產品的出發點就是希望該款資料庫能夠解決我們在事務處理過程中的實時分析痛點。不過，效能優勢只能算作我們選擇一款產品的考量因素之一，實際上，公司層級去選擇一款HTAP產品時，還需要額外考量一些其他的因素，本篇文章，StoneDB首席架構師李浩給大家分享一下選擇 HTAP 產品的六大關鍵考量因素。

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

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

業務場景

 

首先，我們從業務場景的角度來討論如何選擇一款HTAP資料庫，主要有以下四個維度：

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

1.2、端到端的解決方案能力：
對於業務開發相關人員，一個新產品或者解決方案的引入，自然希望不會給其帶來額外的工作負擔，並且最好能夠與其原有的技術棧相相容，這樣對於原有業務系統的改動要求最少 。但也不完全就是為了讓乾的活兒更輕鬆一些，因為，對於一個線上執行的系統，其對於穩定性的要求非常高，而新元件的引入往往會讓整個業務的不穩定因素增大。因此，如果不能夠保持原有的技術棧，則需要提供端到端的解決方案。例如： 原系統採用的 ClickHouse 或者 ElasticSearch， 如果需要替換為 OB 或者StoneDB ，那麼需要考慮原系統 ClickHouse 或者 ElasticSearch 上下游相關模組介面相容性，資料同步 到 CK 或者 ES 的方式等等，這些解決方案都要提供出來。
1.3、資料實時性要求：
資料實時性的高低同樣也會影響到產品的選擇。 當前現有的 HTAP 資料庫在 TP和 AP 之間的資料同步策略實現機制不盡相同。例如：有些雲廠商通過 MySQL+Binlog+ClickHouse 的組合方式提供 HTAP 服務，從使用者的角度看似乎該服務具備了HTAP的能力，但實際上完全不是那麼回事兒——因為通過 Binlog 這種方式會有很多弊端，這裡可以參考我們之前的兩篇文章；又如有廠商通過 TP+Redo+Raft+AP 這樣的組合構成 HTAP 產品，其相較於前一種在資料的實時性上有了較大的提升，但也只是提供資料的最終一致性，同樣資料的實時性還是得不到保證；有的廠商則採用了基於 LSM-tree 實現的行列混存，這種可以基本保證對於資料實時性的要求；而像 MySQL Heatwave 和 StoneDB 則提供了基於記憶體計算的強實時性的方案。
HTAP 資料庫在產品具體實現的時候，其選擇的儲存方案會直接到影響架構的選擇：是一體化的架構？還是 TP 系統疊加 AP 系統的方案？架構的選擇則會直接決定資料同步策略和資料實時性的高低。
1.4、技術能力：
產品背後其公司所代表的技術實力也是業務方選擇一款產品的考量因素，例如：我們在下文第六點中給出的觀點。  

效能

考量完業務場景相關的因素後，接下來需要考量的一個重要因素就是效能。不同於TP系的 Benchmark TPC-C 或者 AP 系統的 Benchmark TPC-H，對於HTAP 的效能測評一般不再使用這兩個傳統的方式來進行衡量。

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

 

運維

運維的難度也需要我們認真考量。 資料庫的運維不同於其它基礎系統，其對於 DBA 的綜合素質有比較高的要求。在系統長時間執行的過程中會遇到各種資料庫的使用、功能、效能等等問題。解決這些問題除了需要資料庫、 作業系統和業務等多方面的知識，同樣也需要相關運維工具的支援。運維手段和運維工具可以高效的支援 DBA 的運維工作。複雜的系統形態，會導致 DBA 的運維工作量增大，最直接的影響就是難以快速定位問題，增加了解決問題的耗時。

 

 

生態

生態是選擇一款 HTAP 資料庫的一個重要因素。 當前有兩類生態：PostgreSQL 和 MySQL。選擇哪一種生態，會直接影響到後續圍繞資料庫所構成的整個技術棧。同時，業務也會從其自身的特點選擇相應的技術路線。例如：如果業務系統是基於 JSON 和 GIS 能力的話，那麼多數的業務開發者可能更傾向於選擇 PostgreSQL 生態；如果是電商業務則更多的會選擇 MySQL 生態。
具體來講，生態中的周邊工具、中介軟體和解決方案的完整性和豐富性非常重要。除工具、方案外，社群參與的人數（不管是對開源的 HTAP 資料庫，還是對於商業或雲上的 HTAP 服務，都需要考量該使用該服務的人群數量），更多的社群參與人數往往意味著社群比較活躍，那麼，我們使用者遇到的一些問題就可以得到快速的響應。
生態的繁榮也從另外一個側面反映出該技術路線獲得了相當多的上下游廠商的支援。

 

 

成本

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

5.1、硬體成本：
其中最主要包括： 計算成本和儲存成本。 在 StoneDB 實際的產品 POC 過程中，遇到很多客戶實際的業務資料量在 100GB-1TB 內。如果採用一些現有的其他國產 HTAP 產品，由於這些產品對最小叢集有要求，從而使得這些小廠商在使用 HTAP 服務時，必須付出比較高的叢集硬體成本，這個是他們不願意接受的。特別地，當需要替換現有MySQL資料庫的時候，目前的一些國產 HTAP 資料庫，基本都存在 MySQL 語法相容性的問題，這導致遷移到新的業務系統上需要進行大量的修改，從而造成整體成本的飆升。如果廠商比較在乎這一部分的成本的話，StoneDB 就是很好的選擇了。
5.2、替換成本：
需要能夠提供對於原系統的 平滑遷移 能力。對於業務侵入改動最小，業務無需做修改即可平滑遷移到新的資料庫平臺。
5.3、運維成本：
在第三點中我們討論運維問題，這裡就不再詳細討論了。運維成本將會是系統穩定後，最主要的支出成本。

 

LTS 支援性

對於LTS（Long Term Support，長期支援版）支援性，這裡又可以從兩個方面來討論。 （1）商業 HTAP 資料庫 （2）開源 HTAP 資料庫 無論對於商業資料庫還是開源資料庫都面臨某個版本的生命週期問題。
商業資料庫相對來說，其售後服務有保障，但同時商業資料庫又面臨閉源和售後服務需要支付昂貴的服務費用等問題。而 開源資料庫，其 LTS 的支援除了需要社群支援以外，也需要由其背後的公司來進行保證。我們也很容易發現， 一個成功的開源資料庫專案背後，通常都有一個成功的商業公司支撐。
因此，無論是選擇哪類 HTAP 資料庫，都需要注意所選擇的產品的 LTS 支援性的問題。
好了，以上就是我們總結的選擇一款 HTAP 資料庫需要考量的六大因素，也即：業務場景、效能、運維、生態、成本和 LTS 支援性，希望對於這六點的分析能給大家在做 HTAP 產品選型時提供幫助。
StoneDB 的 2.0 架構完全對標 Oracle MySQL MDS（HeatWave），目前，我們的架構設計方案的RFC文件也完全公佈在了 Github 上： https://github.com/stoneatom/stonedb/issues/436  如果您想了解更多，也可以關注我們的 Github 倉庫： https://github.com/stoneatom/stonedb 本週五（12月9號）下午，StoneDB 開源社群PMC、StoneDB 首席架構師李浩老師也將參與由 ITPUB 社群舉辦的開源小秀場線上 Meetup 活動，歡迎大家前往官網 http://os.itpub.net/ 關注：

以上就是本次的分享，歡迎大家批評指正。如果您還有其他疑問，歡迎新增StoneDB小助手，加入StoneDB開源社群技術交流群，在群裡您可以隨時提問，我們會認真為您解答。

 

掃碼新增小助手

加入StoneDB開源社群使用者群

討論交流，共同進步