全文搜索引擎选 ElasticSearch 还是 Solr

　　全文搜索引擎选 ElasticSearch 还是 Solr

　　最近项目组安排了一个任务，项目中用到了全文搜索，基于全文搜索Solr，但是该Solr搜索云项目不稳定，经常查询不出来数据，需要手动全量同步，而且是其他团队在维护，依赖性太强，导致Solr服务一出问题，我们的项目也基本瘫痪，因为所有的依赖查询都无结果数据了。所以考虑开发一个适配层，如果Solr搜索出问题，自动切换到新的搜索--ES。

　　其实可以通过Solr集群或者服务容错等设计来解决该问题。但是先不考虑本身设计的合理性，领导需要开发，所以我开始踏上了搭建ES服务的道路，从零开始，因为之前完全没接触过ES，所以通过本系列来记录下自己的开发过程。

　　1.什么是全文搜索

　　什么是全文搜索引擎？

　　百度百科中的定义：全文搜索引擎是目前广泛应用的主流搜索引擎。它的工作原理是计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。

　　从定义中我们已经可以大致了解全文检索的思路了，为了更详细的说明，我们先从生活中的数据说起。

　　我们生活中的数据总体分为两种：结构化数据 和 非结构化数据。

　　当然有的地方还会有第三种：半结构化数据，如XML，HTML等，当根据需要可按结构化数据来处理，也可抽取出纯文本按非结构化数据来处理。

　　根据两种数据分类，搜索也相应的分为两种：结构化数据搜索和非结构化数据搜索。

　　对于结构化数据，我们一般都是可以通过关系型数据库(mysql，oracle等)的table的方式存储和搜索，也可以建立索引。对于非结构化数据，也即对全文数据的搜索主要有两种方法：顺序扫描法，全文检索。

　　顺序扫描：通过文字名称也可了解到它的大概搜索方式，即按照顺序扫描的方式查询特定的关键字。例如给你一张报纸，让你找到该报纸中“RNG”的文字在哪些地方出现过。你肯定需要从头到尾把报纸阅读扫描一遍然后标记出关键字在哪些版块出现过以及它的出现位置。

　　这种方式无疑是最耗时的最低效的，如果报纸排版字体小，而且版块较多甚至有多份报纸，等你扫描完你的眼睛也差不多了。

　　全文搜索：对非结构化数据顺序扫描很慢，我们是否可以进行优化？把我们的非结构化数据想办法弄得有一定结构不就行了吗？将非结构化数据中的一部分信息提取出来，重新组织，使其变得有一定结构，然后对此有一定结构的数据进行搜索，从而达到搜索相对较快的目的。这种方式就构成了全文检索的基本思路。这部分从非结构化数据中提取出的然后重新组织的信息，我们称之索引。

　　还以读报纸为例，我们想关注最近英雄联盟S8全球总决赛的新闻，假如都是RNG的粉丝，如何快速找到RNG新闻的报纸和版块呢？全文搜索的方式就是，将所有报纸中所有版块中关键字进行提取，如"EDG"，"RNG"，"FW"，"战队"，"英雄联盟"等。然后对这些关键字建立索引，通过索引我们就可以对应到该关键词出现的报纸和版块。注意区别目录搜索引擎。

　　2.为什么要用全文搜索搜索引擎

　　之前，有同事问我，为什么要用搜索引擎？我们的所有数据在数据库里面都有，而且Oracle、SQLServer等数据库里也能提供查询检索或者聚类分析功能，直接通过数据库查询不就可以了吗？确实，我们大部分的查询功能都可以通过数据库查询获得，如果查询效率低下，还可以通过建数据库索引，优化SQL等方式进行提升效率，甚至通过引入缓存来加快数据的返回速度。如果数据量更大，就可以分库分表来分担查询压力。

　　那为什么还要全文搜索引擎呢？我们主要从以下几个原因分析：

　　什么时候使用全文搜索引擎：

　　搜索的数据对象是大量的非结构化的文本数据。

　　文件记录量达到数十万或数百万个甚至更多。

　　支持大量基于交互式文本的查询。

　　需求非常灵活的全文搜索查询。

　　对高度相关的搜索结果的有特殊需求，但是没有可用的关系数据库可以满足。

　　对不同记录类型、非文本数据操作或安全事务处理的需求相对较少的情况。

　　3.Lucene，Solr，ElasticSearch？

　　现在主流的搜索引擎大概就是：Lucene，Solr，ElasticSearch。

　　

　　它们的索引建立都是根据倒排索引的方式生成索引，何谓倒排索引？

　　维基百科倒排索引（英语：Invertedindex），也常被称为反向索引、置入档案或反向档案，是一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。它是文档检索系统中最常用的数据结构。

　　3-1Lucene

　　Lucene是一个Java全文搜索引擎，完全用Java编写。Lucene不是一个完整的应用程序，而是一个代码库和API，可以很容易地用于向应用程序添加搜索功能。

　　Lucene通过简单的API提供强大的功能：

　　可扩展的高性能索引

　　强大，准确，高效的搜索算法

　　跨平台解决方案

　　Apache软件基金会在Apache软件基金会提供的开源软件项目的Apache社区的支持。

　　但是Lucene只是一个框架，要充分利用它的功能，需要使用JAVA，并且在程序中集成Lucene。需要很多的学习了解，才能明白它是如何运行的，熟练运用Lucene确实非常复杂。

　　3-2Solr

　　ApacheSolr是一个基于名为Lucene的Java库构建的开源搜索平台。它以用户友好的方式提供ApacheLucene的搜索功能。作为一个行业参与者近十年，它是一个成熟的产品，拥有强大而广泛的用户社区。它提供分布式索引，复制，负载平衡查询以及自动故障转移和恢复。如果它被正确部署然后管理得好，它就能够成为一个高度可靠，可扩展且容错的搜索引擎。很多互联网巨头，如Netflix，eBay，Instagram和亚马逊（CloudSearch）都使用Solr，因为它能够索引和搜索多个站点。

　　主要功能列表包括：

　　3-3ElasticSearch

　　Elasticsearch是一个开源（Apache2许可证），是一个基于ApacheLucene库构建的RESTful搜索引擎。

　　Elasticsearch是在Solr之后几年推出的。它提供了一个分布式，多租户能力的全文搜索引擎，具有HTTPWeb界面（REST）和无架构JSON文档。Elasticsearch的官方客户端库提供Java，Groovy，PHP，Ruby，Perl，Python，.NET和Javascript。

　　分布式搜索引擎包括可以划分为分片的索引，并且每个分片可以具有多个副本。每个Elasticsearch节点都可以有一个或多个分片，其引擎也可以充当协调器，将操作委派给正确的分片。

　　Elasticsearch可通过近实时搜索进行扩展。其主要功能之一是多租户。

　　主要功能列表包括：

　　4Elasticsearch vs. Solr的选择

　　由于Lucene的复杂性，一般很少会考虑它作为搜索的第一选择，排除一些公司需要自研搜索框架，底层需要依赖Lucene。所以这里我们重点分析Elasticsearch和Solr。

　　Elasticsearchvs.Solr。哪一个更好？他们有什么不同？你应该使用哪一个？

　　

　　4-1历史比较

　　ApacheSolr是一个成熟的项目，拥有庞大而活跃的开发和用户社区，以及Apache品牌。Solr于2006年首次发布到开源，长期以来一直占据着搜索引擎领域，并且是任何需要搜索功能的人的首选引擎。它的成熟转化为丰富的功能，而不仅仅是简单的文本索引和搜索；如分面，分组，强大的过滤，可插入的文档处理，可插入的搜索链组件，语言检测等。

　　Solr在搜索领域占据了多年的主导地位。然后，在2010年左右，Elasticsearch成为市场上的另一种选择。那时候，它远没有Solr那么稳定，没有Solr的功能深度，没有思想分享，品牌等等。

　　Elasticsearch虽然很年轻，但它也自己的一些优势，Elasticsearch建立在更现代的原则上，针对更现代的用例，并且是为了更容易处理大型索引和高查询率而构建的。此外，由于它太年轻，没有社区可以合作，它可以自由地向前推进，而不需要与其他人（用户或开发人员）达成任何共识或合作，向后兼容，或任何其他更成熟的软件通常必须处理。

　　因此，它在Solr之前就公开了一些非常受欢迎的功能(例如，接近实时搜索，英文：NearReal-TimeSearch)。从技术上讲，NRT搜索的能力确实来自Lucene，它是Solr和Elasticsearch使用的基础搜索库。具有讽刺意味的是，因为Elasticsearch首先公开了NRT搜索，所以人们将NRT搜索与Elasticsearch联系在一起，尽管Solr和Lucene都是同一个Apache项目的一部分，因此，人们会首先期望Solr具有如此高要求的功能。

　　4-2特征差异比较

　　这两个搜索引擎都是流行的，先进的的开源搜索引擎。它们都是围绕核心底层搜索库-Lucene构建的-但它们又是不同的。像所有东西一样，每个都有其优点和缺点，根据您的需求和期望，每个都可能更好或更差。Solr和Elasticsearch都在快速发展，所以，话不多说，先来看下它们的差异清单：

　　特征Solr/SolrCloudElasticsearch

　　社区和开发者

　　Apache 软件基金和社区支持

　　单一商业实体及其员工

　　节点发现

　　Apache Zookeeper，在大量项目中成熟且经过实战测试

　　Zen内置于Elasticsearch本身，需要专用的主节点才能进行分裂脑保护

　　碎片放置

　　本质上是静态，需要手动工作来迁移分片，从Solr 7开始 - Autoscaling API允许一些动态操作

　　动态，可以根据群集状态按需移动分片

　　高速缓存

　　全局，每个段更改无效

　　每段，更适合动态更改数据

　　分析引擎性能

　　非常适合精确计算的静态数据

　　结果的准确性取决于数据放置

　　全文搜索功能

　　基于Lucene的语言分析，多建议，拼写检查，丰富的高亮显示支持

　　基于Lucene的语言分析，单一建议API实现，高亮显示重新计算

　　DevOps支持

　　尚未完全，但即将到来

　　非常好的API

　　非平面数据处理

　　嵌套文档和父-子支持

　　嵌套和对象类型的自然支持允许几乎无限的嵌套和父-子支持

　　查询DSL

　　JSON（有限），XML（有限）或URL参数

　　JSON

　　索引/收集领导控制

　　领导者安置控制和领导者重新平衡甚至可以节点上的负载

　　不可能

　　机器学习

　　内置 - 在流聚合之上，专注于逻辑回归和学习排名贡献模块

　　商业功能，专注于异常和异常值以及时间序列数据

　　4-3 综合比较

　　另外，我们在从以下几个方面来分析下：

　　

　　5. 总结

　　那么，到底是Solr还是Elasticsearch？有时很难找到明确的答案。无论您选择Solr还是Elasticsearch，首先需要了解正确的用例和未来需求。总结他们的每个属性。

　　记住：

　　总之，两者都是功能丰富的搜索引擎，只要设计和实现得当，它们或多或少都能提供相同的性能。本篇文章的总体内容大致如下图，该图由园友ReyCG精心绘制并提供。

　　

　　参考：