現(xiàn)在只要是個(gè)數(shù)據(jù)庫(kù)都肯定會(huì)說(shuō)自己是具有HTAP能力的，讓選擇數(shù)據(jù)庫(kù)的朋友有了選擇恐懼癥。實(shí)際上選擇數(shù)據(jù)庫(kù)用一句最簡(jiǎn)單的話說(shuō)就是只選對(duì)的，不選最好的。再好的數(shù)據(jù)庫(kù)產(chǎn)品，不符合你的應(yīng)用，運(yùn)維等方面的需求，對(duì)你來(lái)說(shuō)都不合適。話是簡(jiǎn)單，但是做起來(lái)并不容易。很多時(shí)候，適合不適合你，只有用了才知道。面對(duì)各種宣傳，確實(shí)很難做出判斷，哪怕說(shuō)我測(cè)試一下，數(shù)據(jù)庫(kù)這種復(fù)雜的IT基礎(chǔ)設(shè)施，測(cè)試也不那么容易做好做對(duì)。

按照上面的說(shuō)法，難道我們還真的無(wú)法去判斷和分析一個(gè)數(shù)據(jù)庫(kù)到底是不是真正具有HTAP能力呢？也不完全是這樣的，我們可以從HTAP數(shù)據(jù)庫(kù)應(yīng)該具有的幾個(gè)重要特征入手，去加以分析。為了沒(méi)有做廣告的嫌疑，今天的分析里面不會(huì)提及具體針對(duì)某些數(shù)據(jù)庫(kù)產(chǎn)品的比較，僅僅提出一些分析的原則。

首先要看TP/AP能力是不是原生融合的，也就是一個(gè)SQL引擎可以智能化處理TP/AP能力，最起碼TP/AP用用的入口是統(tǒng)一的，一套數(shù)據(jù)，多種處理引擎的模式雖然也能解決一些TP/AP的問(wèn)題，不過(guò)兩個(gè)引擎很難做統(tǒng)一資源管理，在某些時(shí)候會(huì)產(chǎn)生相互干擾，如果AP業(yè)務(wù)嚴(yán)重影響了TP業(yè)務(wù)的穩(wěn)定性，那么就會(huì)引發(fā)大問(wèn)題的。

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

其次是具有行存為主，列存為輔或者行列混合存儲(chǔ)的存儲(chǔ)機(jī)制。一個(gè)數(shù)據(jù)的寫(xiě)入一定是行存儲(chǔ)，不過(guò)必須具備數(shù)據(jù)通過(guò)列模式提供查詢的能力?；蛘邤?shù)據(jù)采用折中的方式，采用范圍分片后的行列混合存儲(chǔ)模式，既照顧TP應(yīng)用的行訪問(wèn)需求，也滿足AP應(yīng)用負(fù)載的列訪問(wèn)需求。

很多數(shù)據(jù)庫(kù)也號(hào)稱是行存列存都支持的，不過(guò)一張表只能建為行存表或者列存表，那么這種行列存儲(chǔ)能力對(duì)于HTAP的支持是打了折扣的，一份行存數(shù)據(jù)必須轉(zhuǎn)儲(chǔ)到列存表中，才能更好的支持OLAP業(yè)務(wù)負(fù)載。HTAP的準(zhǔn)實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)應(yīng)用能力就無(wú)法實(shí)現(xiàn)了。

第三個(gè)重要能力是OLTP/OLAP負(fù)載的隔離性，這兩種負(fù)載不能相互影響，應(yīng)該有一定的資源隔離和資源限制能力。能夠?qū)σ恍╅_(kāi)銷(xiāo)較大，執(zhí)行時(shí)間超長(zhǎng)的OLAP負(fù)載限定資源使用，避免造成對(duì)OLTP的太大的影響。

可以按需掛起/恢復(fù)后臺(tái)OLAP工作任務(wù)，臨時(shí)修改某個(gè)或者某些OLAP負(fù)載的資源限制等，都是HTAP能力精細(xì)化的體現(xiàn)。一個(gè)優(yōu)秀的HTAP系統(tǒng)，底層資源管理和任務(wù)調(diào)度做的好壞是關(guān)鍵。

第四個(gè)重要能力是資源擴(kuò)展的能力，計(jì)算能力，存儲(chǔ)能力，IO吞吐能力等都不存在嚴(yán)重的瓶頸，可以隨時(shí)進(jìn)行擴(kuò)展，以滿足日益增長(zhǎng)的業(yè)務(wù)需要。不管是通過(guò)MPP節(jié)點(diǎn)擴(kuò)展還是只讀節(jié)點(diǎn)擴(kuò)展，只要這種擴(kuò)展能力對(duì)你的業(yè)務(wù)場(chǎng)景是有效的，都是可以接受的，并不限于某種架構(gòu)。

第五個(gè)重要能力是SQL能力，SQL能力主要是考察SQL引擎和CBO優(yōu)化器的能力。支持的SQL標(biāo)準(zhǔn)，特別是統(tǒng)計(jì)函數(shù)，分析函數(shù)，窗口函數(shù)等的支持能力。并行掃描的能力，算子下推的能力，索引類(lèi)型的支持等都是重要的考察內(nèi)容。SQL引擎不能對(duì)表連接的數(shù)量以及表的規(guī)模有任何限制，也不能要求建表的時(shí)候必須指定SHARDING KEY。

第六個(gè)重要能力是容災(zāi)能力，這個(gè)能力和你的應(yīng)用對(duì)高可用，災(zāi)備的要求要相匹配?？梢詫?shí)現(xiàn)自動(dòng)化復(fù)制，自動(dòng)化切換，最小的RTO/RPO，甚至零數(shù)據(jù)丟失是最佳的選擇。

第七個(gè)重要能力是接口能力，是否能夠提供C語(yǔ)音、JDBC、ODBC/OLEDB等多種接口，支持你所是使用的主要編程語(yǔ)言等也是極為重要的，這對(duì)于你今后的應(yīng)用開(kāi)發(fā)與應(yīng)用遷移十分重要。現(xiàn)在的數(shù)據(jù)庫(kù)產(chǎn)品十分龐雜，有些數(shù)據(jù)庫(kù)產(chǎn)品甚至只提供一個(gè)JDBC引擎就敢發(fā)布了。

此外易部署，易管理、可觀測(cè)能力強(qiáng)、生態(tài)工具齊全、數(shù)據(jù)類(lèi)型支持、字符集支持等因素也是你需要去考慮的因素。如果你還需要從老數(shù)據(jù)庫(kù)上遷移數(shù)據(jù)和應(yīng)用到新系統(tǒng)，那么與你原有數(shù)據(jù)庫(kù)的SQL語(yǔ)法兼容性、數(shù)據(jù)復(fù)制工具、數(shù)據(jù)遷移工具的完備性與符合度等也是你必須考慮的因素。

數(shù)據(jù)庫(kù)選型是個(gè)既復(fù)雜又簡(jiǎn)單的事情，如果你能根據(jù)自己的實(shí)際情況，應(yīng)用場(chǎng)景去做理性的分析，不難找到一個(gè)相對(duì)靠譜的選擇。我上面提的一些點(diǎn)有些可能值得你去參考，有些可能也不一定適合你的現(xiàn)狀，總之，只有了解現(xiàn)狀，才能做出正確的選擇。