搜索引擎Solr与Elasticsearch的选择

  • 前言
  • Solr
  • ElasticSearch（简称ES）
  • 如何选择


前言

    笔者接触搜索引擎也有一段时间了，从开始接触到现在一直使用的是Solr，因为对于我们来说应用场景并不多，而且要求不高，Solr基本能满足我们的需求，期间对Solr升过一次级，从7点几升级到8点几，差别并不大。以前也简单了解过ElasticSearch，但并没有深入研究过，最近还是想研究下ElasticSearch，以便日后在实际工作中能有更多的选择。
    在此，我不会对每种搜索引擎做更多更详细的介绍，也不会对他们的安装过程进行讲解，因为这些在某度上已经有太多的文章来讲解了。虽然也有人对他们进行比较，但是笔者还是想把自己总结的和心得分享给大家。

Solr

    我们公司本身是做政务行业的，很多项目都是在内网使用，而且数据量也不大，因此我们对搜索引擎的性能要求并不高。
    Solr是我使用的最多的搜索引擎，原因大概有两点吧：

  1. 它自带了一个管理页面，操作起来比较方便，这个是ElasticSearch没有的
  2. 它能够通过配置直连数据库，并将数据库中的记录直接抽取到Solr中创建索引，而且此过程只需要在它自带的管理页面中进行即可完成，根本不需要编写代码。不过，Solr团队将在9版本中移除该功能，将该功能交给社区维护，会以另一种形式存在。

以上两点都是ElasticSearch没有的，而对于我们来说特别的实用。

ElasticSearch（简称ES）

    ES它并没有自带管理页面，都是使用第三方的插件或工具，比如：ElasticSearch-Head、Kibana等。它也没有直连数据库的功能，而且只支持JSON结构的存储，Solr则支持多种存储结构。
    尽管如此，也阻止不了ES耀眼的光芒。笔者在研究ES时与Solr进行写入性能的对比，同样的代码分别向Solr和ES中写入数据得到的结果如下：

  1. 分别向Solr和ES中插入50条数据时：
    Solr耗时3.9秒，ES耗时0.4秒
  2. 分别向Solr和ES中插入10000条数据时：
    Solr耗时9.8分钟，ES耗时47.9秒

    看到这样一个测试结果，令我甚是惊讶，ES的写入性能如此惊人。我也想过，可能我的测试不够严谨，但即使抛开所有外在因素，任凭我对Solr再怎么优化，随着数据量的增长，Solr的性能也会下降，写入会对查询性能造成影响，ES则不会出现这些问题，由此可见Solr的性能远远不及ES。
    这也仅仅是写入的测试，查询则更不用多说了，ES提供了分片副本用于提升查询性能，同时ES自身就支持分布式，很方便的就能实现集群，而Solr则要借助Zookeeper来实现集群。
    还有一点，Solr的属性增加时，是需要同时修改配置文件和代码的，而ES则不需要修改配置文件，只需要根据需求调整代码即可，这一点也是ES的一个优势。
    而且，有些时候我们是把搜索引擎当成是数据库来使用以提高我们的查询性能，在这方面用Solr的就比较少，ES用的比较多，比如日志搜集后的存储、查询，像现在比较流行的EFK（ES、Filebeat、Kibana）用作日志搜集就是很好的例子。

如何选择

    我想通过我上面的介绍，大家心中应该已经有了结果，那么我们来总结一下：
    当你的实际应用场景和笔者的场景一样，数据量本身就不多，多少年也不会增长多少，不会出现爆发式的增长，那么你完全可以使用Solr，它还有一个可视化的管理页面。
    当你的数据量比较大、后期也会迅速增长、对实时性要求高或者想把搜索引擎当成数据库来使用，那么建议直接使用ElasticSearch不会错的。

如有说的不对的地方，请多指教！