最近，在數據庫行業對HTAP（混合事務/分析處理，Hybrid Transactional/Analytical Processing）這個概念宣傳的非常火爆，也衍生出 Real-Time HTAP的說法，主要是因為隨着IT行業的發展，很多用戶的復雜業務已不再是單純的OLTP或者OLAP場景，而是二者皆有的混合場景。很多數據庫廠商為了響應這樣的需求，同時也為了更好的宣傳旗下數據庫的適用性足夠廣泛，就紛紛打出可同時支持OLTP和OLAP的混合負載，即支持HTAP的宣傳語。
當我們在網絡上去搜索“HTAP”關鍵字，相關信息很多會提到分布式/集中式架構、傳統數據庫/新型數據庫等等概念，本文就從這些相關概念來切入，拋磚引玉，試着理清面臨如今眾多的數據庫，對於有HTAP需求的用戶，究竟該如何理性的選擇。
1.分布式還是集中式？
首先這是一個非常值得深入思考的問題。由於現在“分布式”的概念很熱點，導致很多人會誤認為分布式數據庫也會是數據庫行業的唯一出路，似乎可以解決所有問題。 事實上，分布式也的確可以解決一些問題，比如接近線性的水平擴展；但是同樣分布式也會帶來一些麻煩，比如在互聯網行業最初興起的分庫分表方案（其實並不能算作真正的分布式）通常對應用有很大的侵入性，后來順勢發展起來的原生分布式數據庫也都逃不出CAP理論的制約、事務2PC的考慮、RPC的代價等等。 當然無論哪種方案，復雜還是簡單，都有其適用的場景，最終如何理性選擇，還是要依據具體需求，但有一個基本原則：大道至簡，能用集中式解決的就無需考慮分布式。如果您的業務系統集中式架構就可以完全滿足，卻選擇了分布式架構，那無形中就會多投入很多服務器資源，同時面臨許多分布式架構下獨有的挑戰。2.傳統數據庫還是新型數據庫？
好像如今一談到HTAP，都是各種新型的數據庫，那么，傳統的數據庫不能支持HTAP場景嗎？ 實際上並非如此，就以傳統數據庫中公認的老大哥Oracle為例，其本身的產品定位就是一款融合型的數據庫，無論是關系型數據、圖數據、空間數據、文本、XML、JSON、AP、TP等各種類型甚至包括區塊鏈相關數據，都能實時性解決。也就是說Oracle不但支持HTAP場景，而且能更好更全面的支持，就單拿它在支持多種數據類型這點，大多新型數據庫目前都還是做不到的。 那既然這樣，為什么會有很多人說Oracle承載OLAP表現不佳呢？其實這是一個歷史發展問題。就拿筆者之前負責運維過的項目舉例，大型運營商項目，典型HTAP場景，用戶最終設計還是將OLTP和OLAP分開的：使用Oracle去承擔典型的OLTP業務，另外采用Vertica這類MPP架構的數據庫去承擔OLAP；不得不說，這個專門跑分析類應用的數據庫，在執行大查詢的效率的確是非常高，實際進一步去對比發現，其中一點最本質的區別是行存還是列存的選擇問題，為了對OLAP有更好的效率表現，這類偏向於分析型的數據庫都是采用列存的設計。 起初這樣分開運行也能滿足業務需求，但隨着時代發展，用戶對分析類業務的實時性要求也越來越高，這種混合架構就不能很好保證了，而且期間大量ETL的維護工作也很讓人頭疼。幸運的是，技術也在不斷發展，Oracle在12c以后就推出了In-Memory列存，相當於解決了OLAP的效率問題同時又不影響OLTP的穩定運行。后續很多廠商聲稱支持的HTAP，基本也是參考了這樣的思路，用各種技術手段最終實現的核心都是行列混合存儲，從而更好的支撐HTAP場景，因為所有處理操作都是在同一套環境中，過去那種ETL/數據同步都不再需要，所以自然就實現了 Real-Time HTAP。3.水平擴展問題
通過上面兩節的討論，我們看到，HTAP本身和分布式/集中式、傳統數據庫/新型數據庫是沒什么直接的對應關系的。那為什么提到HTAP就總愛扯上分布式呢？ 這是因為隨着近些年來互聯網行業的蓬勃發展，一些用戶數據有了爆發性增長，傳統的架構下，通過scale-up擴容的方式已經不能很好的滿足這類需求，所以就演變成了分布式架構下scale-out擴容的方式，也就是我們說的水平擴展方式。 舉個例子，現在某產品，當前業務集中式完全可以承擔，但是考慮到未來會有爆發性增長（嗯..很多業務沾上一點互聯網屬性就變得這么有自信^_^），怕采用集中式架構后，以后擴容會遇到瓶頸。比如如今很多非常核心關鍵的應用對應的主數據庫都是由Oracle RAC來支撐的，但有人會說RAC這項技術的確很好，可當部署在傳統架構下遇到擴容需求時，在計算層，擴展RAC節點得不到接近線性的提升，如果使用不當還會出現嚴重的gc等待之類；在存儲層，雖然是高端存儲但總會有上限和I/O瓶頸。 其實早在Oracle Exadata一體機發布以后，這些問題就都被很好的解決掉了，Exadata 平台對數據庫服務器和存儲服務器均采用了一種可橫向擴展的架構，下圖展示了Exadata X8M-2的水平擴展能力：1/8 Rack -> 1/4 Rack -> 靈活配置 -> Multi Rack：
順便提下，在產品白皮書中也有明確提到，像上面1個Rack（一個滿機櫃）的X8M-2每秒就可以執行超過1600萬次8k數據庫讀取I/O操作或510萬次8k閃存寫入I/O操作。而且只要有需要，還可以繼續擴展為Multi-Rack，所以對那些可能爆發性增長的業務，如果擔心選擇傳統集中式架構下的Oracle在未來擴展時會有瓶頸，那么完全可以考慮換成Exadata平台，單體性能本身強悍的同時還解決了未來的水平擴展問題，而且因為沒有更換數據庫，應用也無需重新適配改造。
4.Exadata對OLAP的表現
以前筆者寫過一篇文章，把Exadata類比成我們所熟悉的iPhone手機，眾所周知都知道它的硬件配置並不如同年其他品牌的旗艦機高，但是給使用者的體驗確是最穩定的，這很大程度就是因為iPhone軟硬件一體，可以進行針對性的定制優化。 有熟悉Exadata的朋友曾開玩笑的說：在Exadata上的Oracle簡直就像個作弊器！這類評價也是得益於Exadata的強悍性能表現。下面來看一個DBA的真實體驗：
本來需要對664GB數據的大查詢，僅通過storage index特性就消除了527GB無關I/O，又通過smart scan特性讓剩下的137GB數據下沉在存儲中運行，這樣可以減少網絡消耗並減少數據庫CPU壓力，最終只返回符合條件的284MB結果數據給DB層，整個過程在15秒內完成。大家感興趣可以計算下，若是傳統架構下即便配置全閃存儲，沒有Exadata這些獨特的核心特性，直接查詢這664GB數據要花多久？
5.Exadata對OLTP的表現
Exadata一體機不但為OLAP帶來了卓越性能提升，也可以大幅度提升OLTP類應用效率。 有一定經驗的DBA可能會質疑，如果是非常典型的OLTP場景，管理的也非常嚴格，都是通過合適的索引訪問數據，不會出現沒有走索引這類情況，那么上面說的優勢就沒了吧？ 其實不然，以X8M為例，除了那些耳熟能詳的軟件特性帶來的性能提升之外，還充分利用了RoCE（RDMA over Converged Ethernet）+ PMEM（持久性內存） 技術，可以讓OLTP應用即便在遇到請求訪問的數據塊並不在內存中時（需要向存儲請求物理I/O），也能進一步加快響應，筆者從Exadata PM的介紹中，提煉出相關的幾點：- 1） 事務處理IO延遲提高10倍（單塊讀 ~ 19us）；
- 2） 日志寫入速度提高了8倍（~ 25us）；
- 3） 同時保證原子數據塊寫入PMEM；
- 4） 用於集群互連的遠程直接內存訪問（~ 10us）。
值得一提的是，RoCE + PMEM雖然快，但對於寫入操作並不算是一個好的選擇，因為PMEM具有的是8字節原子寫，而數據庫塊通常大小是8K，如果寫過程中突然斷電，如何確保不會導致分裂塊（壞塊）呢？
其實是由Exadata存儲軟件中的復雜算法來保證原子數據庫塊寫入PMEM，不會出現壞分裂。
另外，傳統架構上，存儲是無法感知數據庫發出的I/O請求屬於什么類型。所以有經驗的DBA可能遇到過OLAP占用大量IO資源導致影響了OLTP的效率，但是在Exadata上數據庫和存儲是可感知的，這就可最大程度避免優先級高的IO（比如log file sync）被其他優先級低的IO阻塞進而影響到業務。所以整體來說Exadata是可以更好的運行HTAP混合負載。
總結
上面我們談了一些HTAP的相關內容，現在回到最初的問題：如何選擇適合你的HTAP數據庫？這里筆者總結一些原則和判斷標准，算是拋磚引玉吧：- 1）架構選擇方面，分布式和集中式兩種架構各有優缺點，因為分布式架構更復雜，所以一般能用集中式解決的就無需考慮分布式，千萬不要為了分布式而分布式；
- 2）數據庫選擇方面，如果是核心類業務，首選Oracle數據庫，不但可以直接支持HTAP場景、支持更多數據類型而且更穩定可靠；如果是非核心類業務，輕量級的可以考慮MySQL這類開源數據庫（通常要配合其他開源產品），壓力大- 的則可以考慮分布式數據庫（一般不建議分庫分表那種實現方式）；
- 3）如果當前核心數據庫已經是Oracle，但又擔心未來幾年業務有爆發式增長，超出scale-up擴容瓶頸，那么最簡單的方式就是選擇遷移到Exadata平台。這樣就能夠實現scale-out（水平擴展），上文已經看到Exadata對不同負載的卓越表現，遷移之后應用也無需重新適配改造。
總的來說，當我們面對琳琅滿目的數據庫產品時，首先自身要有一個清晰的底層邏輯，清楚對應業務要求的到底是什么，而不能盲目跟風選擇，否則最后發現選擇了並不適合自家業務場景的架構或產品，將會給未來的工作帶來本不必要的負擔。