【发布时间】:2009-01-04 10:28:03
【问题描述】:
您在超大型数据库上使用了哪些优化技术?如果我们的估计是正确的,我们的应用程序将在数据库中存储数十亿条记录(MS SQL Server 2005),其中大部分是用于统计的日志。数据包含数字(主要是整数)和文本(错误消息文本、URL)等。
我对任何类型的提示、技巧、解决方案都感兴趣。
【问题讨论】:
标签: sql performance optimization
您在超大型数据库上使用了哪些优化技术?如果我们的估计是正确的,我们的应用程序将在数据库中存储数十亿条记录(MS SQL Server 2005),其中大部分是用于统计的日志。数据包含数字(主要是整数)和文本(错误消息文本、URL)等。
我对任何类型的提示、技巧、解决方案都感兴趣。
【问题讨论】:
标签: sql performance optimization
这个问题有点模糊,但这里有一些提示:
您将不得不更具体地了解存储这些日志的方式。它们是数据库中的 LOB 吗?简单的文本记录?
【讨论】:
我自己不使用它,但我读到可以将 Hadoop 与 hbase 结合使用,用于分布式存储和分布式数据分析,如日志。
【讨论】:
duncan's 链接有一套很好的提示。这里还有一些提示:
如果您不需要查询完全最新的数据(即,如果可以接受截至最后一小时或昨天营业结束的数据),请考虑为分析构建单独的数据集市。这使您可以针对快速分析查询进行优化。
SQL Server 查询优化器有一个星形转换运算符。如果查询优化器识别出这种类型的查询,它可以通过在接触事实表之前基于维度表进行过滤来选择您想要的数据切片。这减少了查询所需的 I/O 量。
对于涉及大型表扫描的 VLDB 应用程序,请考虑使用尽可能多的控制器而不是 SAN 的直接附加存储。您可以更便宜地获得更多带宽。但是,如果您的数据集小于(例如)1TB 左右,它可能不会产生太大的影响。
如果您在查询访问中具有参考位置,则具有大量 RAM 的 64 位服务器非常适合缓存。但是,表扫描没有参考位置,因此一旦它变得比服务器上的 RAM 大得多,额外的内存就没有多大帮助了。
如果您对事实表进行分区,请考虑将每个分区放在单独的磁盘阵列上 - 如果您的 SAS 阵列具有端口复制功能,则至少是一个单独的 SAS 或 SCSI 通道。请注意,只有在您经常跨多个分区进行查询时,这才会有所作为。
【讨论】: