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

Question

这个问题是涉及到另一个问题：
Will having multiple filegroups help speed up my database?

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

我们目前的做法是保存分析结果在一系列的“运行特定的”表和分析是复杂的，以至于我们可能最终每分析多达100桌。通常这些表每次分析使用几百MB（与我们的数百GB或有时多TB的源数据相比，这些表很小）。但总的来说，磁盘空间对我们来说不是问题。每组表格都专门用于一个分析，在许多情况下，这就为我们回溯源数据提供了巨大的性能改进。

一旦我们积累了足够的已保存分析结果 - 在我们添加更强大的归档/清理功能之前，我们的测试数据库爬到了几个表中，该方法开始崩溃。但即使在生产中，拥有超过10万张桌子也不算什么。微软在系统对象的规模（〜20亿）方面提出了相当大的理论限制，但是一旦我们的数据库增长超过10万，那么像CREATE TABLE和DROP TABLE这样的简单查询就会显着减慢。

我们有一些空间来辩论我们的方法，但我认为这可能很难做到没有更多的上下文，所以我想更普遍地提出这个问题：如果我们被迫创建这么多的表，什么是最好的方法来管理它们？多个文件组？多个模式/所有者？多个数据库？

另注：我不是激动不已的“简单的问题抛硬件”（即添加RAM，CPU电源，硬盘速度）的想法。但是我们也不会排除它，特别是如果（例如）有人可以明确地告诉我们添加RAM或使用多个文件组将对管理大型系统目录有什么影响。

Answer 1

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

该方法允许每个数据库的系统目录更加合理，它提供了核心/永久表与动态/运行表之间更好的分离，并且还使备份和归档更易于管理。它还允许我们将数据分割到多个物理磁盘上，尽管使用多个文件组也可以实现这一点。总体而言，考虑到我们目前的要求，我们现在对我们运作良好，并且基于预期的增长，我们认为它也将适合我们。

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

Answer 2

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

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

您将需要认真的数据仓库和数据/表分区的组合。根据您想要保存和归档的数据量，您可能需要开始去归一化和展平表格。

这将是相当不错的情况下直接联系Microsoft可以互惠互利。 Microsoft可以很好地向其他客户展示，并且您可以直接从供应商那里获得帮助。

Answer 3

表是所有不同的结构？如果它们具有相同的结构，则可能会使用单个分区表。

如果它们是不同的结构，但就在同一组维列的子集，你仍然可以将它们存储在分区在同一个表中不适用的列空。

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

Answer 4

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

另一种可能是把每个运行在自己的数据库，然后分离，最后只有安装并根据需要（在只读形式）

CREATE TABLE和DROP TABLE很可能表现不佳，因为主或模型数据库没有针对这种行为进行优化。

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