需要建议：适用于大型数据库的SQL Server数据库架构

Question

您好！

我的客户端目前有一个SQL Server数据库，每天执行3-4百万个插入，每天更新更多，甚至更多。当前的数据库是奇怪的布局恕我直言：进来的数据去“当前”表，然后每晚记录移动到相应的月度表（即MarchData，AprilData，MayData等），这是当前表的精确副本意思）。读取是从UNION所有月度表和当前表，插入和更新仅对当前表完成的。有人向我解释说，将数据分成13个表是因为所有这些表使用单独的数据文件，而这些数据文件被写入13个物理硬盘驱动器。所以每张桌子都有自己的硬盘，据说可以加快观看效果。我注意到的是，夜间记录移动到每月表（每隔2分钟进行一次，每晚8小时）与完全备份一致，数据库开始爬行，网站超时等。

我是想知道这种方法真的是最好的方法吗？或者我们可以考虑一种不同的方法？请注意，该数据库大约为300-400 GB，并且每天增长1.5-2 GB。我们经常将超过12个月的记录移到单独的数据库（归档）中。

任何有识之士高度赞赏。

Answer 1

有人向我解释，数据为13代表的分离的事实， 所有的表都使用单独的数据文件和文件写入到13个物理硬盘驱动器 这些数据的动机。所以每个表都有自己的硬盘，

这是一个声明：IDIOTS在工作。

• 表格不是存储在光盘上，而是存储在可以跨越多个数据文件的文件空间中。注意这个......所以你可以有一个文件空间在13个碟片上有12个数据文件，并且一个表格将在所有13个表格上分布。不需要玩愚蠢的愚蠢游戏来分配负载，只需阅读文档就可以了。

• 即使那样，我严重怀疑13光盘快。真。我私人运行一个较小的数据库（仅800GB），其中有6张光盘供数据使用，而我目前的工作分配是三位数字的光盘（即100+）。请不要将13张光盘命名为大型数据库。

• 无论如何，应该需要分布数据，而不是UNION，但分区表（atgain标准的sql服务器，尽管企业版功能）是要走的路。

请记住，数据库是大约300-400 GB，并通过每天1.5-2 GB增长。

得到一个体面的服务器。

我想知道这种方法真的是最好的方法吗？

• 哦，硬件。为数据库2至4个机架单位高的SAS数据库，24至72个光盘插槽提供一个SuperMicro盒。是的，一台电脑。

• 报废每月blabla表废话，有人想出谁显然不适用于数据库。所有在一张桌子。使用文件空间和多个数据文件来处理所有表格到各种光盘的负载分配。除非...

• ...你实际上意识到，像这样运行的光盘是严重的忽视。 RAID 5或RAID 6或RAID 10是有序的，否则当光盘发生故障时，您的服务器可能会发生故障，这将发生，并且重新安装600GB数据库需要时间。我为我的数据光盘运行RAID 10，但后来私下拥有大约10亿行的表格（并且我们每天都会添加这样的表格）。考虑到数据库的小尺寸，一对SSD也会有所帮助......他们的IOPS预算意味着您可以访问2-3张光盘并获得更多的速度。如果这是不可能的，我敢打赌，这些光盘是慢速的3.5英寸光盘，7200RPM ......企业级光盘的升级将会有所帮助，我个人使用300GB Velociraptors用于数据库，但是有15k SAS光盘可以使用; ）

Anyho，这听起来实在太差成立。如此糟糕，我要么很高兴我的学员想出了一些聪明的（因为它竟被肯定会在学员的头），或我的开发人员当我发现这一点时（根据总体无能，随时在法庭上挑战）

重组它。也要小心处理任何批处理 - 那些需要时间交错，以便它们不重叠wioth备份。有只有简单的低速盘才能提供这么多的IO。

Answer 2

如果您使用的是MS SQL Server，请考虑Partitioned Tables and Indexes。

简而言之：您可以按某个值对行进行分组，即按年份和月份分组。每个组都可以作为具有自己索引的独立表访问。因此，您可以在不访问所有行的情况下列出，总结和编辑2011年2月的销售情况。分区表使数据库变得复杂，但如果表格太长，可能会导致性能显着提高。它还支持“文件组”以将值存储在不同的磁盘中。

这个MS制作的解决方案与您的解决方案非常相似，除了一件重要的事情：它不会在一晚上移动记录。