0

我打算log4net在一个新的网络项目中使用。以我的经验，我看到日志表可以有多大，我也注意到错误或异常重复出现。例如，我刚刚查询了一个包含超过 132.000 条记录的日志表，我使用 distinct 发现只有 2.500 条记录是唯一的（~2%），其他的（~98%）只是重复的。所以，我想出了这个想法来改进日志记录。

有几个新列：counter和updated_dt，每次尝试插入相同的记录时都会更新。

如果要跟踪导致异常的用户，需要创建一个user_log或log_user表，来映射NN关系。

创建此模型可能会使系统尝试比较所有这些长文本时变得缓慢且效率低下......这里的技巧，我们还应该有一个hash column16 或 32 的二进制文件，对消息和异常进行哈希处理，并在其上配置索引. 我们可以HASHBYTES用来帮助我们。我不是 DB 方面的专家，但我认为这样可以更快地找到类似记录。并且由于散列不能保证唯一性，这将有助于更快地对那些相似的记录进行本地化，然后直接通过消息或异常进行比较，以确保它们是唯一的。

这是一个理论/实际的解决方案，但它会起作用还是带来更多的复杂性？我遗漏了哪些方面或需要考虑哪些其他因素？触发器将完成插入或更新的工作，但触发器是最好的方法吗？

4

2 回答 2

1

是的，你可以这么做。这是个好主意，而且会奏效。从多个线程或进程插入时要注意并发问题。您可能需要详细研究锁定。您应该查看锁定提示（在您的情况下UPDLOCK, HOLDLOCK, ROWLOCK）和MERGE语句。它们可用于维护维度表。

作为替代方案，您可以登录到文件并压缩它。典型的压缩算法非常擅长消除这种类型的精确冗余。

于 2012-10-19T21:40:38.867 回答
1

老实说，我不会太在意包含 132,000 条记录的日志表，我已经在日志表中看到了数百万甚至数十亿条记录。如果您每隔几分钟就注销 132,000 条记录，那么您可能需要将其调低一点。

我认为这个想法很有趣，但这是我的主要担忧：

  • 这样做实际上可能会损害应用程序的性能。Log4Net ADO.NET appender 是同步的。这意味着如果你让你的 INSERT 变得比它需要的更复杂（也就是查找数据是否已经存在，计算哈希码等），你将阻塞调用日志的线程。这不好！您可以将这种写作修复到某种临时表上，并通过工作或其他东西在带外进行，但现在您已经为可能更简单的事情创建了一堆移动部件。
  • 时间可能最好花在做其他事情上。存储很便宜，开发人员的时间也很便宜，并且日志不需要非常快地访问，因此非规范化模型应该没问题。

想法？

于 2012-10-19T22:28:39.297 回答