在今天的文章裡，我想專門詳細談下sql server 2014引入的可更新聚集列儲存索引（updateable clustered columnstore index）。在我們進入細節討論前，我想先給你簡單介紹下它在sql server 2012裡出現時的情況，還有它們的侷限性。
sql server 2012裡引入的列儲存索引是最熱的新特性之一（除alwayson外）。如果使用得當的話，對於資料倉儲的工作負荷會帶來巨大的效能提公升。遺憾的是，它們有2個大的侷限性：
對一些使用者來說，這2個侷限性是非常糟糕的。假設你有傳統行儲存資料的300gb表。使用列儲存索引是可以將資料壓縮到30gb大小。但sql server 2012只允許非聚集列儲存索引，這樣的話你需要2次儲存你的資料：乙個在傳統行儲存格式裡，另乙個在新的列儲存格式裡。那是儲存的巨大浪費，因為你的查詢只用到你的非聚集列儲存索引。
一旦你建立了你的非聚集列儲存索引，你就不允許修改表資料了——你的表就唯讀了！當然，對這個問題有一些解決方法，例如分割槽交換，但你還是需要你自己來實現……
現在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裡標記為刪除的記錄。
因為delta store和delete bitmap讓你的列儲存索引看起來是可更新的，但事實上是不可變的。還有個叫做tuple mover的後台處理，它定期執行最後把你的修改非同步到列儲存索引。
在sql server 2014裡，另外你終於可以定義聚集列儲存索引。這就是說你可以不需要將你的資料儲存在傳統行格式裡。直接建立你的表，在上面建立聚集列儲存索引。用這個方法可以在儲存裡節約大量空間，因為現在一切都是壓縮的。當你進一步和關聯式資料庫概念打交道時，聚集（clustered）意味著已排序（sorted）。但是使用聚集列儲存索引這句話是不對的：當你建立了聚集列儲存索引時，在你資料裡是沒有排序的！請意識到這個小區別！
可更新的聚集列儲存索引是sql server 2014乙個神奇的幻想。不要理解錯了：我是的確很喜歡用這個新特性引入的發展潛能，但你如果想要充分用好它，就要理解這個特性內部是如何實現的。
可更新聚集列儲存索引幻想
在今天的文章裡，我想專門詳細談下sql server 2014引入的可更新聚集列儲存索引 updateable clustered columnstore index 在我們進入細節討論前，我想先給你簡單介紹下它在sql server 2012裡出現時的情況，還有它們的侷限性。sql server ...
可更新聚集列儲存索引幻想
在今天的文章裡，我想專門詳細談下sql server 2014引入的可更新聚集列儲存索引 updateable clustered columnstore index 在我們進入細節討論前，我想先給你簡單介紹下它在sql server 2012裡出現時的情況，還有它們的侷限性。sql server ...
可更新聚集列儲存索引幻想
在今天的文章裡，我想專門詳細談下sql server 2014引入的可更新聚集列儲存索引 updateable clustered columnstore index 在我們進入細節討論前，我想先給你簡單介紹下它在sql server 2012裡出現時的情況，還有它們的侷限性。sql server ...