前言
首先我们要明确一点，elasticsearch 和 solr 没有好坏之分，只有适合不适合。这是通用的道理。我们需要根据我们的实际情况来选择最适合我们的搜索引擎。
所以我们对 elasticsearch 和 solr 的优缺点、适用场景进行一下对比，以及我们的未来需求，来找到最合适的方案。
名词解释
大部分认知中，ES 代表 elasticsearch，还有部分理解中 ES 代表 elastic Stack，本文中使用 ES 表示 elasticsearch。
Solr 优缺点
solr 优点
- Solr 有一个更大、更成熟的用户、开发和贡献者社区。
- 支持添加多种格式的索引，如：HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。
- Solr 比较成熟、稳定。
- 不考虑建索引的同时进行搜索，速度更快。
solr 缺点
- 建立索引时，搜索效率下降，实时索引搜索消息不高。
elasticsearch 优缺点
elasticsearch 优点
- Elasticsearch 是分布式的。不需要其他组件，分发是实时的，被叫做 ”Push replication”。
- Elasticsearch 完全支持 Apache Lucene 的接近实时的搜索。
- 处理多租户（multitenancy）不需要特殊配置，而 Solr 则需要更多的高级设置。
- Elasticsearch 采用 Gateway 的概念，使得完备份更加简单。
- 各节点组成对等的网络结构，某些节点出现故障时会自动分配其他节点代替其进行工作。
elasticsearch 缺点
- 还不够自动（不适合当前新的 Index Warmup API）
solr 和 elasticsearch 比较
然而从上面的优缺点对比来看，我们很难发现哪一个搜索引擎更适合我们。甚至我们对于他们的优缺点的确切概念还有些难以理解。
我们可以对 solr 和 ES 部分特性做一些对比，分析他们之间的差异性，来找到更适合我们的搜索引擎。
流行趋势
毫无疑问，ES 已经成为全文索引的事实霸主，名气在国内赶超 Solr。 通过 Google 搜索趋势对比发现，ES 比 Solr 更加有吸引力，Solr 反而有下降的趋势，但这并不意味着 Solr 已经没落，相反，Solr 仍然是最受欢迎的搜索引擎之一。这一点我们可以从搜索引擎排名中可以看出，当前最受欢迎的前三个搜索引擎：Elasticsearch、Splunk 和 Solr 中仍然包含 Solr。
检索速度
当单纯的对已有数据进行搜索时，Solr 更快。 当实时建立索引时, Solr 会产生 io 阻塞，查询性能较差, Elasticsearch 具有明显的优势。 随着数据量的增加，Solr 的搜索效率会变得更低，而 Elasticsearch 却没有明显的变化。 大型互联网公司，实际生产环境测试，将搜索引擎从 Solr 转到 Elasticsearch 以后的平均查询速度有了 50 倍的提升。
从目前趋势来看，我们已经到了大数据时代，必然会面临着海量数据，相比于 Solr，ES 在海量数据检索速度方面有巨大优势。
Solr 是传统应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。
近实时搜索
近实时搜索一直是 ES 的优势之一。然而这么说其实没有什么道理，因为 Solr 也实现了近实时搜索，只不过因为 ES 先提起这个概念，所以大家在谈起近实时搜索的时候，总是优先想起来 ES。
而且实时性这个是 Lucene 的能力，而不是 ES 和 Solr 的。
社区
- Solr 拥有更多、更成熟的用户、开发者和贡献社区。网上可以搜到大量文档，以及问题解决案例。
- ES 虽然发布时间较短，但是发展迅速，很多知名公司都在使用。社区虽然小，但是很活跃。所以完全不必担心。elasticsearch中文社区
扩容（分布式）
ES 为分布式而生，而且它的设计隐藏了分布式本身的复杂性。ES 默认是集群化的（即时是在单台服务器上运行，也称之为集群），并且总是可以添加更多的服务器用于增加容量或者容错性。类似的，如果负载较低的时候，可以很容易地从集群中移除服务器，降低成本。
SolrCloud 是 Solr 提供的分布式搜索方案。 当你需要大规模，容错，分布式索引和检索能力时使用 SolrCloud。 当索引量很大，搜索请求并发很高时，同样需要使用 SolrCloud 来满足这些需求。 不过当一个系统的索引数据量少的时候是不需要使用 SolrCloud 的。 SolrCloud 是基于 Solr 和 Zookeeper 的分布式搜索方案。它的主要思想是使用 Zookeeper 作为 SolrCloud 集群的配置信息中心，统一管理 solrcloud 的配置，比如 solrconfig.xml 和 schema.xml。
对于大多数数据库来说，横向扩展（增加新机器）意味着你的程序将做很大改动才能利用这些新添加的设备。对比来说，ES 天生就是分布式的，它知道如何管理节点来提供高扩展和高可用，这意味着你的程序不必要关心这些。
数据量
分布式的 ElasticSearch 支持的数据量确实更大，毫无疑问。但这是相对于单机版 Solr 来说的，分布式 Solr-cloud 数据量也是一样的支持。
在这一点上，Solr 和 ES 并没有什么区别。
数据聚合功能（aggregation） ☆☆☆☆☆☆☆☆
这个打这么多☆，纯粹是因为这点真是太太太突出了。
无论选择哪个搜索引擎，我们都有一个同样的目标：组织数据为我们的目标所服务。 ES 为我们提供了一个超级棒的功能，数据聚合（aggregation）。聚合功能为 ES 注入了统计分析的血统，使用户在面对大数据提取统计指标时变得游刃有余。
而 Solr 中同样提供相似的功能Analytics Component
这也反映出，其实 ES 和 Solr 并没有什么太大区别。
模式
Solr 中的数据是结构化的，Solr 通过模式文件 schema.xml 文件来定义这种结构。
ES 中的文档是无模式的，也就是说并非所有的文档都需要拥有相同的字段，它们不是受限于同一种模式。
ES 会有一种自动检测的功能，检测一篇新近索引的文档是否拥有一个映射中尚未存在的字段，如果不存在，ES 会自动的将新字段加入映射。为了添加这个字段，ES 不得不确定它是什么类型，于是 ES 会进行猜测。例如：如果值是 7，ES 会假设字段是长整型。
这种做法的缺点是：ES 可能猜的不对。例如，在索引了值 7 之后，你可能再索引 hello world，这时由于它是 string 而不是 long，索引就会失败。
对于线上环境，最安全的方式是在索引数据之前，就定义好所需的映射。
配置管理 ☆
ES 的一个强项是，它的默认配置对程序员非常友好，入门非常容容易。ElasticSearch 很多功能都是开箱即用，并不需要用户去配置。ElasticSearch 的设计哲学是尽量减少用户犯错的可能，ES 对运行环境还做了诸多限制，以避免运行过程中出现一些莫名其妙的错误，因为很多用户并不是这些领域的专家，他们没法从这些错误中找到原因。ES 帮助我们从复杂的配置中解脱出来，将更多的时间和精力放在其他事情上。
Solr 的配置太过于灵活，给了用户很多犯错误的可能。但 Solr 的定制能力更强，几乎什么都可以配置。对于开发者来说，要实现一个新的功能，可以不用动 Solr 核心代码，而给 Solr 增加一些 Processer 和 Component，然后通过 xml 配置服务器的行为。
生态圈 ☆☆☆
Elasticsearch、Logstash、Kibana，
适用场景
网络上对两个搜索引擎的适用场景众说纷纭。 奈何个人才疏学浅，无法分辨真伪。 但是有一点，Solr 和 ES 作为当前两个最流行的搜索引擎，本来就是互相借鉴，共同进步，没有明显的差异性，没有明显的适用和不适用，只能说择其善者而从之。
如果真的有，我会总结在这里。
结论
ES 和 Solr 本质上其实并没有什么太大的差别，毕竟都是基于 Lucene。而且这两个搜索引擎还在不断迭代，该有的功能都有，只不过实现方式不一致。Solr 实现了许多功能，而 ES 的许多功能都是通过插件的方式实现的。
但是，谁叫 ES 目前更流行呢，我投 ES 一票！！！！！！
