閱讀995 返回首頁    go 阿裏雲 go 技術社區[雲棲]


PgSQL · 特性介紹 · 列存元數據掃描介紹

摘要

本文通過對於阿裏雲分析型數據庫HybridDB for postgresql 數據庫的列存掃描的優化特征的解析,讓大家了解列存元數據掃描是如何達到提升查詢掃描的速度的效果。從而使的分析型查詢執行時間進一步縮短。最終能夠更好的為阿裏雲的用戶提供更高性價比的服務。

關鍵字

Meta data scan,HybridDB for postgresql, GreenPlum,column store,MPP
元數據掃描,列存

一、前言

人類社會已經進入了大數據時代,在這個時代人們置身於數據的海洋裏,誰能夠比別人更好,更有效率的, 將對自己有用的數據提取出來,誰就能更有力的獲得先機,通過對數據的處理分析,來達到對未來的決策。可以毫不誇張的說,誰能夠更準確,更快的掌握數據,誰就能夠領先他人。

分析型數據庫就是對人們已經掌握的數據,進行分析匯總,實時計算並輸出結果供人們在做決策的時候進行參考或者回顧。目前人們對於分析型數據庫的要求越來越高,希望它能夠處理越來越大規模的數據量,但是處理時間能夠越來越短。正是基於這樣的需求,分析型數據庫的數據處理能力的提升便成為我們數據庫內核研發人員的永恒的話題。

這篇文章,我們將為大家介紹分析型數據庫提升掃描能力的一個特征:元數據掃描,通過對列存儲格式的數據表增加元數據信息,從而達到提升數據掃描速度的效果。在第2部分,為大家簡單介紹一下元數據掃描的原理與技術實現;
第3部分,為大家介紹元數據存儲的設計原理與實現;第4部分為大家介紹 元數據掃描邏輯的設計原理與實現;第5部分,提供給大家一下性能測試的結果供大家參考。第6部分,為大家介紹一下後續我們還可以持續優化的部分。

二、 元數據掃描簡介

所謂元數據掃描,就是通過對數據表增加額外的信息,從而在掃描數據的時候先利用這部分數據對整個掃描數據集進行粗力度的過濾,達到減少掃描數據表的IO總量,提升掃描效率的目標。

元數據掃描可以看為是一種比索引需要更低的維護成本,在某些場景中超越純索引掃描或者純數據表掃描的一種掃描模式。為什麼元數據掃描擁有這些優點呢?
 1,首先元數據收集不需要完全精確,隻需要收集一個集合元組在某一列上的最大,最小值(其中,最大,最小值可以是這一列上現有的值,也可以是不存在的值,當元組對應列值已被刪除或被修改,隻要原來所表示的最大,最小值範圍仍然可以覆蓋這一集合元組的最大,最小值,則我們不需要修改集合範圍信息)。
 2,使用元數據掃描可以達到索引的效果,對於數據的過濾有提升的作用,同時他對於相對返回結果較大的掃描(分析型數據掃描)又能夠優於全表掃描的效果。

元數據掃描還可以對與條件的過濾采取不同的算法,可以進一步提升過濾效率,這塊內容我們會在以後的文章中給大家介紹。

三、元數據掃描存儲設計與實現

為了達到元數據掃描過濾的高過濾能力,我們在元數據掃描的存儲設計上采用了兩層結構的設計,何為兩層存儲結構?
1. 兩層存儲結構就是首先以一萬個元組為第一層,收集最大值,最小值
2. 在這一萬個元組中,每1000個元組最為一個集合,單獨收集這個集合中相應列的最大值,最小值。
這樣設計為什麼能夠提升過濾能力?首先我們對整個10000個元組進行條件應用,如果不滿足,則直接過濾掉這10000個元組。如果滿足條件,我們在將這10000個元組劃分為10個組,再對這10個組進行條件過濾,最大程度的減少實際掃描的數據量。數據存儲示意圖如圖1顯示:
pic

四、元數據掃描掃描邏輯設計於實現

收集完元數據之後,我們就要利用元數據信息在查詢中獲得性能的提升,那麼如何在原來的列存掃描邏輯中應用元數據掃描邏輯呢?
1, 首先我們需要判斷是否使用元數據掃描?
a) 參數rds_enable_cs_enhancement為on;
b) 參數rds_enable_column_meta_scan為on;
c) 元數據已經被收集;
d) 查詢中含有條件過濾(目前隻支持部分條件的元數據掃描,後麵會詳細介紹),如果查詢無過濾條件,也不會應用元數據掃描;
2, 當我們選擇使用元數據掃描之後,我們將會按照如下邏輯進行元數據掃描準備工作。
a) 首先在表查詢條件中選擇可以下推的條件;
i. 目前我們隻支持數據類型與字符類型數據;
ii. 簡單比較操作符條件的下推(<, > , = );
iii. 不支持OR條件的下推;
iv. 字符串類型我們隻支持 = 操作符下推;
b) 對條件進行解析構造新的滿足元數據掃描的新的條件;
我們將原生條件分為以下幾類,分別生成新的過濾條件供元數據掃描使用;其中col表示元組某一個列,colmin, colmax表示該列在某一個元數據集合中的最小值與最大值。
i. col > 1 轉換為 colmax > 1
pic
ii. col < 1 轉換為 colmin <1
pic
iii. col = 1 轉化為 colmin >1 and colmax <
pic
c) 讀取元數據信息並拚裝成元數據tuple;
這裏拚裝好新的元數據tuple之後,我們建立好colmin與colmax的在元數據tuple的位置關係與之前我們構造的過濾條件列的對應關係,然後使用數據庫自帶的條件判斷邏輯進行條件過濾。

	d)	在找到滿足條件的元數據集合之後,定位到數據文件的對應位置;
		直接根據元數據信息過濾後的記錄號,定位到相應的實際數據文件相對應的位置開始掃描。

五、測試結果

我們選擇了一些scan耗時占比較大的查詢來進行測試,我們選出Q3, Q6, Q7, Q11, Q12, Q14, Q15, Q19, Q20,這幾個查詢。進行測試。

  1. 挑選出scan耗費時間相對較長的查詢進行測試;
    在這次測試中,我們還針對第一輪測試性能未能提升的結果,得到了一個推論,原生數據可能分布比較均勻,Meta scan過濾沒有起到作用,因此我們分析了以上選取的查詢,將lineitem表數據按照字段L_SHIPDATE排序,這樣我們的meta信息將會更好的過濾數據。下麵我們利用第二輪測試來驗證我們的分析。
    測試結果如圖:
    pic

我們構築圖標連對比結果:
pic

Q12, Q19 因為過濾條件沒有l_shipdate,其他字段過濾效率同樣取決於這些字段的分布狀態。總結一下,Meta scan要發揮最大作用,最好謂詞上每個block的數據相對有序。並且返回結果集最好較全量數據有較大縮小。

  1. 比對scan部分提升結果;
    接著我們來看看scan部分的性能提升數據如圖:
    pic
    從上圖上來看,scan提升的幅度普遍大於,查詢性能整體提升的幅度,這說明scan的時間占查詢總時間比越大,meta scan可以發揮作用的空間就越大。

六、 總結與後續工作

元數據掃描作為列存掃描方式的優化補充,對於當前OLAP分析型查詢的優化具有比較好的掃描提升效果。後續我們將繼續對元數據掃描在文件定位方麵進行優化。

最後更新:2017-08-21 09:02:50

  上一篇:go  MySQL · 源碼分析 · MySQL replication partial transaction
  下一篇:go  MySQL · 引擎特性 · Group Replication內核解析