每个分区/文件组有多个文件？

Question

我正在为高性能大型 SQL Server 2016 数据库设计基于分区的解决方案。一些数据每天将有数亿条记录。在白天，我们还将运行报告查询和查询以寻找多天和多周的趋势。

我当前的解决方案将在每日分区中使用 70 天，每个分区使用一个专用文件组。数据超过 70 天标记后，它将进入每周分区，持续 42 周，每个分区也使用专用文件组，然后是 12 个月，然后是 6 年，所有这些都以相同的方式设置。

我们需要真正的高性能和大规模扩展能力（PB+ 范围）。为了最大限度地减少返工，我正在考虑为每日和每周文件组/分区使用每个文件组/分区的多个文件。确切地说，每天 4 次，每周 2 次。

通过这种方式，我们可以潜在地增加每个分区的读取/加载吞吐量，以及增加分区的最大容量（不要问为什么，但我们担心在某些日子实际上需要该级别的容量）。

有没有人这样做过，你的结果是什么？除了管理开销之外，还有什么理由不这样做吗？

所有每周、每月和每年的分区都将位于同一服务器上的同一数据库中（应用程序设计问题，但如果动机适当，多数据库可能是一种选择。多个服务器或实例是不可取的）。

目前正在讨论和评估分区中断。我根据收到的有关查询模式的信息选择了上述值。不同的天数当然是可能的，但我有点喜欢 10 周的每日分区。

我们确实有一个非常高端的数据中心，实际上是 2。我们正在讨论购买特定于该平台和其他平台的融合解决方案。我个人希望看到专用的 AFA（全闪存阵列），但在我得到这些之前，还有一些桥梁需要跨越。

我知道Data Warehouse Fast Track解决方案，但它们对我们不起作用。一方面，我们将主要进行 OLTP，因此基准数据将不能代表我们将得到的结果。其次，它们的规模不够大（目前）。来自参考架构的一些元素当然会被使用，但“交钥匙”SKU 将不是一种选择。我是前 MS PFE，所以这些资源是我首先查看的资源。

Answer 1

这是一个有趣的问题，我自己也有类似的问题。我相信在某些情况下，每个文件组多个文件可以帮助提高性能，具体取决于您的硬件配置（核心数量）和物理 I/O 设计（文件可以分布在多个驱动器上）

当然，您将在 Raid 10 配置中使用 SSD 作为生产数据驱动器，并且拥有大量服务器内存，因此大多数页面都是从磁盘读取的。对于该硬件，我不确定物理设计有多重要。