我们已经运行了一些脚本，它们使用 LogParser 将 IIS 日志转储到 SQL Server 数据库中。
然后我们可以查询它以获取有关命中、使用等的简单统计信息。将其链接到错误日志数据库和性能计数器数据库以比较使用与错误等时也很好。
仅在一个系统上实现了这一点，在过去的 2-3 周内，我们已经拥有一个 5GB 的数据库，其中包含大约 1000 万条记录。
这使得对该数据库的任何查询都非常缓慢，如果我们继续按原样记录，无疑会导致存储问题。
任何人都可以建议我们可以用于这些数据的任何替代数据库，这些数据库对此类日志更有效吗？我对 Google 的 BigTable 或 Amazon 的 SimbleDB 的任何体验都特别感兴趣。
这些中的任何一个都适合报告查询吗？计数、分组依据、数据透视？
我之前也遇到过类似的问题。由于日志文件增长如此之快，我开始思考是否适合使用数据库来记录 IIS 日志。您可能需要考虑以下两点：
建议将所有日志保持原样保存在文件中，但将每周或每月的统计信息（定期处理）存储在数据库中，以便您可以随时使用这些基本数据。
我会看看你的索引。10M 行真的不算多。如果您正在运行 SQL Server '05 或 '08，您可以使用“显示实际执行计划”运行查询，它会建议您应该创建哪些索引以提高该查询的速度。
我遇到的另一件事是 KILLS 查询性能使用了错误的数据类型。例如，如果您将日期时间作为字符串输入，并且必须在查询中执行 CONVERT。那时您不妨喝杯咖啡或晚餐（顺便说一句，这是 Windows 中数据库性能计数器登录的默认设置）。
还取决于您可以实施分区的版本（开发、企业、标准）。因此，按日期进行分区，然后当您获取某个时间范围内的数据时，您只会查询相关数据。如果您想使用分区，我相信 SQL Server 的开发版本具有所有企业功能。MySQL 还允许分区，我们在 USB 驱动器上运行 150GB 的数据库。它按日期（我相信是天）划分，我们通常只在上周查询。它的自由分裂。
免责声明：我不是 DBA，但这些是我们已经做过的事情，并且似乎运作良好。
您多久更新一次索引？您正在对数据执行什么样的查询？
也许您可以在每天结束时执行例行的数据整理以加快其他查询？（使用此整理信息创建新表）
就像页面命中表可能每天都会记录该页面被命中的次数 - 这样您就不必对每个查询进行全表扫描，您只需点击页面命中表。
一个唯一的主机表可能记录了逗留时间、他们点击了多少页、下载的文件数、总带宽、会话放弃、唯一的 cookie（不同的用户，可能在代理或防火墙后面）。
如果有的话，您计划采取什么样的清除计划？
虽然永久保留所有这些数据是件好事，尤其是对于您尚未想到的事情，但您想要的绝大多数内容都在整理的数据中 - 所以围绕它构建您的报告，并保留这些案例的原始数据你真的需要一些独特的东西。
无论如何，这都是您必须使用键值存储（如 simpledb 或 bigtable）构建的所有内容。
我认为存储成本将是您最关心的问题。即使你走云路线，我怀疑你是否能够管理这么多数据的成本。我的建议是将数据移动到超便宜的存储中，并部署一个可以有效地对这些数据进行操作的解决方案。
例如，您可以将日志文件从服务器移动到具有巨大硬盘驱动器（和适当的备份解决方案）的本地计算机，然后在本地运行可以分析数据的工具。如果您可以针对该数据的一小部分进行操作，那么日志解析器就会很有效。您可以在本地运行数据库，但即使是优化的查询也可能运行缓慢。
您可以考虑购买像WebLog Expert这样的日志分析工具来对这些文件进行操作。