在SQL Server 2008中使用索引表的分區切換進行並行批量加載

Question

這是繼我的previous question後確定分區切換作爲快速獲取數據到大量索引的事實類型表中的最佳方式，該表需要保持對讀者可用。

雖然它似乎是最好的方法，但它還不足以真正滿足允許多個（< 5）用戶同時批量插入，並將新數據編入索引並出現在索引視圖（不一定是真正的索引視圖，只是依賴索引的選擇）。

分區的想法是，以分區爲根的每個分區和索引子樹可以並行鎖定爲只讀，複製到工作表中，插入/更新新數據並重建索引，然後切換回來進入主表，以便讀者不受影響。

問題是單個工作表。每個並行批量插入都需要自己的副本，與主表具有相同的約束以允許切換。

到目前爲止，我已經打了幾個牆試圖繞過這個瓶頸：

1. 我嘗試使用同一個分區 功能分區的工作表。這不起作用，因爲您無法禁用基於分區的索引 以插入一個，而在另一個基礎上重建索引 。
2. 創建臨時表作爲工作表。此 不起作用，因爲儘管您可以使用相同的索引名稱，但 無法輕鬆地動態創建約束，並且無論如何也不能切換 。
3. 有一組固定的命名工作表？我如何選擇一個並在別名下使用它，所以我只有一個存儲過程？
4. 動態SQL？我非常努力地避免走這條路。它很複雜。

很大的挑戰，但任何人有任何想法之前，我接受瓶頸？ Sql 2012會有幫助嗎？正確的數據倉庫如何處理這個問題？

Answer 1

正確的數據倉庫如何處理這個問題？妥協並設定EDW的現實目標。數據倉庫不能成爲所有人的一切。確保你正在實施的是業務的最佳解決方案（不僅僅是技術人員/分析師）。如果你找不到經驗豐富的同行和專家的解決方案，你的目標是否現實？

將成本與您跳過的所有環節相關聯。數據是否真的需要最新？如果我告訴你我們需要花費20萬美元的存儲空間，因爲我們一直在複製分區和重建索引，並且當前的解決方案無法跟上IOPS需求？有時候，他們會發現它不是免費的。雖然你不需要說「不」，但你確實需要現實並預先考慮相關成本。另外，你的存儲管理員會感謝你。

至於2012年，有一個新的列存儲索引可以減少或替換您用於涵蓋所有分析師搜索請求的所有當前非集羣。它是高度壓縮的，涵蓋了各種各樣的搜索參數，並且使用了新的批處理執行模式。它在低選擇性查詢（如經常在事實表上執行的查詢）方面表現最佳。一個問題是你無法直接進行更新。您必須將分區切換到登臺表，將列存儲放在登臺表上，更新登臺表，將列存儲返回，然後將分區切換回事實表。這聽起來很像，但可能會比維護所有這些非集羣的速度快得多並且需要更少的IO。

我的問題一直是「如果它不斷變化，它真的是一個事實表嗎？」。這不是OLTP嗎？嘗試抵消交易或至少將所有更新推送到計劃的非高峯時間。更新事實表正在成爲過去。所有的big boys正朝着面向數據倉庫的「更新皺眉」列嚮導架構邁進。 PowerPivot和Analysis Services表格模型構建在列存儲技術上。

最後，複習Kimballs的DW Toolkit書籍。他有幾個最佳實踐，涵蓋邊緣情況。我從他們身上學到的是數據倉庫開發不僅僅是類固醇的數據庫開發。它還涉及政治，並將重點放在最適合業務的資源上。