大型数据库的优化技术

Question

您在超大型数据库上使用了哪些优化技术？如果我们的估计是正确的，我们的应用程序将在db（MS SQL Server 2005）中存储数十亿条记录，主要是用于统计的日志。数据包含数字（主要是整数）和文本（错误消息文本，URL）等。

我对任何提示，黑客，解决方案感兴趣。

Answer 1

这个问题有点模糊，但这里有一些提示：

• 为数据库使用适当的硬件。我也选择64位操作系统。
• 为DB提供专用机器。使用配置的快速磁盘以获得最佳性能您可以跨越的磁盘越多，性能就越好。
• 针对将要执行的查询类型优化数据库。更多SELECT或INSERT会发生什么？
• 负载是在一整天或几小时内发生的吗？你能推迟一些晚上要运行的东西吗？
• 进行增量备份。
• 如果您考虑使用Oracle而不是SQL Server，则可以使用Grid和Table Partitioning等功能，这可能会大大提高性能。
• 考虑在数据库服务器之间使用一些负载平衡解决方案。
• 预先设计方案和表格，以便尽快执行查询。考虑适当的索引。

您必须更加具体地了解存储这些日志的方式。他们是DB中的LOB吗？简单的文字记录？

Answer 2

我自己不使用它，但我已经读过，可以将Hadoop与hbase结合使用，用于分布式存储和分布式数据分析，如日志。

Answer 3

duncan's链接有一套很好的提示。以下是一些提示：

如果您不需要查询完整的最新数据（即，如果数据可以接受最后一小时或昨天的业务结束），请考虑为分析构建单独的数据集市。这允许您针对快速分析查询进行优化。

SQL Server查询优化器有一个星形转换运算符。如果查询优化器重新认识了这种类型的查询，它可以在触及事实表之前通过基于维度表进行过滤来选择所需的数据片段。这减少了查询所需的I / O量。

对于涉及大型表扫描的VLDB应用程序，请考虑使用尽可能多的控制器而不是SAN来直接连接存储。您可以更便宜地获得更多带宽。但是，如果您的数据集小于（比如）1TB左右，那么它可能不会产生很大的差异。

如果在查询访问中具有引用位置，则具有大量RAM的64位服务器适用于缓存。但是，表扫描没有引用的位置，因此一旦它比服务器上的RAM大得多，额外的内存就无助于此。

如果您对事实表进行分区，请考虑将每个分区放在单独的磁盘阵列上 - 或者如果您的SAS阵列具有端口复制，则至少要将其放在单独的SAS或SCSI通道上。请注意，如果您经常跨多个分区执行查询，这只会产生影响。