扩展 MS SQL Server 2008 数据库

Question

我正在尝试找出扩展我的网站的最佳方式，但我对 mssql 将如何扩展有疑问。

表格目前的样子：

cache_id - int - 标识符
cache_name - nvchar 256 - 与 event_id 一起用于查找
cache_event_id - int - 基本上是一种分组方式
cache_creation_date - 日期时间
cache_data - varbinary(MAX) - 数据大小从 2k 到 5k

存储的数据是一个字节数组，基本上是我网站上一个页面的缓存实例（压缩）。

我看到存储的不同方式是：
1) 一张大表，它会包含几千万条记录，很容易变成几G。
2) 多个表包含上述数据，这意味着每个表将包含 200k 到 100 万条记录。

该表中的数据将用于显示网页，因此任何超过 200 毫秒的记录在我看来都是不好的（我知道有些人认为 1-2 秒的页面加载是可以的，但我认为这很慢而且想尽我所能保持低）。

所以归结为，是什么降低了 SQL 服务器的速度？
是表的大小（磁盘空间）
是行数
什么时候使用多个数据库服务器不再具有成本效益？


如果几乎​​不可能预测这些事情，我接受它作为回复。我不是 DBA，我基本上是在尝试设计我的 DB，所以当它包含大量数据时，我不必在以后重新设计它。

Answer 1

所以归结为，是什么降低了 SQL 服务器的速度？ 是否是表的大小（磁盘空间） 是行数 在什么时候使用多个不再具有成本效益 数据库服务器？

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

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

事务负载很大程度上是代码设计和用户总数的一个因素。代码设计包括正确处理事务大小等因素（总体目标是小而快，但像大多数事情一样，有可能把它带到很远并且事务太小而无法保持完整性或太小以至于本身会增加负载） .

在扩展时，我建议先扩展（更大、更快的服务器），然后再扩展（多台服务器）。多服务器实例的管理问题非常重要，我建议只对具有操作系统、网络和 DBA 技能和流程匹配的站点进行考虑。

Answer 2

标准化和索引。

如何，我们不能告诉你，因为你还没有告诉 use 你的表试图建模什么或者你试图如何使用它。

100 万行并不罕见。同样，在没有上下文的情况下，我们无法告诉您太多信息，只有您可以提供，但不要提供。

Answer 3

唯一可能的答案是设置它，并为长期迭代的学习过程做好准备，只有你会知道，因为只有你会生活在你的领域中。您在此处看到的任何技术建议都将是幼稚的，并且在您有一些实际经验可以分享之前，信息不足。

测试你的每一个猜测，比较结果，看看什么有效。并继续寻找更多可测试的想法。 （不要害怕放弃最终无济于事的更改。保持简单的任何希望都是基本要求。）

并接受您的数据库设计将不断发展的事实。它并不像您的评论所暗示的那样可怕。更改数据库比更改数据库要容易得多。