在每秒存储1000条记录时使用SQL Server分区

Question

我读了你的文章（SQL Server分区：不是一切的答案） 对我的情况使用分区是否令人惊讶 我必须每秒存储大约1000条记录这个数据是关于移动节点的位置，这些数据使我的数据库太大了 你认为我必须分区我的数据库吗（我将来有太多的报道）。

Answer 1

1000秒不是那么多。

• 是24/7的每一秒吗？
• 在定义的窗口中？
• 它是每秒1000的峰值，但通常更少吗？

我们最近有一个系统以每月2000万行的速度增长（经过整理后又增加了5千万到8千万行），我们并没有考虑像分区一样。

Answer 2

这是很多数据。

数据的生命周期是什么，即您是否只需要在有限的时间内存储记录？例如，一个月后，某些数据是否可以存档或移动到数据仓库？

考虑到您打算使用的数据量，您可能希望使用容易扩展的体系结构？因此，您可能希望在Azure平台上使用Cloud类型服务，例如Amazon Ec2或SQL Data Services。

http://aws.amazon.com/ec2/

http://www.microsoft.com/azure/data.mspx

也许如果您提供有关您实际想要做什么的更具体的详细信息，即您希望支持哪些业务流程，我们可能会提供更具体的帮助。

如果没有这些细节，就无法确定SQL Server分区是否适合您。

Answer 3

您可能需要查看其他RDMS。我会看一下Vertica。

Answer 4

假设有问题的表已编入索引，那么当任何索引超出可用RAM时，肯定有两个选项中的一个。毫不奇怪，其中之一就是增加RAM。另一个当然是垂直分区。

gbn的答案提供了一些您未提及的好事，例如每月（或一周或一天）添加的记录数。理查德关于（平均）记录有多大的评论也很重要，特别是在索引的平均记录有多大的情况下，假设索引不包括表格中的所有字段。

然而gbn的回答对我来说似乎有点鲁莽。每月增长2000万行，甚至没有“考虑分区”。如果没有上面提到的足够的指标，这可能会导致灾难。您至少应该考虑它，即使只是为了确定在需要考虑更多RAM或分区之前能够维持当前和/或预期增长率的时间。