HTAP數據庫調研

「本文已參與好文召集令活動，點擊查看：後端、大前端雙賽道投稿，2萬元獎池等你挑戰！」

1. HTAP數據庫背景及現狀

1.1 起源

• 大型實時分析應用的逐漸流行（實時庫存/訂價、欺詐檢測，風險分析，物聯網等）；
• 這些系統須要一個分佈式的數據管理系統，要求能處理高併發的TP請求，同時支持對近期的數據進行分析；
• 有些應用甚至會在TP請求中進行AP操做；
• Gartner：即有事務又支持分析的系統叫HTAP；
• 實時分析：指的是實時交易過程當中的分析需求，不是數據時效性上的實時。

1.2 方案1：一套系統同時支持OLTP和OLAP

• 傳統的DBMS能夠在一套系統上支持TP和AP，但對這兩種業務場景都不高效；
• 基於內存的行存（ VoltDB, Hekaton, MemSQL, Silo）和列存（ MonetDB , Vertica , BLU , SAP HANA）系統，這些系統開始只是爲一個場景專門設計的，後來爲了支持HTAP增量了另外一場景的支持。

1.2.1 底層數據分開存儲

• SAP HANA 和 Oracle’s TimesTen 最初是爲OLAP專門設計的，同時也支持ACID事務操做；不過事務的數據時以行存方式支持的，而分析操做是經過列存支持的；
• MemSQL最初是爲in-memory OLTP設計的，後來也支持分析。對於TP數據是以行存方式存在內存中的，當數據須要寫到磁盤中時，會轉換成列存；
• IBM dashDB也是從傳統的行存向HTAP演進的系統。經過行列混合的方式來分別支持TP和AP；
• HyPer是從一開始就爲HTAP設計的，最初使用行存來同時支持TP和AP，不過如今也支持經過列存方式來更好的支持AP場景。

1.2.2 底層用一種方式存儲數據

• H2TAP，學術項目，以行存的方式同時支持TP和AP；
• Hive，SQL-on-hadoop的解決方案之一，AP系統，在0.13版本開始經過ORCFile支持事務，但主要的應用場景是維度表更新以及實時流數據攝取；
• Impala + kudu：支持SQL分析及數據的更新和刪除。
  這類系統跟傳統DBMS面臨一樣的問題，沒辦法同時爲AP和TP進行優化。對於採用列存的系統，須要經過批量的方式來提升事務的吞吐能力；對於採用行存的系統，沒法實現最佳的分析效果。

1.3 方案2：兩套系統來組合來支持OLTP和OLAP

1.3.1 解耦AP和TP的底層存儲

現狀

• 須要用戶的應用程序本身來協調AP和TP系統的使用；
• 數據在兩個系統之間是經過ETL方式同步的；
• 這類方案在目前的大數據系統中很是常見，一般使用kv系統（如cassandra）來承載TP負載，而後將數據轉換成 Parquet or ORC 文件存儲到HDFS中，再使用SQL-on-hadoop方案進行數據分析。

1.3.2 AP和TP共享底層存儲

這類系統一般是使用Spark之類的系統，在原有數據上支持大規模分析的場景。因爲數據只有一份，所以AP分析的數據是實時數據。

• SAP HANA Vora：TP業務負載有vora直接支撐，而分析場景則經過Spark-SQL來支持；
• SnappyData：使用GemFire來承載TP業務，經過Spark生態來支持AP業務；
• HBase 和Cassandra等kv系統被普遍應用在須要實時更新的場景，而對這些數據的分析場景在經過組合SQL-on-Hadoop的解決方案來實現。TP和AP系統訪問的是同一份數據，這須要開發一些額外的擴展，以使得AP引擎能直接讀取TP存儲中的數據，好比Spark HBase connector，Spark Cassandra connector等。經過connector來進行AP分析一般很是慢；
• 另一些SQL-on-hadoop系統，使用HBase做爲支持快速更新的存儲引擎，如： HIVE， Impala, IBM Big SQL, and Actian VectorH。數據的處理是經過HBase的處理引擎來實現的；
• Splice Machine 、 Phoenix則是在HBase之上構建了SQL引擎；
• 基於HBase的AP系統，在處理AP任務時都比較慢，由於在HBase上執行Scan很是慢。HBase適合快速更新和點查的場景；
• Wildfire：IBM最近開發的一套HTAP系統，使用列存方式來同時支持AP和TP，使用的是Parquet格式。Wildfire能夠當即分析最近提交的更新，同時支持使用Spark生態來執行大規模並行分析任務，提交給SparkSQL的請求會被儘量的下沉到Wildfire引擎來進行數據處理。

1.4. 現狀總結

• 目前沒有一個系統支持true-HTAP；

  • 大多數系統已經分別支持了AP請求和TP請求的處理，可是沒有系統支持在TP中執行AP的場景；
  • 要支持真正的HTAP，須要支持在同一個請求中既有TP又有AP的場景。

• 目前大多數系統須要組合各類解決方案來達到HTAP場景的需求，這對用戶部署和維護系統帶來挑戰；

• 目前大多數TP系統爲了加速TP的更新和點查，將索引所有放在了內存中，可是對於更大規模數據的場景，索引所有在內存中會致使TP系統變慢，應當考慮一種僅保留部分索引在內存中的方案，以提升經常使用數據的訪問性能；

• 爲AP場景設計的存儲引擎，一般使用對象存儲或者共享文件系統來存儲數據。這些存儲格式主要是爲scan場景進行優化，沒法提供高效的點查和更新能力。目前這仍是一個未解決的難題。

1.5. 設計HTAP系統要作的一些決策

• Query processing and ingestion engines（數據分析和數據攝取引擎） 
• Storage options （存儲方式：一套存儲仍是混合存儲）
• Data organization （數據組織格式：行存仍是列存）
• Transactional semantics （事務語義）
• Recency of data being read by OLAP
• Indexing support（索引支持）

2. HTAP類數據庫分析

2.1 TiDB

2.1.1 TiSpark

所屬分類

• 兩套系統來組合來支持OLTP和OLAP（採用Spark生態）
• AP和TP共享底層存儲

TiSpark 是將 Spark SQL 直接運行在 TiDB 存儲引擎 TiKV 上的 OLAP 解決方案

• TiSpark 深度整合了 Spark Catalyst 引擎, 能夠對計算提供精確的控制，使 Spark 可以高效的讀取 TiKV 中的數據，提供索引支持以實現高速的點查
• 經過多種計算下推減小 Spark SQL 須要處理的數據大小，以加速查詢；利用 TiDB 的內建的統計信息選擇更優的查詢計劃

2.1.2 TiFlash

所屬分類

• 底層數據分開存儲，TP採用行存，AP採用列存

  • AP存儲在必定程度上屬於TP的一個副本，在比較高的層面上來看，能夠認爲是一套存儲同時支持行列

• 兩套系統來組合來支持OLTP和OLAP，TP經過原生的TiDB來支持SQL和事務；AP則經過TiFlash（基於clickhouse開發的向量化分析引擎）來實現

  • 經過動態的SQL路由，TiDB在更高的層面隱藏了AP和TP引擎

技術實現

• TiFlash 基於列存和向量化分析引擎（Clickhouse）實現；
• TiFlash 做爲 TiDB 的另一個存儲層，經過raft learner從TiDB 複製數據，並保證數據的事務性；
• TiFlash目前不支持SQL直接寫數據，所以其角色目前不能成爲leader或者follower；
• TiFlash節點若是發生故障，須要從TP集羣從新同步數據；
• TiFlash做爲TiDB的擴展，屬於TiDB集羣的一部分；
• 經過全局時間戳來保證用戶從TiFlash中讀到的是最新的數據；
• 經過LSM-Tree來解決列存的更新帶來的寫放大問題；同時利用其局部有序性來解決AP場景對scan的需求；
• 能夠經過動態增減不一樣類型的節點來增減，TP或AP能力；
• TP節點和AP節點在系統層面有不一樣的標籤，當啓發式算法任務用戶下發的SQL是一個AP運算時，會將請求路由到AP節點上執行。在必定程度上隱藏了AP和TP的具體角色分配；
• 一條join語句的兩部分數，一份數據須要全表掃描、另外一份能夠利用索引，則能夠分別將這兩個子查詢調度到不一樣類型的節點上執行，一部分利用TiFlash的scan能力、一部分利用TiKV的點查能力。

後續計劃

• 支持SQL直接更新TiFlash中的數據
• TiFlash支持MPP，從而能夠將TiDB或TiSpark的一部分計算下推到TiFlash執行
• 從新設計TiFlash的存儲引擎，從而將性能提高2倍（目前TiSpark+TiFlash的性能，與Spark+Parquet的性能差很少）

TiKV
對應yugabyte的TabletServer（即DocDB），定位和實現框架幾乎差異不大，都是在實現一個支持事務的分佈式kv。TiKV是一個單獨的項目，更解耦（意味着性能要差）。

• 都是提供RPC接口
• 都是Raft
• 都是基於rocksdb

2.2 MemSQL

技術細節

所屬分類

• 一套系統同時支持OLTP和OLAP
• 底層數據分開存儲

技術實現

• completely in-memory rowstore（行存，所有在內存中，爲TP/HTAP服務，主要針對實時場景）

• disk-backed columnstore（數據寫到磁盤時，改爲列存，爲AP以及須要查詢大量歷史數據的HTAP應用服務）

• 一條查詢語句能夠同時查詢內存和磁盤中的數據

• 也支持內存沒法承載狀況下的OLTP任務（使用hash indexes）

• 主從複製模式，支持同步和異步。同步會致使寫延遲變高，異步複製則從節點數據落後一段時間

• 沒看到如何實現列數據的更新的（MemSQL開啓了列存的表不適合頻繁更新的場景<參考>）

• MVCC + lock free 充分發揮內存的性能

  • 每當事務修改一行時，MemSQL都會建立一個新版本，該版本位於現有版本之上。該版本僅對進行修改的事務可見。Read查詢訪問同一行，「查看」該行的舊版本；
  • MemSQL僅在同一行發生寫-寫衝突的狀況下才使用鎖；
  • MemSQL爲死鎖實現了鎖等待超時。默認值爲60秒；
  • MemSQL將已修改的行排入垃圾收集器。經過避免全表掃描，垃圾收集器能夠很是有效地清理舊版本；
  • MemSQL儘量將單行更新查詢優化爲簡單的原子操做；

• skip list 代替btree，以提供更好的擴展性（skip list能夠實現lock free訪問，更適合純內存場景）

• code gen，提升SQL查詢性能

  • 將SQL編譯成C++代碼，而後用GCC編譯成native code，動態加載到MEMSQL進程。該過程是在SQL首次執行時進行的，而且編譯後的代碼重啓後仍舊有效；
  • 編譯後的結果會被存儲到hash表中，下次若是有相同模式的sql請求，直接使用編譯後的代碼執行。

• CPU效率意味着更高的吞吐量。因爲MemSQL每一個查詢使用較少的指令，所以它們能夠實現更高的吞吐量

• 無鎖數據結構擴展性好，同時也減小了數據爭用期間致使的CPU浪費。MemSQL引擎的每一個組件都創建在無鎖的數據結構上：鏈表，隊列，堆棧，跳錶和哈希表

• 內存數據持久化：定時快照+WAL

  • 事務首先提交到內存緩衝區中，而後異步開始寫入磁盤。日誌刷新器線程每隔幾毫秒將事務刷新到磁盤一次，經過批量提交來提升磁盤IO吞吐；
  • 當日志文件達到已經大小時（2G），會壓縮成快照。快照更緊湊、恢復更快；
  • MemSQL徹底避免了頁面交換，而且能夠保證在讀/寫查詢上具備一致的高吞吐量SLA。MemSQL中的任何讀取查詢都不會等待磁盤。此屬性對於對數TB的數據進行實時分析掃描極爲重要。

• Aggregator：專門的聚合節點，相似Gateway，負責接收用戶的查詢請求，將請求調度到leaf節點，對查詢結果進行聚合，返回最終結果給客戶端。根據系統負載，能夠配置任意數量的Aggregator節點

• 對於開啓了列存的表，數據也會先寫到內存中的面向行的skip list中，而後批量往列存中刷；只要數據寫到內存skip list中，對客戶端就是可見的

特性&定位

• 支持從各類數據源（文件、kafka、數據庫、S三、HDFS）load數據
• 能夠在一條語句中對實時數據和歷史數據進行操做
• Full SQL. MemSQL supports full SQL and transactional semantics.
• 只支持READ COMMITTED隔離級別
• 支持冗餘和持久化
• 面向高併發、高吞吐、小事務的場景
• 面向須要使用MEMSQL賺錢的場景：由於純內存架構比較昂貴
• 解決實時需求，能回答當前正在發生什麼事情的場景
• 提供實時分析功能，如：min、max、distinct、average
• 不是和BI場景
• Write-heavy, read-heavy workloads：Machine data、Traffic spikes、Streaming data

2.3 HyPer

簡介

HyPer最開始是一個學術項目，產出了很多最新的研究成果。目前已經被收購。

3. 其餘數據庫

• kudu

  • HTAP： 放棄事務，只保留TP系統的高性能點查、插入特性；列存：提升OLAP的性能

參考資料

Hybrid Transactional and Analytical Processing - A Survey
blog.csdn.net/tidb_pingca…
blog.csdn.net/TiDB_PingCA…
docs.memsql.com
www.hyper-db.de/
www.memfiredb.com