为了处理大型数据集而为SQL Server 2008 R2设置分片的模式？

我想在SQL Server 2008 R2中处理大型数据集（> 10亿行）。我听说，如果您设置“分片”或“水平分区”，则可以更快地处理大型数据集，因为它将表分成多个文件。

您以前使用过分片或水平分区吗？如果是这样，您是否可以建议根据您的经验，与单个大型表相比能获得更好结果的模式？

sql-server sql-server-2008

— 康坦戈
source

首先，请注意，使用普通商用服务器硬件上的分区体系结构可以有效地处理10亿行。对于此数据量，不需要Exotic共享的体系结构，但是，您可能会从表分区中获得显着的好处。

分片与水平分区有所不同，它意味着“无共享”架构，大多数版本的SQL Server ¹均不支持这种架构。

SQL Server可以支持水平分区，并且共享磁盘体系结构足以容纳约1个billon行。

在SQL Server中，您可以创建一个分区函数，根据表中列的值或值的范围来选择一个分区，例如

create partition function F_AccPrdPart (int)
    as range left for values (
    180001                         -- Dummy value
   ,199012 ,199112 ,199212 ,199312, 199412 ,199512
   ,199612 ,199712 ,199812 ,199912 ,200012 ,200112
   ,200212 ,200312 ,200412 ,200512 ,200612 ,200712
   ,200812
   ,200901, 200902, 200903, 200904, 200905, 200906
   ,200907, 200908, 200909, 200910, 200911, 200912
   ,201001, 201002, 201003, 201004, 201005, 201006
   ,201007, 201008, 201009, 201010, 201011, 201012
   ,201101, 201102, 201103, 201104, 201105, 201106
   ,201107, 201108, 201109, 201110, 201111, 201112
   ,202012
   ,939999                         -- Dummy value
)
go

然后创建一个或多个文件组来分配分区。对于大型数据集，可以在不同的物理卷上设置这些文件组。请注意，在几乎所有情况下，直接连接存储都将比SAN快得多。在下面的示例中，我们将创建6个文件组，称为PartVol1-PartVol6。

可以创建一个或多个分区方案，以根据分区函数的值将表分区分配给文件组，例如

create partition S_AccPrdPart as partition F_AccPrdPart
    TO ([PRIMARY]
      ,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6] 
      ,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
      ,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
      ,[PartVol1]
      ,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
      ,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
      ,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
      ,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
      ,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
      ,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
      ,[PartVol2]
      ,[PRIMARY]
      ,[PRIMARY])
go

此方案旨在按会计期间进行划分。尽管也可以使用任何键，但日期也经常用于此目的。

您可以在分区方案上创建表，就好像它是文件组一样，例如

Create table FooTrans (
       FooTransID        int identity (1,1) not null
      ,AccPeriod         int not null
      ,[...]
) on S_AccPrdPart (AccPeriod)
go

注意，表是在分区方案上创建的，而不是在指定的文件组上创建的，并且该子句指定要用作分区键的列。根据分区键，表中的行将分配给分区方案中的文件组之一。

注意：设计分区方案的经验法则是，每个分区的行数应在百万个数的低10位数之内，例如在10到5000万之间，具体取决于行的宽度。分区所在的磁盘卷应足够快以在几秒钟内扫描至少一个分区。

分区，分片和无共享系统

似乎有些术语是为了消除有关该主题的某些讨论的歧义。

“无共享”系统是一个并行系统，其中节点没有共享的SAN存储，但是使用节点本地的存储。这种架构的经典示例是Teradata。无共享系统可以很好地扩展到非常大的数据集，因为它们没有中央I / O瓶颈。I / O吞吐量随系统中节点的数量而扩展。
“共享磁盘”系统是一个或多个数据库服务器共享一个磁盘存储子系统的系统。数据库可以是具有本地存储或连接到SAN的单个服务器，也可以是连接到共享SAN的服务器集群。这种类型的系统受到存储子系统可用吞吐量的限制。
“共享”是一个术语，用于描述在无共享体系结构中的多个物理服务器之间拆分数据库。各种平台将对分片数据库提供或多或少的支持。在Teradata圈子中，未使用该术语是因为Teradata向客户端提供了透明的单个系统映像，即使物理体系结构是不共享的类型。

较旧版本的SQL Server对通过分布式分区视图进行分片的支持有限。Microsoft现在制作了一个SQL Server 2008 R2版本，该版本支持具有单个系统映像的无共享体系结构，但是该版本仅适用于OEM，并且只能通过硬件捆绑购买。

对于十亿行

对于10亿行（除非各个行非常宽），在过度杀伤的领域中，完全没有共享或分片的体系结构是很舒服的。如果具有足够快速的磁盘子系统，则可以在具有合理规格的单个服务器上处理这种类型的卷。

就性能价格而言，本地直接连接磁盘是迄今为止最具成本效益的。单个SAS RAID控制器可以采用多个阵列，并且可以在服务器中安装多个控制器。根据配置，现代的24-25插槽SAS阵列可提供数千IOPS或1GB + /秒的流性能。理论上，具有多个PCI-e总线和多个控制器的服务器可以处理更多任务。

使用商品服务器硬件和这种类型的直接连接存储，可以轻松，廉价地实现与10亿行数据库一起工作所需的性能类型。也可以使用SAN，但是您可能需要多个SAN控制器才能获得同等的性能，并且硬件的价格可能要贵一个数量级。

作为一般建议，除非需要真正的正常运行时间，否则将直接连接存储用于对I / O要求很高的应用程序。与现代数据中心操作中的硬件故障相比，配置和变更控制错误是造成计划外停机的主要原因。

如果您拥有大量应用程序，SAN可以为您提供一个更易于管理的存储平台，因为它们可以为您提供一系列集中式存储管理功能。但是，这要付出高昂的代价，要想从基于SAN的基础架构中获得高性能，既困难又昂贵。

¹ Microsoft确实制作了并行版本的SQL Server，但只能通过与硬件捆绑在一起的OEM渠道使用。现成的版本不支持此功能。

— 关注TunbridgeWells
source

哇-很棒的答案，我认为这是使该项目正常运行所需的所有提示。