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

Question

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

然后我们可以查询这个以获得关于命中，使用等的简单统计数据。将它链接到错误日志数据库和性能计数器数据库以将使用情况与错误进行比较等时也很好。

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

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

任何人都可以建议我们可以用于此数据的任何替代数据库对这些日志更有效吗？我对Google的BigTable或亚马逊的SimbleDB的任何体验都特别感兴趣。

这些是否适合报告查询？ COUNTs，GROUP BYs，PIVOTs？

Answer 1

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

1. 在大多数情况下，我们IIS日志无法直接提供有用信息，我们需要解析它以获取统计信息。
2. 此外，在大多数情况下，IIS日志不必在数据库中准备好进行查询。

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

Answer 2

您多久更新一次索引？您正在执行哪些类型的数据查询？

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

就像一个页面命中表可能每天都有一个记录该页面被击中的次数 - 这样你就不必对每个查询进行全表扫描，你只需点击页面命中表。

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

您计划采用何种清洗计划？

尽管永远保留所有数据是件好事，特别是对于你还没有想到的事情，你想要的绝大多数都是整理的数据 - 所以围绕它建立你的报告，并保留原始数据对于那些你需要一些独特的东西。

无论如何，这是您必须使用键值存储（如simpledb或bigtable）构建的所有内容。

Answer 3

我认为存储成本将是您最关心的问题。即使你走了云路线，我怀疑你能够管理这些数据的成本。我的建议是将数据转移到超廉价的存储，并部署一个能够以有效的方式对该数据进行操作的解决方案。

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

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

Answer 4

我要看看你的索引。 10M行真的没那么多。如果您运行的是SQL Server '05或'08，则可以使用“显示实际执行计划”运行查询，并建议您应创建哪些索引以提高查询速度。

我遇到KILLS查询性能的另一件事是使用了错误的数据类型。例如，如果您将datetime作为字符串放入，并且必须在查询中执行CONVERT。你可能会在那时得到咖啡或晚餐（这是Windows性能计数器登录的默认btw）。

还可以根据版本（开发，企业，标准）实现分区。因此按日期划分，然后当您获得特定时间范围内的数据时，您只需要查询相关数据。我相信如果你想使用分区，SQL服务器的开发版本具有所有的企业功能。 MySQL还允许分区，我们在USB驱动器上运行150GB的数据库。它按日期划分（我相信的日子），我们通常只在上周查询。它的摇摇欲坠。

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