To add to what Nick said, I’ve had great experiences using Solr and Websolr.
All of my current production apps use this combination. iCalShare http://www.icalshare.com <http://www.icalshare.com/> Graffletopia http://www.graffletopia.com <http://www.graffletopia.com/> These apps have pretty basic search needs, but Solr works like a champ. Cinema Treasures http://www.cinematreasures.org <http://www.cinematreasures.org/> This app has a pretty complex Solr implementation. At the core, the site is a massive database of movie theaters around the world. When you browse the site, we need to pull in a huge amount of data from each theater record and a ton of related models — and then we also need to facet that data and segment it geo-spatially. So, instead of overloading the app with DB queries, we’re actually using Solr as a virtual database cache. So, of course, when you search the site, you’re hitting Solr… but you’re also using Solr when you just browse the site and explore movie theaters in different countries, states, cities, neighborhoods, etc. But, that said, Elasticsearch looks pretty sweet, so I’ll give that serious consideration for my next app. (And, by the way, for those who haven’t met Nick, he’s an SD Ruby alumni and a great example of the awesome folks we’ve had and continue to have in the group!) -- Patrick > On May 14, 2015, at 8:25 pm, Nick Zadrozny <[email protected]> wrote: > > So… I kinda run Solr and Elasticsearch as a service. (Websolr and Bonsai, you > can find them on Heroku.) I've fielded a bunch of questions about all of > those services, and even did a talk about Sunspot at SDRuby waaaay back in > the day. > > My recommendation these days: if you need to ask, go with Elasticsearch. > > It's built on Lucene, which is where most of the search magic is happening > under the hood. It has good client libraries and integrations. I prefer > slinging hashes in elasticsearch-ruby to Sunspot's DSL. Elasticsearch has the > easiest learning curve, especially relative to its power. And its superior > usability means you're going to end up getting more out of the system for > much less effort by virtue of having more easily accessible options and APIs > to work with. > > There are good reasons to use Solr. It's a very close second in my book. It's > a little more rigid, more solid-feeling, a little more aggressively tuned for > performance. It does less "magic" which can be nice when you're at scale, > where more moving parts can cause catastrophic cascading failure. It's an > Apache project, which means open governance, rather than a corporate > gatekeeper, if that's important to you. (It is for some.) > > Postgres is wonderful in general, and its search is pretty adequate. Lucene > as a rule is going to be a lot better optimized in all cases, and definitely > has a lot more functionality. > > I could probably go on. > > > On Thu, May 14, 2015 at 7:02 PM, Chris McCann <[email protected] > <mailto:[email protected]>> wrote: > I'd like some opinions on what folks are using for search in their Rails apps > currently as I need to implement one. > > Over the years I've seen: > > - solr > - thinking_sphinx > - elastic search > - others whose names I can't remember > > If you are currently employing an app-wide search tool in a Rails app, what > is it? Why do you like it? How long have you used it? > > Thanks! > > Chris McCann > > -- > -- > SD Ruby mailing list > [email protected] <mailto:[email protected]> > http://groups.google.com/group/sdruby <http://groups.google.com/group/sdruby> > --- > You received this message because you are subscribed to the Google Groups "SD > Ruby" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > -- > Nick Zadrozny > > -- > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby <http://groups.google.com/group/sdruby> > --- > You received this message because you are subscribed to the Google Groups "SD > Ruby" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
