It is like deciding between a disk drive and a file server. Solr and Lucene are different kinds of things.
wunder On Feb 12, 2013, at 12:26 PM, Glen Newton wrote: > Is there a page on the wiki that points out the use cases (or the > features) that are best suited for Lucene adoption, and those best > suited for SOLR adoption? > > -Glen > > On Tue, Feb 12, 2013 at 3:11 PM, Shawn Heisey <s...@elyograg.org> wrote: >> On 2/12/2013 11:19 AM, JohnRodey wrote: >>> >>> So I have had a fair amount of experience using Solr. However on a >>> separate >>> project we are considering just using Lucene directly, which I have never >>> done. I am trying to avoid finding out late that Lucene doesn't offer >>> what >>> we need and being like "aw snap, it doesn't support geospatial" (or >>> highlighting, or dynamic fields, or etc...). I am more curious about core >>> index and search features, and not as much with sharding, cloud features, >>> different client languages and so on. >> >> >> Because Solr is written using the Lucene API, if you want to use Lucene, you >> can do anything Solr can, plus plenty of things that Solr can't -- but for >> many of those, you'd have to write the code yourself. That's the key >> difference -- with Solr, a HUGE amount of coding is already done for you, >> you just have to put a few easy-to-debug client API calls in your code. >> >> From my perspective as a user with some Java coding ability but not any true >> experience with large-scale development: If your development team is ready >> and capable of writing Lucene code, then it would be better to use Solr >> instead, and if there's something you need that Solr can't do, put your >> development team to work writing the required plugin. They would likely >> spend far less time doing that than writing an entire search system using >> Lucene. >> >> Thanks, >> Shawn >> > > > > -- > - > http://zzzoot.blogspot.com/ > - -- Walter Underwood wun...@wunderwood.org
