数据库 – 远程服务缓存策略;我应该考虑什么?

前端之家收集整理的这篇文章主要介绍了数据库 – 远程服务缓存策略;我应该考虑什么?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我的网络应用程序包含从我无法控制的外部API收集的数据.我每小时限制大约20,000个API请求.我的数据库中有大约250,000个项目.这些项中的每一项本质上都是缓存版本.考虑更新1个项目的缓存需要1个请求.显然,在这些情况下,不可能拥有完美的最新缓存.那么,在开发缓存数据的策略时,我应该考虑哪些事情.这些是我想到的事情,但我希望有人有一些我没有想过的好主意.

>自项目创建以来的时间(更少的时间意味着更重要)
>特定项目的“喜欢”数量(可能意味着被查看的概率更高)
>自上次更新以来的时间

更多细节:项目是照片.每张照片都属于一个活动.当前发生的事件更像是客户端查看(因此它们应该优先考虑).虽然我现在只有250K项目在数据库中,但这个数字增长相当快(不会很长,直到达到100万标记,可能是5个月).

解决方法

http://instagram.com/developer/realtime/会有用吗?当有新的(可能更新的?)图像供您查看时,Instagram似乎愿意POST到您的服务器.这会诀窍吗?

否则,我认为你的问题听起来很像任何搜索引擎的问题 – 你见过Wikipedia on crawler selection criteria吗?您正在处理网页抓取工具所面临的许多问题:抓取内容,抓取频率以及如何避免向单个网站发出过多请求.您也可以查看open-source crawlers(在同一页面上),了解您可以学习的代码和算法.

无论如何,要抛弃一些关于爬行标准的想法:

>更新经常更改的内容.因此,如果一个项目在最近五次更新中没有改变,那么也许您可以假设它不会经常更改并更新它.
>为每个图像创建一个分数,并更新分数最高的分数.或者最低分(取决于您使用的分数类型).这与LilyPond对typeset music使用的内容类似.有些方法可以为这样的分数创建输入:

>图像更新和需要记录的机会的统计模型.
>每个图像的重要性分数,使用图像的新近度或其事件的货币等.

>更新经常查看的内容.
>更新包含许多视图的内容.
>时间会影响图像更新的概率吗?您提到较新的图像更重要,但旧图像的更改概率又如何呢?减慢检查旧图像的频率.
>分配部分请求以缓慢更新所有内容,并拆分其他部分以同时处理来自多个不同算法的结果.因此,例如,有以下(数字仅用于显示/示例 – 我只是将它们从帽子中拉出来):

>每小时5,000个请求通过数据库的完整内容进行搅拌(前提是它们自上次爬行程序以来未被更新)> 2,500个请求处理新图像(您提到的更重要)> 2,500个请求处理当前事件的图像> 2,500个请求处理前15,000个查看次数最多的图像(只要该图像的最后5次检查发生变化,否则按递减计划检查)> 2,500个请求处理至少已查看过的图像>总计:每小时15,000个请求.

猜你在找的MsSQL相关文章