【问题标题】:Cachekey generation from object state从对象状态生成缓存键
【发布时间】:2013-02-12 10:55:15
【问题描述】:

背景

我希望纯粹存储是否已执行查询。如果有,则应针对数据缓存(内部数据库,进程外)运行查询,否则应针对原始数据源(第 3 方外部 Web 服务)运行查询。这种缓存的动机是允许我们对该 API 进行的调用次数是有限的,而且我们可能会多次执行相同的查询。

在对原始数据源运行一次查询后,它只会在后续调用中对缓存的数据源运行。注意:为了简单起见,我故意忽略了缓存过期的问题。

鉴于每个查询可能包含许多参数(目前只有 5 个),并且参数的数量可能会随着时间的推移而增加,我不想使用类似 "WHERE x AND y AND z AND a AND b AND c AND d AND...".

为此,我只想知道这个确切的查询之前是否已经运行过,如果有,我会假设它的数据已经在缓存的数据存储中可用(尽管格式不同)。我认为某种形式的“cachekey”可以识别具有相同参数和关联值的任何查询对我有用。每次我尝试查询时,我都会根据查询对象的状态生成缓存键,并检查缓存键存储以确定查询是否曾经运行过。 cachekey 存储需要促进快速查找。

问题

我发现很难弄清楚这个缓存键应该是什么样子以及如何生成它。到目前为止,我倾向于

  1. 有趣的查询参数及其值连接到一个字节数组中
  2. 从字节数组创建一个 MD5
  3. 将此缓存键存储在二进制 (16) 索引列中

出于争论的目的,我愿意接受可能会导致缓存报告缓存数据可用于查询的一些冲突,但假设可能性很小(尽管如何小,我不能 100% 确定)。

上述用于创建缓存键的解决方案是否合理,或者我应该考虑其他任何方法吗?

【问题讨论】:

    标签: caching hash


    【解决方案1】:

    您的潜在解决方案正是我过去所做的,并且效果很好。我实际上将方法/调用名称连接起来,然后将所有参数值组合成一个字符串,然后在其上运行 MD5 并获得我的缓存密钥。

    我不明白怎么可能发生冲突。如果更改参数值,缓存键会不同,这可能会带回不同的数据。

    (说了这么多,我不确定你所说的“有趣”参数是什么意思。)

    【讨论】:

    • MD5 有碰撞问题,但它们(取决于输入)很少见。根据我的阅读,如果输入是结构化的,那么发生冲突的可能性就更高。 mathstat.dal.ca/~selinger/md5collisionlinks.org/?p=6
    • 我认为还有其他的哈希算法效果更好。您总是可以将每个函数中的一个参数命名为疯狂的散列散列。哈哈。 =)
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-05-20
    • 2021-03-15
    • 2018-05-21
    • 1970-01-01
    • 2013-02-18
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多