我正在为高性能大型 SQL Server 2016 数据库设计基于分区的解决方案。一些数据每天将有数亿条记录。在白天，我们还将运行报告查询和查询以寻找多天和多周的趋势。
我当前的解决方案将在每日分区中使用 70 天，每个分区使用一个专用文件组。数据超过 70 天标记后，它将进入每周分区，持续 42 周，每个分区也使用专用文件组，然后是 12 个月，然后是 6 年，所有这些都以相同的方式设置。
我们需要真正的高性能和大规模扩展能力（PB+ 范围）。为了最大限度地减少返工，我正在考虑为每日和每周文件组/分区使用每个文件组/分区的多个文件。确切地说，每天 4 次，每周 2 次。
通过这种方式，我们可以潜在地增加每个分区的读取/加载吞吐量，以及增加分区的最大容量（不要问为什么，但我们担心在某些日子实际上需要该级别的容量）。
有没有人这样做过，你的结果是什么？除了管理开销之外，还有什么理由不这样做吗？
所有每周、每月和每年的分区都将位于同一服务器上的同一数据库中（应用程序设计问题，但如果动机适当，多数据库可能是一种选择。多个服务器或实例是不可取的）。
目前正在讨论和评估分区中断。我根据收到的有关查询模式的信息选择了上述值。不同的天数当然是可能的，但我有点喜欢 10 周的每日分区。
我们确实有一个非常高端的数据中心，实际上是 2。我们正在讨论购买特定于该平台和其他平台的融合解决方案。我个人希望看到专用的 AFA（全闪存阵列），但在我得到这些之前，还有一些桥梁需要跨越。
我知道Data Warehouse Fast Track解决方案，但它们对我们不起作用。一方面，我们将主要进行 OLTP，因此基准数据将不能代表我们将得到的结果。其次，它们的规模不够大（目前）。来自参考架构的一些元素当然会被使用，但“交钥匙”SKU 将不是一种选择。我是前 MS PFE，所以这些资源是我首先查看的资源。