如何為 VLDB OLTP 解決方案設計分區策略（SQL Server 2016，>100TB init.size）
我目前正在設計一個基於 MSSQL 2016 的平台來處理將增長到 PetaByte 級別以上的數據集（基於 OLTP）。它將用於需要使用各種方法和工具（包括 R）發現趨勢的特定類型的分析。將有各種來源以“實時”的方式為數據庫提供數據，以及將批量攝取的數據批次。由於交易量大，預計並髮使用者數量（>250）以及使用者使用數據的方式（稍後更多），我們需要該解決方案具有高性能和可擴展性。很明顯，數據需要在幾個級別上進行分區以支持數據消費者。
使用者將在每日、每週、每月和多年範圍內執行趨勢分析類型的工作負載。大多數數據將提供日期欄位，但客戶名稱、帳號和交易類型也在進行趨勢分析的範圍內。
我對大家的問題如下，您設計合適的分區解決方案的策略是什麼？你會問什麼問題，你會在答案中尋找什麼？你將如何處理索引等的維護……你會在設計中考慮什麼？
Oowww 並將所有內容放入數據湖（閱讀：沼澤）或轉向不同的平台不是一種選擇。另外，我無權討論項目的細節或涉及的數據，所以請不要問。只要知道這是高度機密的財務和個人數據，我們將按照對我們施加的合法要求進行取證分析（使用 R、PowerBI 和/或其他 BI 工具）。除此之外，我不會分享任何其他細節，對不起。
我建議您閱讀這篇文章，其中介紹了 OLTP 數據庫的一些重要先決條件和建議。
http://nerdtechies.com/2016/12/05/improve-write-performance-sql-server-database/
對於載入過程使用
BULK INSERT和普通插入使用者WITH(ROWLOCK)。https://technet.microsoft.com/en-us/library/dd425070.aspx
分區
你需要知道什麼。
- 什麼是線上數據的保留？
- 什麼是增長/天？
- 在什麼基礎上報告使用者拉最大（每天/每週/每月或每年）？
- 歸檔政策。
–我有 2 TB 表的經驗，每天增長 50GB，一個月的生產數據在 WH 上。所以提出相應的建議。
如果 70-80 % 使用每日基礎分析報告。我建議進行每日分區，因為會有大量數據。它將執行得更快，但要生成每週、每月和每年的報告，您將有很長的查詢。
如果每日、每周和每月分析之間的比率為 50-50，則進行每月分區。在這種情況下，每日和每週報告的執行速度將比每日分區慢，因為將有很多記錄要從月份中過濾。但是你會有非常簡單的查詢。
通過考慮保留線上數據進行分區使歸檔策略更容易。
指數
由於表將被分區，您應該在表上創建分區索引。要創建分區索引，您需要在索引中包含分區基列。除非您不在分區表上創建分區索引，否則您不會獲得性能優勢。
在單獨的文件組上創建索引將為報告帶來良好的性能。因此，在單獨的文件組上為與為表創建的索引相同的索引創建單獨的分區方案、函式。
最好在 Index_Partition_Scheme 上使用（Base_Partition_Column、客戶名稱、帳號、交易類型、財務列）上的列儲存索引。
創建索引
FILLFACTOR=80創建分區索引使索引維護更容易。您可以對索引的特定分區執行維護任務，而不是重建或重組完整的索引，從而最大限度地減少大表的維護時間。
為此，您可以跟踪分區的索引碎片和行數。它將幫助您找出應該重建哪個分區的索引。
維護計劃取決於數據大小、執行維護活動的休息時間以及 SQL Server 完成任務所需的時間。最好先使用相同數量的數據在測試環境中測試您的維護計劃，然後如果它在您擁有的下班時間完成，則將其用於生產。
謝謝