>自项目创建以来的时间(更少的时间意味着更重要)
>特定项目的“喜欢”数量(可能意味着被查看的概率更高)
>自上次更新以来的时间
更多细节：项目是照片.每张照片都属于一个活动.当前发生的事件更像是客户端查看(因此它们应该优先考虑).虽然我现在只有250K项目在数据库中,但这个数字增长相当快(不会很长,直到达到100万标记,可能是5个月).
解决方法
否则,我认为你的问题听起来很像任何搜索引擎的问题 – 你见过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个请求.
