SQL-Server数据库的实际限制

Question

我正在建立一个我预计会非常大的数据库，用于计算和数据存储。它将是一个包含10个字段的表，其中包含一个主键和两个外键。我预计每天会有大约10亿条记录。

每条记录都应该很小，我主要是做插入。对于每个插入，我将需要对连接记录的一个或两个字段进行简单更新。所有查询都应该相对简单。

我将以什么尺寸开始遇到sql-server的性能问题？我已经看到了vldb系统的提及，但也听说它们可能是一个真正的痛苦。有一个门槛，我应该开始考虑吗？是否有比为此类设计的sql-server更好的数据库？

Answer 1

当谈论超过10k /秒的交易率时，你不应该在论坛上提出建议......这与32和64种方式的TPC-C基准性能接近，这需要花费数百万美元来调整。

你会遇到什么尺寸的问题？

通过良好的数据模型和架构设计，正确调整并具有正确容量的计划服务器将不会遇到问题。每天的记录。最新发表的SQL Server benchmarks约为1.2 mil tran / min。这相当于每秒16k的交易量，2005年的系统价格为600万美元（64路Superdome）。要达到10k tran / sec的计划负载，你不需要Superdome，但是你需要一个非常强大的系统（可能至少16路），特别是一个非常好的I / O子系统。当进行信封容量规划时，通常会考虑每个HBA大约1K tran / sec和4个CPU内核来为HBA提供信息。而且您将需要相当多的数据库客户端（应用程序中间层）才能提供1亿美元。每天记录到数据库中。我并没有声称我在这里做了容量规划，但我只想给你一个关于我们在谈论什么的大概。这是一个价值数百万美元的项目，这样的事情不是通过在论坛上提出建议来设计的。

Answer 2

除非你像Google的索引类型那样说话很大，否则像SQL Server或Oracle这样的企业数据库就可以了。

James Devlin over at Coding the Wheel summed it up nicely（虽然这更像是免费的数据库，如MySQL与Oracle / SQL Server之间的比较

  

如今我喜欢将SQL Server和Oracle视为关系数据库世界的死星。非常强大。单片。辉煌。复杂几乎超出了单一人类思维的能力。除了在你真正需要摧毁一颗行星的罕见情况之外，还有巨大的金钱浪费。

就性能而言，这一切都取决于您的索引策略。插入实际上是瓶颈，因为记录需要在它们进入时编入索引，索引越多，插入的时间就越长。

如果像谷歌的索引一样，请阅读“大桌面”，谷歌将其设置为使用服务器集群来处理大量数据的搜索只是毫秒，这一点很有趣。

Answer 3

可以这样做，但考虑到你的硬件成本和计划，让MS为你制定规范。它将是您硬件成本的一小部分。

两年前，Paul Nielson blogged about 35k TPS（每天30亿行）这样说。值得一读的评论也反映了Remus所说的一些内容

Answer 4

数据库本身的大小不会产生性能问题。数据库大小的实际问题来自运营/维护问题。

例如：

1. 解密和重建索引需要太长时间。
2. 备份时间过长或占用太多空间。
3. 如果发生中断，则无法快速执行数据库还原。
4. 对数据库表的未来更改需要很长时间才能应用。

我建议从一开始就设计/构建某种分区。它可以是SQL Server分区，应用程序分区（例如每月一个表），归档（例如，归档到不同的数据库）。

我相信这些问题都出现在任何数据库产品中。

此外，请务必考虑事务日志文件大小。