在前篇簡單提到新世代的Analysis Server架構,因為硬體技術的突破,而重新實作了OLAP架構。本篇會著重介紹新版的搜尋引擎 - VertiPaq,這種搜尋引擎的出現是因為記憶體容量的增加而發展出來的。一句話簡單形容VertiPaq這項技術:一種提高搜尋速度、壓縮資料的演算法。DAX語法也是基於VertiPaq演算法而發展出來的類似Excel函數的語法。
VertiPaq儲存概念可以想像在記憶體中(in-memory)有個資料庫(DataBase)。一般的OLTP資料庫是Row-based DB,每一個資料以「Row」的方式完整儲存每一個欄位。而VertiPaq採用的是Columnar DB,將資料儲存角度變成「Column」來存。
(這篇文章有兩種資料庫的簡單說明:請點我)
資料壓縮
以下簡單介紹VertiPaq演算法如何將匯入的資料轉換成Columnar Table存起來:
1. Value Encoding
專門處理Integer類型的資料。VertiPaq演算法會判斷某個Integer Column的最大最小值差距,如果差距過大,那就不會用這個演算法;如果差距還OK,就會將每個值減掉最小值,然後存起來,並另外紀錄最小值是多少。經過Value Encoding之後,可以壓縮資料,降低儲存容量。如下圖:
2. Dictionary Encoding
除了處理Integer類型之外,也有處理String的演算法。概念是將String Column改以Integer來存,並建立一個Mapping Table。目的也是縮小資料儲存容量。如下圖:
3. Run Length Encoding (RLE)
如果欄位存的值是有順序性的,那VertiPaq就會結合Dictionary Encoding或Value Encoding,並採取RLE來儲存資料。把各別欄位值的資料做Count,這樣就不用花很多空間來儲存每一筆資料。在復原資料的時候,因為有順序性,所以可以知道該筆資料是在第幾個位置開始出現,大大減少空間的消耗。
資料搜尋
以下簡單介紹VertiPaq演算法如何提升搜尋速度:
1. Columar Table
如果想搜尋Location在Taipei的員工有幾位,我們來看看兩種不同的Table會怎麼處理:
● Row-based Table
將每一條Row從ID欄位開始掃到Location欄位,如果Location = 'Taipei',則Count++。
● Columnar Table
直接搜尋Location欄位(Column Elimination),如果Location = 'Taipei',則Count++。
2. Segmentation
有點類似做DB的Index。如果想要搜尋工號>=3的員工有幾位,VertiPaq就會找出ID = 3的Segmentation在哪,並在ID欄位做查詢。VertiPaq的運作如下圖:
花了四篇的篇幅來介紹微軟的Analysis Service的概念,本篇是最後一篇,終於介紹完了。