cap*_*aig 7 sql-server database-design
我正在建立一个我预计会非常大的数据库,用于计算和数据存储.它将是一个包含10个字段的表,其中包含一个主键和两个外键.我预计每天会增加约10亿条记录.
每个记录应该很小,我将主要做插入.对于每个插入,我将需要对连接记录的一个或两个字段进行简单更新.所有查询都应该相对简单.
在什么尺寸下我会开始遇到sql-server的性能问题？我已经看到了vldb系统的提及,但也听说它们可能是一个真正的痛苦.有一个门槛,我应该开始考虑吗？是否有比为这类东西设计的sql-server更好的数据库？
Rem*_*anu 22
当谈论超过10k /秒的交易率时,你不应该在论坛上提出建议......这与32和64种方式的TPC-C基准性能接近,这需要花费数百万美元来调整.
你会遇到什么尺寸的问题？
通过良好的数据模型和模式设计,正确调整并具有正确容量的计划服务器将不会遇到问题.每天的记录.最新发布的SQL Server基准测试大约为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亿美元.每天记录到数据库中.我并没有声称我在这里做了容量规划,但我只想给你一个关于我们在谈论什么的大概.这是一个价值数百万美元的项目,这样的事情并不是通过在论坛上提出建议来设计的.
Nei*_*l N 11
除非你像Google的索引类型那样说话很大,否则像SQL Server或Oracle这样的企业数据库就可以了.
詹姆斯·德夫林(James Devlin)在Coding the Wheel上总结得很好(虽然这更像是免费数据库之间的比较,比如MySQL和Oracle/SQL Server
现在我喜欢将SQL Server和Oracle视为关系数据库世界的死星.非常强大.单片.辉煌.复杂几乎超出了单一人类思维的能力.除了在你真正需要摧毁一颗行星的罕见情况之外,还有巨大的浪费.
就性能而言,这一切都取决于您的索引策略.插入确实是这里的瓶颈,因为记录需要在它们进入时编入索引,索引越多,插入的时间就越长.
对于类似谷歌索引的内容,请阅读"大桌面",谷歌将其设置为使用服务器集群来处理大量数据的搜索,仅仅是毫秒,这让人感到有趣.
它可以完成,但考虑到你的硬件成本和计划,让MS为你制定规范.它将是您硬件成本的一小部分.
据说,2年前Paul Nielson 在博客上写了大约35k TPS(每天30亿行).值得一读的评论也反映了Remus所说的一些内容
| 归档时间： |
|
| 查看次数： |
6666 次 |
| 最近记录： |