作者：李浩

責編：宇亭

當我們選擇一款 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 2.0 云原生分布式實時 HTAP 架構詳細設計以 RFC 形式持續進行，歡迎大家關注我們最新進展，更歡迎給我們開源協作的模式和方法提出改進意見，一起通過開源的方式共建 StoneDB ~

https://github.com/stoneatom/stonedb/issues/436

• StoneDB 代碼已完全在 Github 開源：

https://github.com/stoneatom/stonedb

• StoneDB 官網：

https://stonedb.io/

標籤：MySQL

上一篇：1.5.4 HDFS 客戶端操作-hadoop-最全最完整的保姆級的java大資料學習資料

下一篇：糟糕，資料庫例外不可用怎么辦？