Server分区-用于分区键的是什么？

Question

我从未处理过Server分区，但我目前面临的问题是设计一个可能需要卷的数据库。这个系统是用来购买优惠券的。优惠券将定期发行，通常每六周发行一次，不过也会有特别发行(如特别活动的优惠券)。有1500万客户，每一次发行活动，每个客户将收到6种不同的优惠券类型，总共9000万的优惠券实例。我们需要跟踪优惠券实例赎回数据，并维持6个月，尽管通常一张优惠券只有效六个星期。任何无效优惠券的赎回请求将不会到达数据库，因为它将由POS验证直到。

在六个月的时间里，我们需要在优惠券实例表中存储3.6亿行，在救赎表中存储多达7200万行(假设最高20%的赎回率)。我觉得这些数字对于单个分区来说太大了？

我的问题是-使用什么作为分区密钥？一个明显的候选将是通过发行事件，给予大约6个分区。但是，我认为，即使这样，也会给出一个太大的分区大小，从而无法实现最佳性能？是否可以用两个键(如发行事件+客户id的最后一位数)进行分区？所以逻辑是：

If issuance event = 1 and last digit of customer id < 5 then
    Store in partition 1
Else if issuance event = 1 and last digit of customer id >4 then
    Store in partition 2
Else if issuance event =2 and last digit of customer id <5 then
    Store in partition 3
Else if issuance event =2 and last digit of customer id >4 then
    Store in partition 4
Etc...

另外，我不确定我们需要的数据库服务器的规范。16 be和8 and就足够了吗？db需要能够从优惠券实例表中返回一个结果，在不到半秒钟内输入一个数字条形码值。预期的验证(select)和赎回(insert)事务请求将达到峰值，大约为每分钟3,500。

SQL Server 2008r2 64位db服务器将作为VM从功能非常强大的主机上提供，可以访问高性能和大容量的SAN。

我非常感谢那些部署了SQL Server解决方案来管理类似卷的人的任何建议。

问候

罗伯。

Answer 1

服务器规范问题应该指向服务器故障或DBA.SE。

对于分区问题，我认为您不一定需要为此进行分区。

360米行是很多，但也不是太笨重。

在任何情况下都不要尝试根据字段的最后一个数字进行分区。我不确定这是否可行，但SARGable是不成立的。

如果您只需要基于数字键执行单个行查找，分区可能不会有帮助。

如果您确实决定采用分区路径，请记住要有效，所有查询都需要包含分区键(S)，以便引擎知道要检查哪个分区。否则，它将检查他们的所有，你实际上损害了性能。

Answer 2

如果使用持久化计算列，则可以对多个键进行分区；但是，正如其他人所说，分区并不适用于每种情况。我不确定我是否理解您的场景是否足以给您提供具体的建议，但以下是一些一般性指南：

• 当分区键是SQL语句的一部分时，分区在读取数据时非常有用，因为SQL语句允许优化器调用parition排除控制。您需要确保所选择的键对于大多数查询都是有用的。
• 好的分区策略的一个好处是用于老化数据；例如，如果分区键基于日期(即一年中的某一天)，并且希望删除所有比某个日期更老的数据，那么很容易将这些分区切换到一个空表并截断。

Answer 3

您确实需要更清楚地定义您的需求。您提到，您将在6个月内拥有大约3.6亿行。两年后怎么样？你还会继续以目前的增长速度增长吗？或者你是否有可能经历指数增长。您希望永远保存此表中的数据，还是希望定期存档数据。

分区可用于数据归档。参见滑动窗口场景。看看这个白纸和这一个。

分区也可用于管理索引碎片。可以重新构建/重新组织特定的分区。

您还应该考虑分区视图，而不是分区表。分区视图不需要Server企业许可证。分区视图还使您能够在特定的“分区”上执行联机索引重新构建。

在进行灾难恢复规划时，也可以考虑分区。它可以用于部分数据库恢复。例如:您可以将旧分区放在与主/当前分区不同的文件组中。然后在恢复时，恢复主文件组，然后恢复当前分区所在的文件组，最后恢复旧分区所在的文件组。这可以减少您的应用程序必须关闭的时间。

看看这个金伯利·特里普关于分区的精彩视频。