SolrJ用于控制Solr/Luce与直接休息电话 [英] SolrJ used to control Solr/Luce vs. Straight Rest Calls

问题描述

我们正在为面向公众的REST应用程序运行TomCat servlet(Railo).我已经开始实现SolrJ来控制独立的Solr集群.查询工作正常，但是我只是想用流程而不是仅仅使用Solr提供的直接HTTP接口.我以为使用SolrJ会有一些性能上的好处，这就是为什么我开始实现它，但是从我在响应时间中所看到和看到的结果来看，我认为我在该帐户上错了(?).

We are running a TomCat servlet (Railo) for a public facing REST application. I've started implementing SolrJ to control a standalone Solr cluster. Queries are working well, but I'm scratching my head over the flow vs. just using the straight HTTP interface Solr provides. I thought there was some performance benefit to using SolrJ which is why I started implementing it, but from what I'm reading and seeing in response times, I think I was wrong on that account (?).

使用SolrJ相对于操作和返回Solr的JSON响应是否有真正的优势?我当然可以在不向客户端返回JSON/XML的Java应用程序中使用SolrJ.

Is there any real advantage to using SolrJ vs. just manipulating and returning the JSON response from Solr? I certainly get using SolrJ for a java application that is not returning JSON/XML to the client.

推荐答案

我不知道有任何声称可以提高SolrJ的性能.大多数情况下，它被设计为一种易于使用的与Solr交互的方式. SolrJ可能会阻止您摆脱Solr界面允许的某些性能下降的事情，但是对于简单的索引搜索，我认为它不会显着提高速度.

I'm not aware of any claims of improved performance with SolrJ. It's designed, mostly, to be an easy-to-use way to interface with Solr. SolrJ might prevent you getting away with some things the Solr interface allows that would perform very poorly, but for simple searches on the index, I don't see it generating a signficant speed improvement.

我确实看到了SolrJ的一项性能优势:

One performance benefit from SolrJ that I do see: ConcurrentUpdateSolrServer looks like a performant way to handle updates, particularly with large batches of updates. I would expect it to perform much better, especially with heavy loads, than the naive implementation of just establishing a connection and sending updates one at a time.

这篇关于SolrJ用于控制Solr/Luce与直接休息电话的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！