作者：李浩
編輯/設計：宇亭
當我們選擇一款 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 上。（Github搜StoneDB）