图片缓存策略
场景
我正在构建一个 Web 应用程序，可以在其中动态生成报告（基于从 SQL 数据库检索的信息）。这些报告将包含图表，也可以即时生成。由于这些图表包含敏感信息，因此不可能使用第三方图表 API（即：Google Charts）。
问题
我正在使用 PHP 的 GD 扩展来生成这些图表。这是相当慢的。缓存是可行的方法，但问题是可能的图表数量巨大；尽管我相信大多数要求的图表都是以前生成的。
部分解决方案
图表是使用数据和其他信息（大小、图表类型等）生成的。因为这些可以唯一地标识一个图表，所以我根据这些信息为每个图表赋予一个唯一的哈希值并保存它。现在我可以计算新请求的图表的哈希值，并查看是否已经渲染了它。
这样做的问题是发生碰撞。为了解决这个问题，我正在考虑将哈希值和数据的序列化形式保存在 SQL 表中。然后，如果我有缓存命中，我仍然会比较数据本身。
我对此过度设计了吗？ （这是一个 160 位哈希 - SHA1）
有更好的方法来处理这个问题吗？
The Scenario
I am building a web application where reports can be generated on the fly (based on information retrieved from an SQL database). These reports will contain charts, which can also be generated on the fly. Because these charts contain sensitive information, using a 3rd party chart API (ie: Google Charts) is out of the question.
The Problem
I am using PHP's GD extension to generate these charts. It is pretty slow. Caching is the way to go, but the problem is there is a huge number of possible charts; although I believe the majority of the charts requested will be ones that have been generated before.
Partial Solution
Charts are generated with data and other information (size, chart type, etc.). Because these can uniquely identify a chart, I give each chart a unique hash based on this information and save it. Now I can compute the hash for a newly requested chart and see if I already have it rendered.
The problem with this is the event of a collision. To get around that, I am thinking of saving the hash and a serialized form of the data in an SQL table. Then if I have a cache hit, I'll still compare the data itself.
I am over-engineering this? (It's a 160-bit hash - SHA1)
Is there a better way to handle this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我怀疑不是GD，慢一点。最有可能的候选者是整理数据的处理（来自数据库？）。在这种情况下，您可能会从优化数据库模式/和/或使用预合并数据中获得显着的好处。
尽管您也可能考虑缓存查询输出，但除非您在其他地方使用相同的数据，否则缓存图形图像可能更简单。
过早的优化——这不会发生。但如果您确实必须这样做，请将用于生成图形的元数据分开并将其存储在单独的文件中（再次通过相同的哈希进行索引） - 然后在运行时进行比较。如果您成功发生碰撞，我们将进行快速检查并请您喝一杯。
我建议看一下 jpgraph - 这是一个优秀的软件，并且内置缓存。
C.
I suspect that its not GD which is the slow bit. The most likely candidate is the processing of collating the data (from a database?). In which case you may get significant benefits from optimizing the database schema / and/or using pre-consolidated data.
Although you might also consider caching the query output, but unless you're using the same data elsewhere it's probably simpler to cache the graph images.
Premature optimization - it's not going to happen. But if you really must, split the meta-data you are using to generate the graph and store it in a seperate file (again indexed via the same hash) - then compare it at runtime. If you manage to get a collision, we'll have a whip-round and buy you a drink.
I would recommend having a look at jpgraph - which is an excellent bit of software and has caching built-in.
C.
如果您的散列数据长度小于 160 位，那么您很可能是安全的。否则，就像你说的，可能会发生冲突，需要比较数据。
Most probably if your hashed data length is less than 160 bit, you're safe. Otherwise, like you say, collisions may occur and comparing data is necessary.
看看ChartDirector我们在工作中使用它，它不依赖GD库，应该更快。
Take a look at ChartDirector we use it at work and it doesn't rely on the GD library, should be faster.