代码之家 › 专栏 › 技术社区 › quantumSoup

图像缓存策略

hash-collision caching php

0

quantumSoup · 技术社区 · 15 年前

情景

我正在构建一个Web应用程序,可以在其中动态生成报告(基于从SQL数据库中检索到的信息)。这些报告将包含图表,这些图表也可以动态生成。因为这些图表包含敏感信息,所以使用第三方图表API(即:谷歌图表)是不可能的。

我正在使用php的gd扩展来生成这些图表。速度很慢。缓存是一种方式,但问题在于可能存在大量的图表;尽管我相信请求的大多数图表将是以前生成的图表。

图表是用数据和其他信息(大小、图表类型等)生成的。因为它们可以唯一地标识一个图表,所以我会根据这些信息给每个图表一个唯一的哈希并保存它。现在我可以计算一个新请求的图表的散列值,看看是否已经呈现了它。

问题是发生了碰撞。为了解决这个问题,我正在考虑在SQL表中保存哈希和数据的序列化形式。然后,如果缓存命中,我仍然会比较数据本身。

我设计得太过火了?(这是一个160位的哈希-sha1)
有更好的方法来处理这个吗?

3 回复 | 直到 15 年前

1

0

symcbean 15 年前

我正在使用php的gd扩展来生成这些图表。速度很慢。

我怀疑它不是GD,这是慢位。最可能的候选者是整理数据的处理(从数据库?)。在这种情况下,您可以从优化数据库模式/和/或使用预合并数据中获得显著的好处。

尽管您也可以考虑缓存查询输出,但是除非您在其他地方使用相同的数据,否则缓存图形图像可能会更简单。

问题是发生了碰撞。

过早的优化-不会发生。但是,如果您确实必须这样做,那么可以将用于生成图形的元数据拆分,并将其存储在单独的文件中(再次通过相同的哈希进行索引),然后在运行时进行比较。如果你成功地撞到了,我们马上给你买杯饮料。

我建议您看看jpgraph——它是一个非常好的软件,内置了缓存。

C.

2

0

Nebril 15 年前

最可能的情况是,如果散列数据长度小于160位,那么您是安全的。否则,如您所说,可能会发生碰撞,需要比较数据。

3

0

fire 15 年前

看一看 ChartDirector 我们在工作中使用它,它不依赖于gd库,应该更快。