Having inherited an ES cluster shortly after it replaced Solr, and built out many clusters since then, I can comment that the 'split brain' problem which attrac

Having inherited an ES cluster shortly after it replaced Solr, and built out many clusters since then, I can comment that the 'split brain' problem which attracted a lot of attention 2-3 years ago thanks to the infamous Jepsen 'Call Me Maybe' torture test is effectively a non-issue in a well-configured environment, today. Theoretically possible, perhaps; in practice, just not an issue. Our initial cluster suffered from it thanks to improperly having been run across data centers with default settings of various kinds. Once I got that under control, zero recurrence despite our clusters living in what I like to call a 'hostile network environment.' I am not a fan of the 'Zen' cluster management system they adopted; but it does work and Elastic has put a ton of work into cleaning out the corner cases. For my purposes, One of the distinctions I would say is most interesting today is that Elastic the company has been aggressively chasing the analytics market, at the expense of developing the text/freeform search capabilities of ES. At Elasticon last year there were some interesting talks that touched on this in various ways; and I was part of a group of people who traded chagrin that Elastic does not have a strong user community in this area. Instead they have put a lot of work on their 'stack' and data shippers and cloud deployment. Solr on the other hand has continued to move forward and for an environment in which the primary application is going to be free-form text search (vs. say structured metadata, or analytics) it is probably stronger. Fwiw I find deployment, configuration, inspection, etc., all refreshingly clean. Imperfect, sure, but the ES team did have the advantage of starting with a blank page in a lot of respects. It shows. (Currently running 6+ clusters, 100+ nodes, doing metadata and full-text and a small amount of analytics)