我开始创建新的搜索应用程序。在我之前的应用程序中，我使用了Apache solr。现在我想知道在性能和可用性方面哪个更好。
我个人想知道Elastic search和solr的性能基准。如果有其他替代方案，欢迎提出建议。
答案 0 :(得分：2)
免责声明：我在elasticsearch.com工作
我只想说：尝试一下弹性搜索。我想在几个小时后（几分钟？），你会有某种意见。 启动2或3或4个节点，您将看到如何很好地重新平衡事物。
关于性能，我会说即使你正在进行大量的索引操作，elasticsearch也会为你提供一个恒定的查询吞吐量。
答案 1 :(得分：1)
我已经使用了很多，而且更喜欢ElasticSearch。 API更灵活，更易于访问。开始使用起来比较容易。默认情况下会自动进行复制通常，所有默认值都更容易使用。一切都通常是开箱即用（安全默认值），你只需要调整你发现需要更好的工作。
我没有使用SOLR 4，仅使用3.x.一旦我切换，我从未回头，但我听说在复制和群集方面有很多改进，使其成为可用的竞争对手。
关于性能，我认为通常它们是可比较的，因为它们都依赖于Lucene。这就是为什么缺乏有效的基准来进行这种一般比较。也就是说，肯定会有一个用户表现得比另一个好。
如果你看一下使用趋势，而目前有更多的人使用SOLR，那么它正在下降。这种下降与Elasticsearch用户的增长密切相关，而Elasticsearch的用户数量正在急剧上升。正如Dadoonet所说，尝试一下ElasticSearch，它不会花很长时间，你又不想再使用SOLR了。
更新
我刚刚在客户网站上花了两周时间咨询SOLR云安装。我现在对SOLR的更新更加熟悉，并且非常自信地说，我仍然更喜欢ElasticSearch，但似乎SOLR再次有了一些动力。
ElasticSearch，更有弹性。也就是说，拥有一个弹性集群，其中节点来来往往，或者甚至只需要添加节点，这在ElasticSearch中要比SOLR容易得多。任何在SOLR中告诉你它很容易的人都没有在ElasticSearch中完成它。 ElasticSearch将自动加入群集并在该群集中承担活动角色，接管服务可用分片和副本。在过去的一周里，我退出了一个2节点集群，用两个新节点取而代之。我只是添加了2个新节点，一次一个，将其他两个节点标记为非数据节点。碎片迁移完成后，我退出节点。我设置了minimum_master_nodes = 2（（2/2）+1），并且没有裂脑问题。
在同一周，我不得不将一个节点添加到SOLR集群。这个过程记录很少，特别是考虑到4.1到4.3的变化以及现有文档的混乱，其中大部分都表示你甚至可以根据旧版本的SOLR来做到这一点。我终于找到了澄清的文件。它需要手动将核心添加到集合中，然后将副本添加到集群中的现有分片。最后，您手动停用其他节点上的冗余分片。在某些时候，此节点可能会成为其中一个分片的主节点，但不会立即成为主节点。
使用SOLR如果没有足够的分片进行分发，则只需添加副本，或者可以通过分片分割来创建两个新分片。同样，这是一个记录不完整的功能，但它是ElasticSearch中不存在的功能。您必须拆分然后删除原始分片，这些文档都没有明确说明。
如果与Hadoop集成，SolrCloud还有其他一些优势。如果要在HDFS或HBase中索引数据，现在有Map-Reduce和将数据摄取到SOLR的实时方法。这为您的大数据平台提供了一些实际功能，并允许您对几乎无法访问的数据进行全文搜索。
虽然您可以将Hadoop数据索引到ElasticSearch中，但实现并不像SolrCloud / Cloudera Search实现那样干净。让MapReduce直接构建分片是一个非常优越的解决方案，具有显着的性能优势。直接与群集通信的减速器有效，但它不一样。我不知道ElasticSearch是否存在类似于HBase的Lily连接器的任何内容，如果不是，我可能会考虑编写一个。这允许直接从HBase复制日志中进行索引。
总而言之，肯定存在两种情况都有益的情况。如果您正在寻找与Hadoop，SOLR，ClouderaSearch的紧密集成，那么这是一个不错的选择。如果您希望轻松管理Elastic集群，Elasticsearch将是一个更好的选择。对我来说，我将继续我的hacky Hadoop集成，使其与Elasticsearch一起使用，直到出现更好的东西。