我想为在线资源(博客、指南等--而不是论坛)提供一些建议,以帮助我更好地设计高性能的SQL Server数据库,这些数据库可以处理大量的数据,并且在数据周转和每分钟查询方面有很大的负担。
有什么建议吗?
编辑
我所说的负载主要是关于数据周转的。主表有多达一百万行,大约有30个不同大小的数据字段,每天更新30到40000行,每天至少有200000行用新数据更新。这些更新是在一天中持续进行的。最重要的是,所有的更改和更新都需要全天从数据库中删除,以保持一个大型Lucene索引的最新更新。
发布于 2010-03-21 00:51:18
在中等规模的服务器上,听起来是相当容易管理的负载--您还没有说明在执行这些插入和更新时(除了Lucene的提取)和数据大小(按字节/数据类型划分)时发生了什么样的读取操作(您给出的基数似乎很好)。
此时,我建议您只使用常规Server最佳实践 --确定一个合适的模式(规范化,然后只在必要时进行去normalize),审查执行计划,使用索引调优向导,使用DMV查找和删除未使用的索引,仔细选择聚集索引来管理页面分割,仔细选择数据类型和大小,以及尽可能地使用在可能的情况下使用引用完整性和约束为优化器提供尽可能多的帮助。除此之外,还有性能计数器,并确保您的硬件/软件安装是调优的。
在许多/大多数情况下,您将永远不需要超越这个范围来实际重新设计您的体系结构。
但是,即便如此,如果读取负载很重,插入和更新也会导致读写之间的锁定问题,然后您将查看应用程序的体系结构决策。
另外,每天更新的数百万行和200 k的更新不会让我担心--但是您会提到Lucene (即全文索引),因此可能有些列相当大。更新大型列并导出它们显然需要花费更长的时间,更多的带宽和IO。窄百万行表中的30列与传统的数据类型列完全不同。您可能需要查看update配置文件,看看是否需要垂直划分表以将某些列移出行(如果列很大,它们将被存储在行外),以改进锁定行为。
因此,当您有沉重的读取负载时,关键是:插入和更新需要尽可能快,锁越少越好(避免锁升级),更新尽可能少的索引以支持读取操作。
如果读取负载太重(以致插入/更新开始发生冲突),但不需要100%的最新信息(例如,5分钟或15分钟的延迟是不明显的),则可以维护数据库的只读版本(通过复制进行相同的索引,为性能建立不同的索引,取消规范化或建模不同--比如维度模型)。也许您的Lucene索引可以包含其他信息,这样昂贵的读取操作都在Lucene中--即Lucene将覆盖许多大型读取操作,从而将数据库上的读取负载减少到支持插入/更新(这些通常是小读取)和应用程序的事务性部分(例如,客户服务信息屏幕将使用常规数据库,而您的每小时仪表板将使用二级数据库)。
发布于 2010-03-20 15:17:48
您可以尝试Server示例 on CodePlex或DatabaseAnswers.com。
发布于 2010-03-20 15:50:56
下面是有关Server中的故障排除和优化性能的一些资源,我发现这些资源非常有用:
http://updates.sqlservervideos.com/2009/09/power-up-with-sql-server-sql-server-performance.html
特别是,有效地使用索引可以极大地提高性能。我认为,在大多数情况下,大多数web应用程序的阅读要比编写多得多。此外,表达式的sargability可能会对性能产生严重影响。
https://stackoverflow.com/questions/2483525
复制相似问题