SQL Server分区-分区密钥使用什么？

10

我从来没有使用过SQL Server分区，但是目前我面临着设计数据库的问题，而这些数据库可能需要它的支持。该系统用于优惠券。优惠券应定期发行，通常每六周发行一次，尽管也会临时发行（例如特殊活动）。有1500万客户，每次发行活动，每个客户将获得6种不同的优惠券类型，总共提供9000万个优惠券实例。我们需要跟踪优惠券实例的兑换数据并保持6个月，尽管通常优惠券仅有效6周。任何兑换无效优惠券的请求都不会到达数据库，因为直到POS都将对其进行验证。

在六个月的时间内，我们需要在Coupon Instance表中存储3.6亿行，在Redemption表中存储多达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...

另外，我不确定我们需要的数据库服务器规格。16GB和8CPU是否足够？数据库需要能够从优惠券实例表中返回结果，并在不到半秒的时间内键入数字条形码值。验证（选择）和赎回（插入）的预期交易请求预计将达到约每分钟3500个峰值。

SQL Server 2008r2 64位数据库服务器将通过功能强大的主机配置为VM，并可以访问高性能和大容量SAN。

对于那些已经部署了SQL Server解决方案来管理类似卷的人员的建议，我将不胜感激。

问候

抢。

sql-server partitioning

— 罗伯·鲍曼
source

2

您的表仍然很小-不需要分区，我有一个具有数十亿行而不分区的表，可以工作。不过，分区对于快速删除非常有用。

— TomTom公司

1

废话@TomTom，分区在行数中占很小的比例可能是有益的。可以肯定的是，分区方案必须有利于访问模式以实现性能提升，但是以这种大小进行“根本不需要”是完全错误的。

— Mark Storey-Smith，

1

不，这是正确的。需要！=收益。当您在进行不带分区的查询时遇到问题时，需要使用NEED。

— TomTom

1

嘿@TomTom我认为您需要一个小小的休息伙伴，即使实际上没有冒犯性，但它也很强大。我同意Mark StoreySmith的观点，总括地说“不需要”是完全错误的，但是您断言它可能不需要是正确的。我想这是索引的问题。我也知道Mark知道您对需求与收益的理解。让我们都放松一点，放下咖啡因，K？（相信我，有些日子，我的耐心很少，尤其是像今天这样的日子，

— 那时候

14

服务器规范问题应直接针对Serverfault或DBA.SE。

对于分区问题，我认为您不必为此进行分区。

360m行很多，但是也不太麻烦。

请不要在任何情况下尝试分区基于字段的最后一位。我不确定这是否行得通，但它不是SARGable，那将是站不住脚的。

如果只需要根据数字键进行单行查找，则分区可能无济于事。

如果您决定采用分区路径，请记住要有效，所有查询都需要包括分区键，以便引擎知道要检查的分区。否则，它将检查所有这些，您实际上损害了性能。

— JNK
source

2

我同意。SQL Server分区并不适合所有人。

— Nick Chammas

我也同意。有时您只需要更好的索引。

— jcolebrand

我不同意@JNK。从分区消除中受益的基于数字键的单行查找减少了IO。如果访问方式使频繁访问的分区保留在不频繁访问的分区上的缓冲池中，则可以进一步提高性能。而且，我们甚至都没有触及到我最喜欢的功能，即分区为您提供了部分可用性。

— Mark Storey-Smith

记录下来，就您的其他观点，我表示衷心的同意：）

— Mark Storey-Smith

@ MarkStorey-Smith-这将取决于他的钥匙。正如OP中当前定义的那样，该分区不会添加任何值。听起来他也将无法使用带有日期字段或“常规”分区方案的两部分式密钥。

— JNK

5

如果使用持久化的计算列，则可以在多个键上进行分区；正如其他人所说，分区并非在每种情况下都适用。我不确定我是否了解您的情况足以为您提供具体建议，但以下是一些一般准则：

当分区键是SQL语句的一部分时，分区在读取数据时很有用，这使优化程序可以调用分区排除。您需要确保选择的键对大多数查询有用。
好的分区策略的好处之一是可以老化数据。例如，如果您的分区键是基于日期的（即一年中的某天），并且您要删除所有早于某个日期的数据，则可以很容易地将这些分区切换到空表并进行截断。

— 斯图尔特·安斯沃思（Stuart Ainsworth）
source

4

您确实需要更加明确地定义您的需求。您提到在6个月内将有大约3.6亿行。两年后怎么样？您是否仍将仅以当前的增长速度增长。还是有机会经历指数增长。您是否想将数据永久保存在该表中？或者您想定期存档数据。

分区可用于数据归档。请参阅滑动窗口方案。请参阅本白皮书和本白皮书。

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

您还应该考虑分区视图，而不是分区表。分区视图不需要SQL Server Enterprise许可证。分区视图还使您可以对特定的“分区”执行在线索引重建。

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

看看这个来自金佰利特里普大视频分割。

— Dharmendar Kumar'DK'
source

我们只需要将数据保存六个月。每周，我们将执行一次客房清洁工作，以删除六个月前发行的所有优惠券。

— 罗伯·鲍曼

3

因此，基本上，您每周必须删除/删除大约1500万行。桌子有多宽？我建议您按日期列对表进行分区。这样，每周删除将是一个简单的元操作。您只需要将最旧的分区从主分区表中切换到暂存表中。然后放下暂存表。这称为“滑动Windows”方案。查找我发布的第一份白皮书，该如何做。

— Dharmendar Kumar'DK'

-2

除非由于存档旧数据而进行分区，否则这样做是出于错误的原因，因此不应这样做。

— 雷克
source

2

除了存档外，还有很多使用分区的原因。如果使用得当，partition排除对于许多不同类型的查询都非常有用。

— 斯图尔特·安斯沃思

我同意Stuart的观点，这是个坏建议。

— jcolebrand