5 ms·

Would be curious to hear what Elasticsearch is doing wrong if you don't mind. I have no dog in the fight, I just always hear good things.

elcapitan 10y ago
I haven't seen it being broken, but it breaking things all the time definitely. There are more non-backwards compatible api changes between versions than I have seen with other infrastructure software. When you spend lots of time fine-tuning the exact combination of filters, ranking algorithms, weighting of fields and so on, the api just completely switching certain methods kind of hurts.
fusiongyro 10y ago
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.
- rrampage 10y ago
  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.
  - johnbellone 10y ago
    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 https://github.com/bloomberg/zookeeper-cookbook
    - phamilton 10y ago
      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).
    - techdragon 10y ago
      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.
    - rrampage 10y ago
      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?
phamilton 10y ago
My favorite experience was discovering that HTTP Pipelining was completely broken. Rather than respond in FIFO order, it would respond in the order that queries completed. Since most of our queries were homogenous, we wouldn't detect any schema issues and successfully return a completely wrong set of results to our users.

elcapitan 10y ago

I haven't seen it being broken, but it breaking things all the time definitely. There are more non-backwards compatible api changes between versions than I have seen with other infrastructure software. When you spend lots of time fine-tuning the exact combination of filters, ranking algorithms, weighting of fields and so on, the api just completely switching certain methods kind of hurts.

fusiongyro 10y ago

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.

rrampage 10y ago
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.
- johnbellone 10y ago
  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 https://github.com/bloomberg/zookeeper-cookbook
  - phamilton 10y ago
    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).
  - techdragon 10y ago
    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.
  - rrampage 10y ago
    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?

phamilton 10y ago

My favorite experience was discovering that HTTP Pipelining was completely broken. Rather than respond in FIFO order, it would respond in the order that queries completed. Since most of our queries were homogenous, we wouldn't detect any schema issues and successfully return a completely wrong set of results to our users.