2009-06-11 57 views
3

我正在使用的數據庫目前超過100個GiB,並承諾在未來一年左右的時間內增長得更多。我試圖設計一個分區方案,這個分區方案可以和我的數據集一起工作,但是迄今爲止失敗了。我的問題是,對這個數據庫的查詢通常會測試這個大表中多個列的值,最終以不可預知的方式重疊的結果集中。SQL Server中表分區的方法

每個人(與我一起工作的數據庫管理員)都警告不要超過一定大小的表,並且我研究並評估了我遇到的解決方案,但他們似乎都依賴於允許邏輯表分區。不幸的是,鑑於我的表格結構,我沒有辦法實現這一點。

下面是我們兩個主要表格的結構,以便對此進行透視。

Table: Case 
Columns: 
Year 
Type 
Status 
UniqueIdentifier 
PrimaryKey 
etc. 

Table: Case_Participant 
Columns: 
Case.PrimaryKey 
LastName 
FirstName 
SSN 
DLN 
OtherUniqueIdentifiers 

請注意,上述任何一列都可以用作查詢參數。

+0

你可能會做的更好,詢問這對serverfault。 – 2009-06-11 21:09:10

+0

同意喬爾。我已經打好了它。 ServerFault的人才是這方面的專家。 – RBarryYoung 2009-06-11 23:21:44

回答

5

而不是猜測,測量。收集使用情況統計(queries run),查看引擎自己的統計信息,如sys.dm_db_index_usage_stats,然後您做出明智的決定:最佳平衡數據大小併爲最常運行的查詢提供最佳關聯性的分區將是一個不錯的選擇。當然你必須妥協。

另外不要忘記,partitioning是每個索引(其中'表'=其中一個索引),而不是每個表,所以問題不是分割什麼,而是哪些索引要分區或不分區以及哪些分區功能使用。這兩個表上的聚簇索引顯然是最可能的候選者(分割非聚簇索引並不劃分聚簇索引沒有多大意義),除非您正在考慮重新設計聚簇鍵,否則問題實際上是爲聚簇索引選擇什麼分區功能。

如果我冒險猜測我會說,對於隨着時間的推移積累的任何數據(如'年''案件')最自然的分區是sliding window

0

如果您沒有其他選擇,您可以按關鍵模塊分區分區表的數量。 可以說你想分區到10個表。 您將定義表:
Case00
Case01
...
Case09

並通過唯一標識符或PrimaryKey的模塊10分區上的數據並將其放置在相應的表中的每個記錄(根據您的獨特的唯一標識符你可能需要開始手動分配ID)。

執行查詢時,您需要在所有表上運行相同的查詢,並使用UNION將結果集合併到單個查詢結果中。

它不如基於對應於預期查詢的邏輯分隔對錶進行分區,但最好達到表的大小限制。

0

另一個可能的事情(分區之前)是你的模型。

你是否在規範化數據庫?是否有進一步的步驟可以通過正常化/解除/部分正常化的不同選擇來提高性能?是否有選擇將數據轉換爲適用於報告/查詢的Kimball樣式的維星模型?

如果你不打算放棄(滑動窗口,如提及)表的分區或區別對待不同的分區(你說的任何列可以在查詢中使用),我不知道你想什麼擺脫那些您不會從索引策略中走出來的分區。

我不知道對行的任何表格的限制。 AFAIK,行數僅受可用存儲的限制。