現在只要是個數據庫都肯定會說自己是具有HTAP能力的，讓選擇數據庫的朋友有了選擇恐懼癥。實際上選擇數據庫用一句最簡單的話說就是只選對的，不選最好的。再好的數據庫產品，不符合你的應用，運維等方面的需求，對你來說都不合適。話是簡單，但是做起來并不容易。很多時候，適合不適合你，只有用了才知道。面對各種宣傳，確實很難做出判斷，哪怕說我測試一下，數據庫這種復雜的IT基礎設施，測試也不那么容易做好做對。

按照上面的說法，難道我們還真的無法去判斷和分析一個數據庫到底是不是真正具有HTAP能力呢？也不完全是這樣的，我們可以從HTAP數據庫應該具有的幾個重要特征入手，去加以分析。為了沒有做廣告的嫌疑，今天的分析里面不會提及具體針對某些數據庫產品的比較，僅僅提出一些分析的原則。

首先要看TP/AP能力是不是原生融合的，也就是一個SQL引擎可以智能化處理TP/AP能力，最起碼TP/AP用用的入口是統一的，一套數據，多種處理引擎的模式雖然也能解決一些TP/AP的問題，不過兩個引擎很難做統一資源管理，在某些時候會產生相互干擾，如果AP業務嚴重影響了TP業務的穩定性，那么就會引發大問題的。

原生融合實際上對SQL引擎和優化器的要求很高，如果SQL引擎存在一些BUG或者有些考慮不周的地方，就可能會引起TP/AP負載被錯誤識別，引起不必要的麻煩，因此SQL引擎支持HINT是十分必要的，而且在HINT中最好一些針對TP/AP識別，只讀副本使用，弱復制一致性數據讀取，資源限制等方面的支持。

其次是具有行存為主，列存為輔或者行列混合存儲的存儲機制。一個數據的寫入一定是行存儲，不過必須具備數據通過列模式提供查詢的能力。或者數據采用折中的方式，采用范圍分片后的行列混合存儲模式，既照顧TP應用的行訪問需求，也滿足AP應用負載的列訪問需求。

很多數據庫也號稱是行存列存都支持的，不過一張表只能建為行存表或者列存表，那么這種行列存儲能力對于HTAP的支持是打了折扣的，一份行存數據必須轉儲到列存表中，才能更好的支持OLAP業務負載。HTAP的準實時數據倉庫應用能力就無法實現了。

第三個重要能力是OLTP/OLAP負載的隔離性，這兩種負載不能相互影響，應該有一定的資源隔離和資源限制能力。能夠對一些開銷較大，執行時間超長的OLAP負載限定資源使用，避免造成對OLTP的太大的影響。

可以按需掛起/恢復后臺OLAP工作任務，臨時修改某個或者某些OLAP負載的資源限制等，都是HTAP能力精細化的體現。一個優秀的HTAP系統，底層資源管理和任務調度做的好壞是關鍵。

第四個重要能力是資源擴展的能力，計算能力，存儲能力，IO吞吐能力等都不存在嚴重的瓶頸，可以隨時進行擴展，以滿足日益增長的業務需要。不管是通過MPP節點擴展還是只讀節點擴展，只要這種擴展能力對你的業務場景是有效的，都是可以接受的，并不限于某種架構。

第五個重要能力是SQL能力，SQL能力主要是考察SQL引擎和CBO優化器的能力。支持的SQL標準，特別是統計函數，分析函數，窗口函數等的支持能力。并行掃描的能力，算子下推的能力，索引類型的支持等都是重要的考察內容。SQL引擎不能對表連接的數量以及表的規模有任何限制，也不能要求建表的時候必須指定SHARDING KEY。

第六個重要能力是容災能力，這個能力和你的應用對高可用，災備的要求要相匹配。可以實現自動化復制，自動化切換，最小的RTO/RPO，甚至零數據丟失是最佳的選擇。

第七個重要能力是接口能力，是否能夠提供C語音、JDBC、ODBC/OLEDB等多種接口，支持你所是使用的主要編程語言等也是極為重要的，這對于你今后的應用開發與應用遷移十分重要。現在的數據庫產品十分龐雜，有些數據庫產品甚至只提供一個JDBC引擎就敢發布了。

此外易部署，易管理、可觀測能力強、生態工具齊全、數據類型支持、字符集支持等因素也是你需要去考慮的因素。如果你還需要從老數據庫上遷移數據和應用到新系統，那么與你原有數據庫的SQL語法兼容性、數據復制工具、數據遷移工具的完備性與符合度等也是你必須考慮的因素。

數據庫選型是個既復雜又簡單的事情，如果你能根據自己的實際情況，應用場景去做理性的分析，不難找到一個相對靠譜的選擇。我上面提的一些點有些可能值得你去參考，有些可能也不一定適合你的現狀，總之，只有了解現狀，才能做出正確的選擇。