Preferred search solution for Rails 4 apps?

[Chris McCann]

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

[Ylan Segal]

Chris,

The last time I needed to implement search was 3 years ago, on rails 3.2. At the time I went with solr because

1) I was hosting on heroku and it was very easy to use an add-on
2) It was trivial to use foreman locally to manage the local processes without worrying about the details
3) It has a really simple DSL for the models to define what is searchable, even if you need to do some data manipulation when sending the data over to solr
4) The DSL for performing searches was equally nice. As I recall the results where handled easily by the rest of the app as any ActiveRecord::Relation. I remember having to add a kaminari-solr add on, but was really trivial to get it working.

Overall I was really happy with the performance in production.

I hope this helps,

—
Ylan Segal
yl...@segal-family.com

> --
> --
> SD Ruby mailing list
> sdr...@googlegroups.com
> 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 sdruby+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Chris McCann]

Ylan,

As always, a very concise, cogent answer -- thanks very much!

Chris

You received this message because you are subscribed to a topic in the Google Groups "SD Ruby" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sdruby/jJ68Z9EUCS8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sdruby+un...@googlegroups.com.

[Kevin English]

Hey Chris,

  I've used elasticsearch recently and was pleased with it. Once setup, elasticsearch-model makes it easy to build and customize the indeces. The docs for both elasticsearch and elasticsearch-model are quite good. If you need to get down and write custom elasticsearch queries using their query dsl, using elasticsearch-model with rails console is good way to get in and play around with it. You simple pass ruby hashes into the 'search' method and it hits elasticsearch bringing back your results. The elasticsearch search DSL has a small learning curve but if you aren't doing anything too custom, you might get by with just customizing the index and using the standard query method.

  I've used Sunspot/Solr a few years back. If I had to choose again, I would still go with elasticsearch.

All the best, 

Kevin English 

--

[Guyren Howe]

On May 14, 2015, at 17:02 , Chris McCann <testf...@gmail.com> wrote:

I'd like some opinions on what folks are using for search in their Rails apps currently as I need to implement one.

Worth noting that Postgres has a surprisingly full-featured text search capability built in, that includes simile search, stemming (finding "ran" when you searched for "run", for example), ranking, fuzzy search and other features. Nothing like having it all in one place and less to set up.

<http://blog.lostpropertyhq.com/postgres-full-text-search-is-good-enough/>

[Kevin English]

That's an excellent point Guyren!

There are the textacular and pg_search gems if you want more sugar in your ActiveRecord. Each has a different approach. I used textacular on a project a few years ago for a project we were hosting on Heroku.

Some of us are on projects that use Mysql so we don't have the luxury of taking advantage of Postgres :~(

Kevin

[Nick Zadrozny]

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.

--

--
SD Ruby mailing list
sdr...@googlegroups.com
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 sdruby+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nick Zadrozny

[Patrick Crowley]

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

Graffletopia

http://www.graffletopia.com

These apps have pretty basic search needs, but Solr works like a champ.

Cinema Treasures

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

[Richard Bishop]

Assuming your search needs are pretty simple, I'll echo using Postgres as well if you're already using Postgres. Otherwise I've enjoyed using Elasticsearch recently on an app that had really robust search needs.