On Fri, Mar 11, 2011 at 5:26 PM, Yonik Seeley <yo...@lucidimagination.com> wrote: > That's an apples to oranges comparison - lucene is a library and solr > is a server.
I partially agree ;-) Lucene is a library and Solr is an http server wrapper-plus around Lucene. Solr also adds (all sorts of great) significant functionality on top of Lucene, > You can't really "run" lucene on it's own... so some of your > application code will do stuff that solr probably already does. It depends. For the functionality that is implemented by Lucene, and Solr is just passing through to Lucene (like many queries), you could test this sub-set of queries (most Solr application have some of these; some have many of these). Yes, this would only be comparing these queries, and would not be testing the functionality that Solr is providing (faceting, etc). And certainly if this part of the application is the part that has performance problems, you would want to do this. So it would be comparing oranges-to-oranges. Actually oranges-to-(oranges+XML+network) (when remote). > So performance-wise it's less about solr vs lucene and more about solr > vs your potential custom application. On that basis, Solr can be > either slower or faster. It depends on how much of the Solr-added functionality the application uses. If it primarily uses functionality that passes through to Lucene (is using Solr for http access, language independence, other reasons) then asking the question of Solr vs Lucene is valid. Or asking this question for the subset of the application that has this kind of profile is also valid. There _will_ be situations where the developer will not be willing to take the performance hit of Solr. Of course, they will lose the great added functionality of Solr, against which they must balance their requirements and/or the cost of reimplementing the functionality (as Yonik points out). Thanks, Glen :-) PS. Some (old) Lucene search performance stuff (100s of GB data; millions of documents, up to 8192 parallel query threads): http://zzzoot.blogspot.com/2008/06/lucene-concurrent-search-performance.html http://zzzoot.blogspot.com/2008/06/simultaneous-threaded-query-lucene.html On Fri, Mar 11, 2011 at 5:26 PM, Yonik Seeley <yo...@lucidimagination.com> wrote: > On Fri, Mar 11, 2011 at 5:07 PM, sivaram <yogendra.bopp...@gmail.com> wrote: >> So you are saying that it all depends on how we setup the Solr? In a >> performance perspective, does Solr lags behind Lucene because it's a layer >> above Lucene to our application or will it have a better indexing and >> searching techniques than Lucene? (when talking about really big indexes) > > That's an apples to oranges comparison - lucene is a library and solr > is a server. > You can't really "run" lucene on it's own... so some of your > application code will do stuff that solr probably already does. > So performance-wise it's less about solr vs lucene and more about solr > vs your potential custom application. On that basis, Solr can be > either slower or faster. > > If you have really specialized needs, you can always gain speed by > dropping down to a lower level. The decision to be made is if your > needs are that special, what your requirements are, and if the extra > development cost is worth it. If you're doing something really > different, Solr could be the completely wrong solution. > > It's the same with databases... you could *always* get better > performance by putting in enough effort and doing custom code rather > than using an off the shelf product like MySQL. Just like you could > always get better performance dropping from Java to C, from C to > assembler, and moving from general purpose processors to ASICs or > GPUs, etc. > > I guess this is a very long winded way of saying "it depends" ;-) > > -Yonik > http://lucidimagination.com > -- -
