Comment by fusiongyro | Hacker News Reader

Comment by fusiongyro | Hacker News Reader

Parent Full thread

I've used Solr in production for about five years. All of the pain with Solr is up-front. Once you get it running, set up your schemas and you have your indexes built, it just hums along, doing its job and being obscenely fast.

Trying out Elasticsearch, my experience was that it really wants to be run in a cluster, but it also loses data pretty easily. I had more issues with it crashing and it's generally a lot hungrier for memory.

Both have non-obvious shortcomings. Solr's schema will make you believe that it likes deeply nested JSON documents. False! It actually wants pretty flat "documents" without nesting (you /can/ nest, but it usually doesn't do what you want without some extra legwork). ES will have you believe that it supports lots of query types and they'll all perform great on semi-structured data. My experience was that it was difficult to predict performance, but that generally the fancier the query the worse it would be.

Solr's querying functionality is not extremely powerful (though they "helpfully" made it offensively complex with different query parsers and stuff) but performance has always been excellent for me.

IMO, if you don't need clustering, Solr is definitely better. A cranky but robust piece of engineering from before scaling was everything. ES has better documentation, a better "getting started" story, and is generally a lot more user-friendly. Aphyr's posts about it have made me wary of using it without a re-indexing story.

I haven't tried Solr's scaling stuff because I haven't needed it, but I would expect it to be in pretty rough shape compared to ES because it's not a primary use case for Solr and it is for ES.

We use SolrCloud cluster where I work. The initial setup is rather daunting and involves reading up on Zookeeper, and Solr terminology on Collections, Cores, Shards and Nodes. But once the reading is done, clustering is effortless to execute. Solr 5 and 6 have a robust REST API for managing Collections.

The new SQL / Parallel Streaming has also made querying multiple collections a cinch.

What's daunting about running Zookeeper?

Most of the problems that I have had are with the ZK clients and not the server. As long as you follow the operational documentation (there are a few basic rules) it hums along nicely. We have a few clusters with Kafka and have a decent process in Chef:

https://github.com/bloomberg/zookeeper-cookbook

Compared to ES documentation on clustering it's a lot of work. ES merely requires a seed host to connect to and will gossip the rest of the cluster. No external service needed.

On the other hand, it's had its share of improperly handled split brain scenarios. I still think it has problems with partial split brain (where A and B can't talk, but C can talk to both of them).

I may not have phrased it correctly. It was daunting to setup the first time as I had no idea (then) about running clusters. Most people graduate from running a single Solr Node to a (generally) 3 node cluster. Getting a running Zookeeper ensemble is just part of that process.

Thanks for sharing the cookbook :) . Do you use Zookeeper for anything other than Kafka?

Because I'd rather run Consul?

Zookeeper as a hard requirement feels like asking me to supply an entire container port to unload one container from a semi-trailer.

That's interesting thanks for sharing. I've used Elasticsearch and found all the configuration tuning daunting, but I'm sure I would go through that with Solr as well. I never used ES as a primary data store and I had jobs syncing it up so data loss was never a real concern for me.

I just clustered ES with Docker somewhat recently. It was pretty good at discovery I must say. Well, I'm no great search engineer I just throw these things up when I need 'em so good to know all this. Thanks again.

Reply on news.ycombinator.com