2009-06-11 30 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,行数仅受可用存储的限制。