每個分區/文件組多個文件？
我正在為高性能大型 SQL Server 2016 數據庫設計基於分區的解決方案。一些數據每天將包含數億條記錄。白天，我們還將執行報告查詢和查找多天和多周趨勢的查詢。
我目前的解決方案將在每日分區中使用 70 天，每個分區使用一個專用文件組。數據超過 70 天標記後，它將進入每週分區 42 週，每個分區也使用專用文件組，然後是 12 個月，然後是 6 年，所有這些都以相同的方式設置。
我們需要真正的高性能和大規模擴展能力（PB+ 範圍）。為了最大限度地減少返工，我正在考慮為每日和每周文件組/分區的每個文件組/分區使用多個文件。確切地說，每天 4 次，每週 2 次。
通過這種方式，我們可以潛在地增加每個分區的讀取/載入吞吐量，以及增加分區的最大容量（不要問為什麼，但我們擔心在某些日子實際上需要這種容量水平）。
有沒有人這樣做過，你的結果是什麼？除了管理成本之外，還有什麼理由不這樣做嗎？
所有每週、每月和每年的分區都將位於同一伺服器上的同一數據庫中（應用程序設計問題，但如果動機適當，多數據庫可能是一種選擇。多個伺服器或實例是不可取的）。
目前正在討論和評估分區中斷。我根據收到的有關查詢模式的資訊選擇了上述值。當然可以有不同的天數，但我有點喜歡 10 週的每日分區。
我們確實有一個非常高端的數據中心，實際上是 2。我們正在討論購買特定於該平台和其他平台的融合解決方案。我個人希望看到專用的 AFA（全快閃記憶體陣列），但在我接觸到這些之前還有一些橋樑需要跨越。
我知道Data Warehouse Fast Track解決方案，但它們對我們不起作用。一方面，我們將主要進行 OLTP，因此基準數據不能代表我們將獲得的結果。其次，他們沒有足夠的規模擴大（目前）。來自參考架構的一些元素當然會被使用，但“交鑰匙”SKU 將不是一個選項。我是前 MS PFE，所以這些資源是我首先看的。
您不能處理分區 <=> 文件關係。分區只影響文件組。但是，將文件組拆分為不同的文件將有助於提高性能。我一直使用的數字是將每個文件組的分區數設置為 MAXDOP 值。我看到了 SQL Server 如何將 tempdb 拆分為不同的文件，我確實注意到複製此行為的一些改進。
關於分區，您應該做的是在文件組上拆分它們，以便不再更新的那些永遠不會移動。我們的 DWH 中通常有一個熱文件組和一個冷文件組。冷的是只讀的，我們只在將數據從熱移動到冷的那一天更改該狀態。您可以這樣做，而不必為每個分區創建一個文件組。這只會讓管理變得更加困難。
從評論轉換：
我嘗試了類似的方法，使我達到了 1000 個分區的限制，但我發現 IO 無法使用這麼多打開的文件句柄。這是在帶有直接附加儲存的 2008r2 SSEE 上完成的。我建議您仔細查看您的 io 子系統的規格，並與供應商合作進行設置和調整。您可能會發現您需要多個 io 通道來滿足您正在尋找的規模。–亞倫2018 年5 月 8 日 14:19