資料庫HTAP能力強弱怎麼看

現在只要是個資料庫都肯定會說自己是具有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語法相容性、資料複製工具、資料遷移工具的完備性與符合度等也是你必須考慮的因素。

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