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

我有一个非常巨大的日志。（百万行）使用binary_checksum（）来表示URL或类似字符串的限制？

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

我想通过标准化数据来减少这张表。（苗条的尺寸）

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

现在，我知道日志仍然必须要快，所以我不想做字符串比较，这导致我的问题：

我可以依靠的LogTable存储

binary_checksum(COLUMN_VALUE)

，并保持COLUMN_VALUE到其独立表中的校验和映射？

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

主要目标是能够在表上运行一些简单的分析查询，以及不需要提取数据彻底研磨数据库（和我的应用程序）停下来。

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

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）或更小。
我假设它也允许我更快地索引数据？（我会索引离线/转换副本）

来源

2009-07-20 Jeff Meatball Yang

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

来源

2009-07-20 21:48:55

我想你间接地回答了我的问题。只要我对每个值都有独特的哈希值（我敢肯定，对于每一列我都要小于10k的独特值），它应该没问题。 ... 很明显，这样一个简单的散列很脆弱。 – 2009-07-20 22:09:38

您可以尝试使用MD5，速度相当快，128位不易碰撞。 – 2009-07-20 22:23:53

除了这里提到的其他有关过度使用日志存储场景的注释，您应该考虑按照日期对表进行分区，并且如果需要大量报告，请考虑将数据转换为其他格式（无论是尺寸还是汇总）进行报告。

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

将日志表中的最小信息归档到任何永久存储（转化为电位）后，您可以保留最少的信息由需求决定。

来源

2009-07-20 23:25:03

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

回答

相关问题