ramblr

http://blog.tourb.us/archives/searching-with-solr/
John Munsch just posted about something I’ve been wanting to mention for a while now: replacing ferret with Solr for search.
These issues were discussed at the first RailsConf during Seth Fitzsimmon’s great Lucene Eye for the Ruby Guy talk. Seth mentioned Solr as perhaps the best choice for adding search to a large-scale rails deployment. We took a look when we got back from the conference and really liked what we saw. We wrote a Solr version of our own “acts_as_searchable”-like library, although if we were starting over today we’d probably use acts_as_solr.
Since we are both comfortable programming in Java, it was no problem building a version of our location-based searching for Solr. The whole thing is much faster than the ruby version of ferret that we were using and has been rock solid. It does chew up a fair amount of memory, and to be honest it has stretched our VPS hosting plan to its limits. But other than the occasional memory issue we have never needed to restart the Solr service.
In summary:
Solr Pros:
* Uses the stable and highly-optimized Lucene code base, which is used on many high-traffic sites
* Supports advanced features like configurable caching, replication, plugins and an admin interface
* Both Solr and lucene are under active development
* Easy to move the service to a beefier machine or a cluster if search becomes a bottleneck
Solr Cons:
* Requires java for deployment and for plugin development (although jruby might come into play here)
* Uses more memory than we’d like in our resource-constrained environments
* Running a separate process adds some operational overhead