sql-server - 扩展 MS SQL Server 2008 数据库

Question

我正在尝试找出扩展我的网站的最佳方式，但我对 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，我基本上是在尝试设计我的数据库，这样当它包含大量数据时我就不必再重新设计它。

Answer 1

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 rowsAt what point does it stop becoming cost effective to use multiple        database servers?

这都是“经验法则”观点；数据库的负载(因此在相当大的程度上是性能)主要是两个问题数据量和事务负载的一个因素，恕我直言，第二个通常更相关。

关于数据量，可以容纳数 GB 的数据，并通过规范化、索引、分区、快速 IO 系统、适当的缓冲区缓存大小等方式获得可接受的访问时间。其中许多，例如规范化是人们在 DB 设计时考虑的问题，其他问题是在系统调整期间考虑的，例如添加/减少索引，缓冲区缓存大小。

事务负载主要是代码设计和用户总数的一个因素。代码设计包括一些因素，比如让事务大小合适(小而快是总体目标，但像大多数事情一样，它可能会走得太远，事务太小而无法保持完整性，或者太小以至于本身会增加负载) .

扩展时，我建议先向上扩展(更大、更快的服务器)，然后再向外扩展(多个服务器)。多服务器实例的管理问题很重要，我建议只有操作系统、网络和 DBA 技能和流程相匹配的站点才值得考虑。