sql-server之扩展 MS SQL Server 2008 数据库
我正在尝试找出扩展我的网站的最佳方式,但我对 mssql 的扩展方式有疑问。
表格目前的样子:
cache_id - int - identifier
cache_name - nvchar 256 - Used for lookup along with event_id
cache_event_id - int - Basicly a way of grouping
cache_creation_date - datetime
cache_data - varbinary(MAX) - Data size will be from 2k to 5k
存储的数据是一个字节数组,基本上是我网站上页面的缓存实例(压缩)。
我看到的不同存储方式是:
1) 一张大表,几千万条记录,很容易变成几千兆字节。
2) 多个表包含上述数据,这意味着每个表将有 200k 到 100 万条记录。
该表中的数据将用于显示网页,因此在我看来任何超过 200 毫秒的记录都是不好的(我知道有些人认为 1-2 秒的页面加载是可以的,但我认为那很慢而且我想尽我最大的努力保持较低的水平)。
归根结底,是什么减慢了 SQL 服务器的速度?
是表的大小(磁盘空间)
是行数
使用多个数据库服务器在什么时候不再具有成本效益?
如果它几乎不可能预测这些事情,我会接受它作为对的回复。我不是 DBA,我基本上是在尝试设计我的数据库,这样当它包含大量数据时我就不必再重新设计它。
请您参考如下方法:
So it boils down to, what is it that slows down the SQL server? Is it the size of the table ( disk space ) Is the the number of rows At what point does it stop becoming cost effective to use multiple database servers?
这都是“经验法则”观点; 数据库的负载(因此在相当大的程度上是性能)主要是两个问题数据量和事务负载的一个因素,恕我直言,第二个通常更相关。
关于数据量,可以容纳数 GB 的数据,并通过规范化、索引、分区、快速 IO 系统、适当的缓冲区缓存大小等方式获得可接受的访问时间。其中许多,例如规范化是人们在 DB 设计时考虑的问题,其他问题是在系统调整期间考虑的,例如添加/减少索引,缓冲区缓存大小。
事务负载主要是代码设计和用户总数的一个因素。代码设计包括一些因素,比如让事务大小合适(小而快是总体目标,但像大多数事情一样,它可能会走得太远,事务太小而无法保持完整性,或者太小以至于本身会增加负载) .
扩展时,我建议先向上扩展(更大、更快的服务器),然后再向外扩展(多个服务器)。多服务器实例的管理问题很重要,我建议只有操作系统、网络和 DBA 技能和流程相匹配的站点才值得考虑。
1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。