可更新聚集資料行存放區索引幻想

標籤：

在今天的文章裡，我想專門詳細談下SQL Server 2014引入的可更新聚集資料行存放區索引（Updateable Clustered ColumnStore Index）。在我們進入細節討論前，我想先給你簡單介紹下它在SQL Server 2012裡出現時的情況，還有它們的局限性。

SQL Server 2012裡的資料行存放區索引

SQL Server 2012裡引入的資料行存放區索引是最熱的新特性之一（除AlwaysOn外）。如果使用得當的話，對於資料倉儲的工作負載會帶來巨大的效能提升。遺憾的是，它們有2個大的局限性：

• 只對非聚集資料行存放區索引支援
• 一旦在表上建立了資料行存放區索引，這個表就唯讀了，對其資料不允許修改

對一些使用者來說，這2個局限性是非常糟糕的。假設你有傳統行儲存資料的300GB表。使用資料行存放區索引是可以將資料壓縮到30GB大小。但SQL Server 2012隻允許非聚集資料行存放區索引，這樣的話你需要2次儲存你的資料：一個在傳統行儲存格式裡，另一個在新的列儲存格式裡。那是儲存的巨大浪費，因為你的查詢只用到你的非聚集資料行存放區索引。

一旦你建立了你的非聚集資料行存放區索引，你就不允許修改表資料了——你的表就唯讀了！當然，對這個問題有一些解決方案，例如分區交換，但你還是需要你自己來實現……

SQL Server 2014裡的資料行存放區索引

現在SQL Server 2014做出了一些改變，因為微軟已經解決了上述問題——用了一些魔法和幻想：SQL Server 2014提供你可更新的聚集資料行存放區索引（Updateable Clustered ColumnStore Index）！我們一起來具體看下在SQL Server裡這個魔法和錯誤內部發生了什麼。

第1個最重要的事實是：直接更新資料行存放區索引是不可能的！在你的INSERT，UPDATE和DELETE事務期間進行完全的解壓和壓縮太費時間了。因此SQL Server 2014從一些魔法裡獲得協助：Delta Stores和Delete Bitmap。我們詳細看下這2個概念。

每次當你只執行INSERT語句，新記錄不直接插入資料行存放區索引——記錄會插入Delta Store。Delta Store本身就是典型的B樹，有B樹的所有缺點和優點。接下來當你從資料行存放區索引讀取時，SQL Server同時從壓縮的資料行存放區索引和Delta Store裡返回你資料。

當你執行DELETE語句時，在壓縮的資料行存放區索引裡還是什麼也沒發生。唯一發生的是通過Delete Bitmap記錄被邏輯刪除。在資料行存放區索引裡的每條記錄在Delte Bitmap裡都有對應位。當你再次讀取資料行存放區索引時，SQL Server會忽略在Delete Bitmap裡標記為刪除的記錄。

執行UPDATE語句意味著在Delta Store裡插入新的記錄，在Delete Bitmap裡把原版本記錄標記為刪除。很簡單，是不是？顯示了詳細展示這個概念（來源：http://research.microsoft.com/pubs/193599/Apollo3%20-%20Sigmod%202013%20-%20final.pdf）：

 

因為Delta Store和Delete Bitmap讓你的資料行存放區索引看起來是可更新的，但事實上是不可變的。還有個叫做Tuple Mover的幕後處理，它定期運行最後把你的修改非同步到資料行存放區索引。

在SQL Server 2014裡，另外你終於可以定義聚集資料行存放區索引。這就是說你可以不需要將你的資料存放區在傳統行格式裡。直接建立你的表，在上面建立聚集資料行存放區索引。用這個方法可以在儲存裡節約大量空間，因為現在一切都是壓縮的。當你進一步和關聯式資料庫概念打交道時，聚集（Clustered）意味著已排序（Sorted）。但是使用聚集資料行存放區索引這句話是不對的：當你建立了聚集資料行存放區索引時，在你資料裡是沒有排序的！請意識到這個小區別！

小結

可更新的聚集資料行存放區索引是SQL Server 2014一個神奇的幻想。不要理解錯了：我是的確很喜歡用這個新特性引入的發展潛能，但你如果想要充分用好它，就要理解這個特性內部是如何?的。

感謝關注！

可更新聚集資料行存放區索引幻想