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


4

这个问题是涉及到另一个问题:
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或使用多个文件组将对管理大型系统目录有什么影响。

  0

WOW。对于许多表,Management Studio在加载列表时会做什么?这一定是痛苦的。 23 9月. 082008-09-23 23:38:19

  0

我们不敢让Management Studio拉起一张表的列表。任何时候有人不经意地这样做,要么他们必须杀死这个过程,要么就是崩溃。但这远不是我们最大的问题。 30 12月. 082008-12-30 14:49:17

  0

我很好奇这是怎么发生的,这似乎是一个几乎没有人有关于如何做到这一点的坚实信息的领域,这全是理论。所以任何答案都是很好的知道的。 16 8月. 112011-08-16 06:58:58

0

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

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

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


0

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

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

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

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


1

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

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

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


2

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

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

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

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