在MS SQL Server中管理大量表的最佳方法是什么？

Question

这个问题与另一个问题有关：
有多个文件组会有助于加速我的数据库吗？

我们正在开发的软件是一个分析工具，它使用MS SQL Server 2005来存储关系数据。 初步分析可能很慢（因为我们正在处理数百万或数十亿行数据），但是对于快速调用以前的分析存在性能要求，因此我们“保存”每个分析的结果。

我们当前的方法是将分析结果保存在一系列“特定于运行”的表中，并且分析非常复杂，每次分析最多可能有100个表。 通常，这些表每次分析耗尽几百MB（与我们的数百GB，有时甚至是多TB的源数据相比，这个表很小）。 但总的来说，磁盘空间对我们来说不是问题。 每组表都特定于一个分析，在许多情况下，这为我们提供了超过回溯源数据的巨大性能改进。

一旦我们积累了足够的保存分析结果，这种方法就会开始崩溃 - 在我们添加更强大的归档/清理功能之前，我们的测试数据库已经攀升到数百万个表。 但即使在生产中，我们也不能拥有超过100,000张桌子。 微软对sysobjects的大小（约20亿）进行了相当大的理论限制，但是一旦我们的数据库增长到100,000以上，像CREATE TABLE和DROP TABLE这样的简单查询就会大大减慢。

我们有一些空间来讨论我们的方法，但我认为如果没有更多的背景可能很难做到，所以我想更广泛地提出这个问题：如果我们被迫创建这么多表，那么最好的管理方法是什么他们？ 多个文件组？ 多个架构/所有者？ 多个数据库？

另一个注意事项：我对于“简单地将硬件投入问题”（即添加RAM，CPU功率，磁盘速度）的想法并不感到兴奋。 但我们也不会排除它，特别是如果（例如）某人可以明确地告诉我们添加RAM或使用多个文件组对管理大型系统目录会产生什么影响。

Answer 1

在没有首先看到整个系统的情况下，我的第一个建议是将历史运行保存在组合表中，并将RunID作为键的一部分 - 维度模型也可能与此相关。 可以对此表进行分区以进行改进，这也允许您将表扩展到其他文件组中。

另一种可能性是将每次运行放在自己的数据库中然后分离它们，只根据需要附加它们（并且以只读形式）

CREATE TABLE和DROP TABLE可能表现不佳，因为主数据库或模型数据库未针对此类行为进行优化。

我还建议您与Microsoft讨论您选择的数据库设计。

Answer 2

表格是否都是不同的结构？ 如果它们是相同的结构，您可能会使用单个分区表。

如果它们是不同的结构，但只是同一组维度列的子集，您仍然可以将它们存储在同一个表中的分区中，并且在不适用的列中使用空值。

如果这是分析（衍生定价计算可能？），您可以将计算运行的结果转储到平面文件，并通过从平面文件加载来重用您的计算。

Answer 3

这似乎是您正在使用的一个非常有趣的问题/应用程序。 我很乐意在这样的事情上工作。 :)

你有一个非常大的问题表面区域，这使得很难开始帮助。 您的帖子中有几个解决方案参数不明显。 例如，您计划保留运行分析表多长时间？ 还有很多其他问题需要提出。

您将需要结合严格的数据仓库和数据/表分区。 根据您要保留和存档的数据量，您可能需要开始对表进行反规范化和展平。

这是非常好的情况，直接联系Microsoft可以互惠互利。 微软得到了向其他客户展示的好例子，您可以直接从供应商处获得帮助。

Answer 4

我们最终将数据库拆分为多个数据库。 因此，主数据库包含一个“数据库”表，该表引用一个或多个“运行”数据库，每个数据库包含不同的分析结果集。 然后主“运行”表包含数据库ID，检索保存结果的代码包括所有查询的相关数据库前缀。

这种方法允许每个数据库的系统目录更加合理，它可以更好地分离核心/永久表和动态/运行表，还可以使备份和归档更易于管理。 它还允许我们跨多个物理磁盘分割数据，尽管使用多个文件组也可以这样做。 总的来说，考虑到我们目前的要求，它现在对我们来说运作良好，并且基于预期的增长，我们认为它也将为我们很好地扩展。

我们还注意到SQL 2008倾向于比SQL 2000和SQL 2005更好地处理大型系统目录。 （当我发布这个问题时，我们没有升级到2008年。）