5 ms·

In solr vs elasticsearch, my understanding is that solr is more correct and has faster & better algorithms for certain edge cases. Though I'd be interested in h

In solr vs elasticsearch, my understanding is that solr is more correct and has faster & better algorithms for certain edge cases. Though I'd be interested in hearing the details of any differences of opinion. Therefore Stratio's Cassandra Lucene Index is worth an equal mention. https://github.com/Stratio/cassandra-lucene-index https://github.com/Stratio/cassandra-lucene-index

phamilton 10y ago
Solr is operationally more complex to cluster (at least it was a few years ago) and the API is less intuitive in my opinion. Elasticsearch is terribly broken in a lot of ways, but it's awfully easy to get up and running. I'm not sure which I'm holding out for. That Solr will be easier to manage or that ElasticSearch will stop doing terrible things.
- joslin01 10y ago
  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.
- rpedela 10y ago
  Before ES 1.7.x, ES would lose data all the time. However they have made a serious effort to make it much more reliable. There are still some problems, but I haven't lost a significant amount of data in a long time (currently on 2.3.3). They are fixing it.
  - cjbprime 10y ago
    I think everyone agrees it's getting better, but: > This is probably not true: Crate 0.54.9 uses Elasticsearch 1.7, which definitely loses updates. If Crate loses updates, it’s unlikely that you can guarantee reading the latest write, let alone reading that write ever again. Even the unreleased Elasticsearch 5.0.0 still fails its Jepsen tests according to Elastic, so claiming linearizable reads on single keys might be a bit of a stretch. https://aphyr.com/posts/332-jepsen-crate-0-54-9-version-divergence https://aphyr.com/posts/332-jepsen-crate-0-54-9-version-dive...
    - rpedela 10y ago
      Yes there are still problems: https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html https://www.elastic.co/guide/en/elasticsearch/resiliency/cur...
deleted 10y ago
[deleted]
rpedela 10y ago
I think this is a great comparison between Solr and Elasticsearch from a search relevance perspective: http://opensourceconnections.com/blog/2016/01/22/solr-vs-elasticsearch-relevance-part-two/ http://opensourceconnections.com/blog/2016/01/22/solr-vs-ela...
brightball 10y ago
My understanding has always been that elastic search is tremendously more consistent with streaming data while Solr has long pauses for the indexes to keep up. That was based on a detailed post by Loggly some years ago though.

phamilton 10y ago

Solr is operationally more complex to cluster (at least it was a few years ago) and the API is less intuitive in my opinion. Elasticsearch is terribly broken in a lot of ways, but it's awfully easy to get up and running. I'm not sure which I'm holding out for. That Solr will be easier to manage or that ElasticSearch will stop doing terrible things.

joslin01 10y ago
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.
rpedela 10y ago
Before ES 1.7.x, ES would lose data all the time. However they have made a serious effort to make it much more reliable. There are still some problems, but I haven't lost a significant amount of data in a long time (currently on 2.3.3). They are fixing it.
- cjbprime 10y ago
  I think everyone agrees it's getting better, but: > This is probably not true: Crate 0.54.9 uses Elasticsearch 1.7, which definitely loses updates. If Crate loses updates, it’s unlikely that you can guarantee reading the latest write, let alone reading that write ever again. Even the unreleased Elasticsearch 5.0.0 still fails its Jepsen tests according to Elastic, so claiming linearizable reads on single keys might be a bit of a stretch. https://aphyr.com/posts/332-jepsen-crate-0-54-9-version-divergence https://aphyr.com/posts/332-jepsen-crate-0-54-9-version-dive...
  - rpedela 10y ago
    Yes there are still problems: https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html https://www.elastic.co/guide/en/elasticsearch/resiliency/cur...

deleted 10y ago

[deleted]

rpedela 10y ago

I think this is a great comparison between Solr and Elasticsearch from a search relevance perspective: http://opensourceconnections.com/blog/2016/01/22/solr-vs-elasticsearch-relevance-part-two/ http://opensourceconnections.com/blog/2016/01/22/solr-vs-ela...

brightball 10y ago

My understanding has always been that elastic search is tremendously more consistent with streaming data while Solr has long pauses for the indexes to keep up. That was based on a detailed post by Loggly some years ago though.