使用LogParser将IIS日志放入数据库时​​要使用的备用数据库

Question

我们已经运行了一些使用LogParser将IIS日志转储到SQL Server数据库中的脚本。

然后，我们可以查询它以获取有关命中率，用法等的简单统计信息。将其链接到错误日志数据库和性能计数器数据库以比较用法与错误等时，也很好。

仅在一个系统上实现了此功能，在过去的2-3周中，我们已经拥有一个5GB的数据库，其中包含大约1000万条记录。

这使得对该数据库的任何查询都非常缓慢，并且如果我们继续按原样记录，无疑会导致存储问题。

谁能建议我们可以用于此数据的任何替代数据库，这些数据库对于此类日志会更有效？ 我会对Google的BigTable或Amazon的SimbleDB的任何使用经验特别感兴趣。

这些都适合报告查询吗？ COUNT，GROUP BY，PIVOT？

Answer 1

我以前也遇到过类似的问题。 由于日志文件增长如此之快，所以我开始考虑是否适合将数据库用于IIS日志。 您可能需要考虑两点：

1. 在大多数情况下，我们的IIS日志无法直接提供有用的信息，我们需要对其进行解析以获取统计信息。
2. 同样，在大多数情况下，无需在数据库中准备好IIS日志即可进行查询。

建议将所有日志保留在以前的文件中，但将每周或每月的统计信息（定期处理）存储在数据库中，以便可以随时使用这些基本数据。

Answer 2

您多久更新一次索引？ 您正在对数据执行哪种查询？

也许您可以在每天结束时执行常规的数据整理，以加快其他查询的速度？ （使用此整理的信息创建新表）

就像页面点击量表每天可能记录该页面被点击的次数一样-这样，您不必对每个查询都进行完整的表扫描，您只需点击页面点击量表即可。

唯一的主机表可能包含以下记录：持续时间，命中了多少页，下载的文件数，总带宽，会话放弃，唯一的cookie（不同的用户，可能在代理或防火墙后面）。

您正在计划什么样的净化时间表？

虽然永久保留所有数据是很不错的，尤其是对于您尚未想到的事情，但是您想要的绝大多数是在整理后的数据中-因此围绕该数据构建报告，并保留这些案例的原始数据您确实需要一些独特的东西。

无论如何，这些都是您必须使用键值存储（例如simpledb或bigtable）构建的所有东西。

Answer 3

我认为存储成本将是您最大的担忧。 即使您采用云计算路线，我也怀疑您是否能够管理该数量的数据的成本。 我的建议是将数据移至超低价存储，并部署可以有效处理该数据的解决方案。

例如，您可以将日志文件从服务器移动到具有巨大硬盘驱动器（和适当的备份解决方案）的本地计算机上，然后在本地运行可以分析数据的工具。 如果您可以处理该数据的一小部分，则日志解析器将非常有效。 您可以在本地运行数据库，但是即使优化查询也可能运行缓慢。

您可能考虑购买像WebLog Expert这样的日志分析工具来对这些文件进行操作。

Answer 4

我将看一下您的索引。 1000万行确实不算多。 如果您正在运行SQL Server '05或'08，则可以使用“显示实际执行计划”运行查询，并且它将建议您创建哪些索引以提高查询速度。

我遇到的KILLS查询性能的另一件事是使用错误的数据类型。 例如，如果您将日期时间作为字符串输入，并且必须在查询中进行转换。 那时您还可以喝咖啡或晚餐（这是Windows中DB性能计数器的默认登录时间）。

还可以根据分区（开发，企业，标准）的版本来实现分区。 因此，按日期进行分区，然后在某个时间范围内获取数据时，您只会查询相关数据。 我相信，如果您想使用分区，则SQL Server的开发版具有所有企业功能。 MySQL还允许分区，我们正在USB驱动器上运行150GB的数据库。 它按日期（我相信是日子）划分，我们通常只在上周查询。 其裂开。

免责声明：我不是DBA，但是这些是我们已经完成的事情，并且似乎运作良好。