嘉賓簡介
馮媛：
ibm資深軟體工程師
2005年至今一直從事db2相關工具開發，包括ibm data studio admin console, infosphere optim performance manager，data studio等
專注于資料管理，監控和性能優化。目前帶領團隊開發data server manager 管理和配置部件，曾在北京交通大學，深圳大學，哈爾濱大學等多所高校及各種高校老師的教育訓練課程中介紹db2知識
參與《db2性能管理與實戰》寫作并在developerworks發表多篇文章
演講實錄
ibm在db2 10.5版本中推出了blu accelerator，ibm對于列存儲的支援晚于teradata，sybase等資料庫廠商。blu acceleration作為ibm全球數百位頂尖研究人員智慧結晶，blu具有記憶體列式動态處理、可操作的壓縮資料、并行向量處理、以及資料忽略等行業獨有的特性。今天我這裡和大家一起分享一下db2做的這些優化。
列存儲最大的特點是資料是按列存儲的，比較适合olap應用中擷取一部分列的場景。 在行存儲的時候，資料頁裡存有整行的資料，當我們需要查詢局部列的時候，必然的我們會把對應的行所在的頁都加載進來，想象一下資料庫在讀的時候我們都知道bufferpool會順序預取後面的幾頁，對于一個有很多行的表，取局部列資料的時候實際上會帶來非常多的額外io開銷。舉個比較極端的場景100列的表中取1列的情況，如果沒有索引在這一列上，io中隻有1%的資料才是我們需要的。
那麼既然blu的資料都是以單列存儲的，又怎麼能保證對于資料多列的讀取的呢。 db2将一組列組成的單元給了一個唯一的序列号叫tsn, 由tsnlist組成了一個邏輯的行。每個頁有一個tsn map。是以行表裡的rid()這些方法在清單裡是不支援的。對于取局部列資料的應用，比如之前100列中讀取１列，這裡隻要把列所在的資料頁加載過來就行，不需要加在其他無關列的資料。
db2在blu的壓縮中不僅有列級别的壓縮，而且在頁級别的字典會再進一步壓縮。
當資料被load的時候，當你使用loaＤ replace, load replace resetdictionary, load replace resetdictionaryonly或者load insert的時候，列級别的壓縮字典就會被建立。當新的資料被加入的時候，資料會用表級别的壓縮字典進行壓縮。blu還會用頁級别的壓縮字典來壓縮新的時候。這種兩層的資料壓縮字典，提高了資料的壓縮效率。頁級别的壓縮字典就存在于每個資料頁中。每個資料頁包含了該頁的起始tsn以及總共有多少個tsn。
blu采用了壓縮包括了近似的霍夫曼編碼、字首編碼和內插補點壓縮。對于出現頻率高的值壓縮後會用比較少的bit來表示，而且在一個區塊内是保序的。結合頁級别的壓縮，有可能根據列級别的壓縮成為3 bits的，在目前頁裡面出現頻率比較高有可能就會壓縮成2 bits. 這種壓縮算法大大提高了壓縮效率，減少了存儲和i/o開銷。資料頁裡儲存了目前頁的壓縮字典。
在進行查詢的時候，查詢條件的值也是通過壓縮算法後在每個單元中比較的，而不是把資料解壓後進行比較，隻有滿足條件的值才會被過濾出來，在中間運算過程中盡可能的用壓縮值。
db2自動維護了一個page map index和一個synopsis表，page map index存放了列組合的起始tsn以及對應的頁位址。synopsis表含的是每個非字母列的最大，最小值組合。
在資料load和insert的時候，db2會自動在synopsis表中生成記錄，synopsis表裡包含了mintsn、maxtsn以及列的最大和最小值。
synopsis表能幫助在查詢的時候根據查詢條件跳過一些tsn。在load的時候每1024tsn就會插入一條記錄在概要表裡，每一次插入事務也會單獨生成一條記錄。db2 blu比較适合大批量的資料插入，比如load、ingest等，不适合單個insert操作，性能相對會慢一些。
我們在剛才看概要表的時候，已經講到概要表裡的最大，最小值能幫助在查詢的時候跳過不需要的資料。
比如列之間的謂詞條件的查詢：
x1 > x2 ==> maxx1 > minx2
x1 >= x2 ==> maxx1 >= minx2
再比如單列in
col in (val1, val2, ...) ==> (mincol <= val1 and maxcol >= val1)
or (mincol <= val2 and maxcol >= val2) or ...
db2 blu 會自動動态更新資料頁裡面的值範圍，這樣在查詢的時候不滿足條件的值會自動被忽略。
blu使用了單指令多資料流（simd）技術
單指令多資料流（simd)是指能夠複制多個操作數，并把它們打包在大型寄存器的一組指令集。
以加法指令為例，單指令單資料（sisd）的cpu對加法指令譯碼後，執行部件先通路記憶體，取得第一個操作數；之後再一次通路記憶體，取得第二個操作數；随後才能進行求和運算。而在simd型的cpu中，指令譯碼後幾個執行部件同時通路記憶體，一次性獲得所有操作數進行運算。
這裡的例子，我們做一個= 運算，可以同時把4個值同時給cpu去處理，這對于謂詞處理，join, group以及數學運算等都能大大提高效率
db2能把128 bits 給simd，因為資料的高度壓縮，并且是頻率越高壓縮率越高，這樣能大大提高cpu的運算效率。
自動分布到多個cpu core
blu預設要打開intra_parallel， blu結合workload manager，盡可能得使用cpu的core，我們都知道l1的cache效率是最高的。
在左圖中，沒有用blu技術的時候，amount_paid裡的資料一部分在core1，一部分在core2中，是以core1在處理的時候還要從core2中擷取資料。core2工作在num_claims列上，但是它也要從core1上擷取資料。 是以就存在core之間争取資料的“乒乓”操作。
在采用blu以後，列存儲以後，amount_paid的處理都在core1上，num_claims列的處理都在core2上，是以兩個核之間不用交換資料。而且能更好的保證core裡面的cache被更好的利用。
機率緩存取代傳統lru
如何有效地緩存資料一直是一個非常困難的問題，因為資料遠遠大于緩存的大小。采用什麼樣的算法是很關鍵的問題，傳統的采用保留最近使用(mru)，換出最久未使用資料(lru)并不适合分析性資料。 大部分的分析資料，有一部分資料會比其他部分的資料熱，用傳統的行存儲的方式，一是由于需要的對于所需要資料的記憶體，二是當記憶體不夠時，資料庫cleaner采用lru釋放出記憶體的資料很可能是下一個scan的時候要用的資料，會大大增加io的開銷。
db2 blu一方面由于采用列存儲和在運算過程中儲存壓縮，大量減少了所需要的記憶體，是以實際70,80%所需要的資料可以被記憶體容納着，另一方面blu本身的資料就是基于使用頻率壓縮的，是以db2會盡可能把使用機率高的資料緩存在記憶體中，盡可能的提高緩存的使用效率。
對于oltp系統，db2對于行存儲繼續使用lru,對于列存儲，db2會自動切換的機率緩存。對于使用者來說這些都是透明的，不需要去管理。
使用blu以後，因為使用列存儲，是以使用者不需要再建indexes，也不需要mdc。
此外很多操作db2預設都會做，是以不需要使用者手動去run reorg，runstats，不需要統計資訊表，也不需要optimizer hints。大大簡化了資料庫管理工作，使用者隻需要把資料用load倒入到blu db中，用db2set db2_workload=analytics , 就會打開很多自動處理，比如自動的wlm,自動的space回收，自動的資料頁分析，記憶體優化等等。
此外db2還提供了shadow table，使用cdc工具，把oltp中的一個行表定期複制到一個對應的分析用的清單中。
最後，雖然db2在列存儲上起步比較晚，但是它采取的一些方法都是比較先進的方式，blu适用大部分olap應用，根據統計大部分情況下，db2 blu能提高10倍作喲的存儲使用效率相對于沒有壓縮的行表來說。對于一些workload能提高6-124倍的效率。
q & a
q1：db2 dpf blu 什麼時候ga？
a1：很快了，在blu mix上已經支援mpp了，可以去适用一下bluemix上的dashdb。
q2：blu cpu core 技術有硬體要求嗎？
a2：現在power和x86（intel amd）都沒問題。
q3：blu對sort group by 這裡的聚集計算，性能怎麼樣？
a3：blu在對query支援的時候，都先分解為單表的謂詞條件，單表都是壓縮處理的。壓縮不但是按頻率編碼，而且編碼是排序的。blu确實是會盡可能的使用記憶體，壓縮的時候采用頻率，區塊内保序的方式。是以很多無效的資料會被忽略，也大大提高了排序和比較運算的開銷。
q4：blu在目前行業領域應用怎麼樣？用過太耗記憶體資源，而且是單機，并發并不是很理想。
a4：要看和誰比，比oracle12c的in memory option要好多了。
q5：是不是對于“男女”這種字段列壓縮會很好，要是像uuid這種字段壓縮效果怎麼樣？
a5：blu适合olap應用，也适用oltap。用shadow table 同時保有行表和清單，随機數肯定沒有出現頻率高的壓縮效率高。
q6：blu列式存儲的表，可以和傳統行式存儲的表，在資料庫内共存嗎？
a6：可以。
q7：字元集是不是隻能utf8的才可以用blu？
a7：blu目前隻支援utf-8，collate為16-bit identity的database。
q8：現在離線計算大家都在做，老師們你們認為blu目前最大的優勢是什麼，對于hadoop、greenplum、td，而言将來的dpf blu最大的亮點是什麼？
a8：又快又省空間。blu在整個運算過程中盡可能得不解壓運算，比很多資料庫的實作省記憶體和提高了運算效率，謂詞也是同樣壓縮算法直接和壓縮後的值計算，盡量在單表條件過濾後，以最少結果集多表間join,但在join的時候會出現需要解壓運算，也會有溢出寫磁盤的情況。一般壓縮這個事情是你壓縮了,你回頭還得解壓,用時間換空間。是以一般是小了，但是會慢。但是blu的處理不是解壓column，而是去壓縮謂詞之後你需要比較的值，隻需要比壓縮之後的結果就行了。還有一點..就是blu的壓縮不但能按頻率,還能壓縮之後保持順序，是以對于>,<,between..and..這樣的謂詞也能做，在join不得不解壓的一些場景中，db2盡量單表中保持壓縮的情況下運算完成後，将滿足條件的最小集合做表間join,這樣還是比很多資料庫的實作節省了解壓帶來的損耗。馬遠提到的壓縮保序在謂詞運算中在保持資料壓縮情況時運算很關鍵。
q9：blu推薦的配置是什麼？
a9：blu推薦的核數和記憶體: 16 cores for every 3tb raw (uncompressed) data, 16 gb of main memory per core。
q10：版本優化器做了加強了嗎？針對于blu設計了特殊的成本計算規則吧？
a10：會單獨走ctq的執行計劃。
q11：那執行器有更改嗎？
a11：data skipping是執行器做的，在比較的時候根據是否落到某些區域，直接跳過一些資料區塊，還有db2記錄了概要表，概要表也會記錄一些列的最大，最小值，db2基本上在你插入資料的時候就時時更新統計了。
q12：db2 blu 概要表與db2概要表是不同概念嗎？
a12：不一樣，db2 blu 概要表是指synopsis table。
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2015-12-17</b>