3

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

目前表的方式是：

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

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

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

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

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


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

4

3 回答 3

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

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

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

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

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

于 2009-04-20T00:44:35.883 回答
1

规范化和索引。

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

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

于 2009-04-19T23:16:53.097 回答
1

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

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

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

于 2009-04-19T23:31:47.257 回答