我阅读了您的文章(SQL Server 分区:不是所有问题的答案)并且对我的情况使用分区感到惊讶我必须每秒存储大约 1000 条记录,这些数据是关于移动节点的位置,这些数据构成了我的数据库你认为我是否必须对我的数据库进行分区太大(我将来有很多报告)。
4 回答
一秒1000也不算多。
- 是 24/7 的每一秒吗?
- 在定义的窗口中?
- 它是每秒 1000 次但通常更少的峰值吗?
我们最近的系统以每月 2000 万行的速度增长(在整理后说另外 50-8000 万行),我们没有考虑分区之类的事情。
这是很多数据。
数据的生命周期是什么,即您只需要在有限的时间内存储记录吗?例如一个月后,也许某些数据可以归档或移动到数据仓库?
考虑到您打算使用的数据量,您可能想要使用易于扩展的架构?出于这个原因,您可能希望考虑在 Azure 平台上使用云类型服务,例如 Amazon Ec2 或 SQL 数据服务。
http://www.microsoft.com/azure/data.mspx
也许如果您提供有关您实际想要做什么的更具体的细节,即您希望支持的业务流程,我们也许能够提供更具体的帮助。
如果没有这些详细信息,就无法确定 SQL Server 分区是否适合您的设计方法。
假设有问题的表是索引的,那么当任何索引超出可用 RAM 时,肯定需要两个选项之一。毫不奇怪,其中之一就是增加 RAM。另一个当然是垂直分区。
gbn 的答案提供了一些您没有提到的好东西,例如每月(或每周或每天)添加多少条记录。Richard 关于(平均)记录有多大的评论也很重要,特别是在索引的平均记录有多大方面,假设索引不包括表中的所有字段。
然而,gbn 的回答对我来说似乎也有点鲁莽。每月增长 2000 万行,甚至没有“考虑分区之类的事情”。如果没有上述足够的指标,这可能会导致灾难。在需要考虑更多 RAM 或分区之前,您至少应该考虑一下,即使只是为了确定您可以维持当前和/或预期的增长率多长时间。
您可能需要查看不同的 RDMS。我会看看Vertica。