Question

我有一个非常庞大的日志。（数百万行）

LogTable
-------
ID    
DATE   
BASEURL
QUERYSTRING
USER   
REFERRER  
USERAGENT
SERVER

我希望通过规范化数据来缩小此表。（纤细的尺寸）

我知道！我知道！日志应该是超快插入。另一方面，日志表非常庞大，维护计划变得越来越难看。所以我只关注像BASEURL，USER，SERVER和USERAGENT这样的高度重复的列。

现在，我知道日志记录必须仍然很快，所以我不想进行字符串比较，这导致了我的问题：

我可以依赖存储

binary_checksum(COLUMN_VALUE)

在LogTable中

，并在另一个表中保留COLUMN_VALUE与其校验和的映射？

在我的应用程序中，我会保留映射的缓存，因此我不需要为每个请求返回数据库服务器。（只有当我有一个新的校验和值时，我才需要插入Mapping表中。）

主要目标是能够在表上运行一些简单的分析查询，并在不完全磨损数据库（和我的应用程序）的情况下提取数据。

这是一个简单的查询，例如：

select 
   count(1)
,  [user] /* This is a checksum value, which I can lookup in my cache */
from
   LogTable
where date between @from and @to
group by [user]

你怎么看？这个校验和方法是否正常？

修改：

我的所有列都是varchar（2000）或更少。
我认为它还允许我更快地索引数据？（我会索引离线/转型副本）

Answer 1

除了这里关于过度思考日志存储场景的其他评论之外，您还应考虑对表进行分区（按日期），如果需要进行大量报告，请考虑将数据转换为另一种格式（维度化或汇总）报告。

例如，USERAGENT是（可能是雪花）维度的主要候选者，用替代整数替换长字符串。

在将日志表归档到任何永久存储（已转换成电路）后，您可以在日志表中保留最少的信息。

Answer 2

你的哈希冲突策略是什么？在仅65k条目之后，导致32位摘要的校验和具有50％的冲突概率。这是因为meet-in-the-middle碰撞。对于数百万行，您将具有非常高的哈希冲突概率。

使用binary_checksum（）表示URL或类似字符串的限制？

2 个答案: