ID,body_text,date,num_upVotes,num_downVotes
在我的应用程序中,创建了一个带有一些整数ID和一些body_text(最多500个字符)的文档.日期设置为输入时间,num_upVotes和num_downVotes从0开始.
我的应用程序为用户提供了上述内容的upVote和downVote的能力,以及我想在Solr而不仅仅是数据库中跟踪这一点的原因是我希望能够在我的搜索中考虑upVotes和downVotes的数量.
这是一个问题,因为您不能简单地更新solr文档(即up_Votes的增量数),并且您必须替换整个文档,这可能是相当低效的,因为它需要命中我的数据库以再次获取所有相关数据.
我意识到解决方案可能需要不同的数据布局,或者可能需要多个索引(尽管我不知道你是否可以在solr内核中查询/得分).
有人能提供任何有关如何解决这个问题的建议吗?
解决方法 我在类似问题中使用的解决方案是在数据库中更新该信息,并使用自上次更新后修改的文档每十分钟执行一次SolR更新/插入.还有每天晚上,当我没有太多流量时,我会做索引优化.
每次导入后,我在SolR配置中设置了一些预热查询.
在我的SolR索引中,我有大约150万个文档,每个文档有24个字段,整个文档大约有2000个字符.
我每隔10分钟更新一次约500个文档的索引(没有优化索引),我做了大约50个热门查询,包括最常见的方面,大多数使用过滤查询和自由文本搜索.
我不会对性能产生负面影响. (至少它是不可见的) – 我的查询在0.1秒内平均运行. (在每10分钟更新一次之前,平均查询为0.09秒)
后期编辑:
在此更新期间我没有遇到任何问题.我总是从数据库中获取文档并使用Unique键将它们插入SolR.如果文档存在于SolR中,它将被替换(这就是我所说的更新).
更新SolR永远不会超过3分钟.实际上我每次更新后都会休息10分钟.所以我开始更新索引,等待它完成,然后再等10分钟重新开始.
我没看过整个晚上的表现,但对我来说这并不重要,因为我希望在用户访问高峰期间获得新的数据信息.
总结以上是内存溢出为你收集整理的搜索 – Solr文档的频繁更新 – 效率/可伸缩性问题全部内容,希望文章能够帮你解决搜索 – Solr文档的频繁更新 – 效率/可伸缩性问题所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)