數據庫在海量數據處理中的進化

大數據方案提供商，在幫助企業客戶處理流向數據的過程不可避免的要面對如何處理大量的數據問題。雖然說數據處理一個老話題，但是時代在變化，技術在進化，解決的問題思路也需要與時俱進，在處理數據的過程中，技術人員也在不停的思考和實踐，更好的發揮出技術優勢來解決問題。

以下內容來自為醫藥產業開發互聯網和大數據解決方案的未名企鵝供稿，作者為高級架構師Joseph，文章體現了他和團隊在傳統關系數據庫升級到分析型數據庫這個過程中的一些實踐和思考。

傳統關系數據庫的瓶頸

數據是所有業務處理的基本對象，數據的處理能力會受多方面的限制。其中數據庫就是數據處理能力的重要提供者。 

傳統關系型數據庫指的是 MySQL、SQL Server、Oracle 等嚴格執行事務ACID原則的數據庫。其關注點在于事務的處理、單機的存儲性能。一般項目啟動時會選擇一款數據庫，為數據的存儲和事務處理提供支持。但傳統關系型數據庫的性能受限于主機的硬件性能和強事務保證的算法邏輯。

隨著業務的拓展，數據量激增。使得我們不得不直面傳統關系數據庫的問題。

首先會遇到大表的檢索問題。當一個表中的數據激增到大幾百萬或上千萬時，會發現即使使用索引的查詢也變的越來越慢了，甚至盲目增加索引會造成寫入困難。這個時候可能會考慮按時間(或按其他條件)分表分庫來解決問題。如需求穩定，這種分庫分表的方式還算可以接受。然而這些給業務層帶來額外的開發量，增加了處理的復雜度。

隨著數據量的繼續增長，數據的存儲量增加。單節點的存儲能力問題會逐漸顯露。靠簡單的擴容硬盤來提高存儲能力會變得越來越困難，成本也會隨之升高。更要命的是單節點的故障風險也會增加。數據丟失、 服務器宕機等任何一個問題的恢復時間會長到無法接受。此時有人會提出使用多個主機運行多個數據庫實例，并結合分庫分表的方案來解決問題。 

進行多主機的方案實施后會發現， 采用多實例方案會引入大量的開發量。寫入時數據的分配問題、聚合計算的問題、單節點很容易實現的功能會在多節點上實現變得異常困難。因此急需一個中間環節來對上層業務屏蔽這些復雜化的動作。

傳統數據庫的增強、中間件的應用及問題

在這樣的背景下，數據庫中間件應運而生。如MyCat這樣出色的中間件，它對上層業務屏蔽了多實例操作的復雜問題，讓業務使用起來如同單機一樣。 

業務在不斷變化，需求復雜多樣。好景不長，表結構的修改變的不可避免，之前穩定的分庫分表策略開始被頻繁被挑戰。更改表結構漫長的等待時間逐漸讓你失去耐心，意外的數據傾斜讓你不知所措。

列式數據庫的興起

列式數據庫 HBase 、Hive 的出現讓人眼前一亮，新的設計理念，拋棄了對事務ACID的執著，專注于對大表(Big Table) 的處理。從大數據處理本身出發，沒有了傳統關系型數據庫的包袱，輕裝上陣，浴火重生。
如果說傳統關系型數據庫的存儲時以記錄為單位，那么一條記錄為一行，因此可以稱為行數據庫。列數據庫按記錄里的字段進行分割存儲，因此稱為列數據庫。

列式數據庫獨有的特性

* 存儲容量無限擴容

* 按列聚集存儲，高壓縮比，高存儲空間利用率

* 列即是索引

* 可預分區解決擴容極限問題

如此優秀的特性一度成為大數據處理的標配。如果說傳統關系型數據庫解決的問題的重點在于事務，那么列式數據庫解決問題的重點在于大數據分析，因此將傳統關系型數據庫分類至OLTP聯機事務處理(On-Line Transaction Processing)數據庫，列式數據庫分類至OLAP聯機分析處理(On-Line Analytical Processing)數據庫。至此數據庫向兩個方向齊頭并進。  

列式數據庫的局限性

雖說列式數據庫解決了大部分大數據分析的痛點，但在逐漸豐富的功能需求下，依然暴露出了短板。

* 實時響應要求高的系統無法接受秒級響應* 缺失事務管理能力，很難保證數據完整性，需要業務層介入* 運維成本高，依賴Hadoop生態眾多項目，運維管理開發困難都較大

在實際使用當中，用于OLAP數據實際上是經過大量繁瑣且昂貴的ETL操作才進入到數據庫中的，數據在處理的過程中，為了保證高可用的狀態，會保存多份，極大的增加對數據操作的成本，管理的復雜度，人力成本等等。同時如果實時響應的需求變得迫切。有些必要的事務動作不得不加入。在此背景下對部分數據的存儲被迫使用其他數據庫替代，如此操作又引入了數據的同步問題和存儲空間的浪費。數據版本的管理不當容易引發災難性后果。

新型數據庫功能和性能的對立統一

從列式數據庫的使用經驗可以得知，真正的實際使用需求是既要能分析大數據，又要有事務控制能力。最好不要讓業務管理多個版本的數據，否則既浪費存儲資源，又增加開發成本。綜上可以歸納為一條，擁有傳統數據庫的事務控制和實時響應能力，性能上又不受數據量影響。

對于以上存在的問題，我們更傾向于采用集成系統，能夠同時支持OLTP和OLAP操作，中間不需要有大量的ETL操作。也就是具備HTAP混合事務和分析處理(Hybrid Transaction and Analytical Process)的能力。

已知列式數據是放棄了事務功能才獲得大數據處理的優勢，那么現在重新組合在一起，真的可行嗎？

為此我們調研了現在能找到具備這種特性或潛力的數據庫，TiDB就是其中一種，在分布式KV存儲引擎上實現了事務控制、計算下推等能力。從而可以應對大量數據查詢。從TiDB的架構設計上可以看出，其本質上依然是行式數據庫，所以可以擁有很好的數據完整性控制能力，同時擁有分布式的存儲擴容能力。但復雜查詢的性能依然無法讓人滿意。好在后續推出了 TiSpark 彌補了這一缺陷，擁有了列數據庫的能力，通過冗余的存儲換取了復雜查詢的性能。

同樣功能的產品Aliyun的AnalyticDB采用行列混合存，最大程度滿足了分析、和實時響應的需求，同時運維便捷。由于沒有像TiSpark一樣應對OLAP的接口，只能使用SQL操作，在應對復雜分析時略顯語法表達能力的不足。

合適的才是最好的

可以預見HTAP將成為數據庫發展的主流方向，甚至傳統數據庫如Mysql也默契的在新版本中加入OLAP特性來應對需求的升級。HTAP也并非完善無缺，在這個過程中需要有專業的團隊去綜合判斷。

我們在追求極致的用戶體驗時從不迷信哪種技術可以解決一切問題，能在功能和成本上找到一個平衡點才是最佳的方案。

專業的事情交給專業的團隊來做，未名企鵝在技術方向上投入了大量的人力和財力，專注于為客戶提供開箱即用的數據處理平臺，使客戶無需再考慮復雜的技術實現問題，專注于自業務即可。

責編：Luffy Liu

（本文授權編輯轉載自公眾號“未名企鵝”，電子工程專輯對文中陳述、觀點保持中立）