作者：李浩責編：宇亭當我們選擇一款 HTAP 資料庫時，總是先被其相關文檔里所描述的優異性能所吸引。卓越的性能是我們選擇一款產品的出發點，因為我們希望該款產品能夠解決我們業務中的痛點。而大家使用 HTAP 產品的出發點就是希望該款資料庫能夠解決我們在事務處理過程中的實時分析痛點。不過，性能優勢只 ...

file

作者：李浩

責編：宇亭

當我們選擇一款 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？實踐篇》的下一章進行討論。

file

業務場景

首先，我們從業務場景的角度來討論如何選擇一款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、技術能力：

產品背後其公司所代表的技術實力也是業務方選擇一款產品的考量因素，例如：我們在下文第六點中給出的觀點。

file

性能

考量完業務場景相關的因素後，接下來需要考量的一個重要因素就是性能。不同於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 負載運行於不同的節點上，從而做到真正的物理隔離。

file

運維

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

file

生態

生態是選擇一款 HTAP 資料庫的一個重要因素。當前有兩類生態：PostgreSQL 和 MySQL。選擇哪一種生態，會直接影響到後續圍繞資料庫所構成的整個技術棧。同時，業務也會從其自身的特點選擇相應的技術路線。例如：如果業務系統是基於 JSON 和 GIS 能力的話，那麼多數的業務開發者可能更傾向於選擇 PostgreSQL 生態；如果是電商業務則更多的會選擇 MySQL 生態。

具體來講，生態中的周邊工具、中間件和解決方案的完整性和豐富性非常重要。除工具、方案外，社區參與的人數（不管是對開源的 HTAP 資料庫，還是對於商業或雲上的 HTAP 服務，都需要考量該使用該服務的人群數量），更多的社區參與人數往往意味著社區比較活躍，那麼，我們使用者遇到的一些問題就可以得到快速的響應。

生態的繁榮也從另外一個側面反映出該技術路線獲得了相當多的上下游廠商的支持。

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

5.1、硬體成本：

其中最主要包括：計算成本和存儲成本。在 StoneDB 實際的產品 POC 過程中，遇到很多客戶實際的業務數據量在 100GB-1TB 內。如果採用一些現有的其他國產 HTAP 產品，由於這些產品對最小集群有要求，從而使得這些小廠商在使用 HTAP 服務時，必須付出比較高的集群硬體成本，這個是他們不願意接受的。特別地，當需要替換現有MySQL資料庫的時候，目前的一些國產 HTAP 資料庫，基本都存在 MySQL 語法相容性的問題，這導致遷移到新的業務系統上需要進行大量的修改，從而造成整體成本的飆升。如果廠商比較在乎這一部分的成本的話，StoneDB 就是很好的選擇了。