最近项目组安排了一个任务，项目中用到了全文搜索，基于全文搜索 Solr，可是该 Solr 搜索云项目不稳定，常常查询不出来数据，须要手动全量同步，并且是其余团队在维护，依赖性太强，致使 Solr 服务一出问题，咱们的项目也基本瘫痪，由于全部的依赖查询都无结果数据了。因此考虑开发一个适配层，若是 Solr 搜索出问题，自动切换到新的搜索--ES。html

其实能够经过 Solr 集群或者服务容错等设计来解决该问题。可是先不考虑自己设计的合理性，领导须要开发，因此我开始踏上了搭建 ES 服务的道路，从零开始，由于以前彻底没接触过 ES，因此经过本系列来记录下本身的开发过程。mysql

什么是全文搜索

什么是全文搜索引擎？算法

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

从定义中咱们已经能够大体了解全文检索的思路了，为了更详细的说明，咱们先从生活中的数听说起。数据库

咱们生活中的数据整体分为两种：结构化数据 和 非结构化数据。编程

结构化数据：指具备固定格式或有限长度的数据，如数据库，元数据等。
非结构化数据：非结构化数据又可称为全文数据，指不定长或无固定格式的数据，如邮件，word文档等。

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

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

对于结构化数据，咱们通常都是能够经过关系型数据库(mysql，oracle等)的 table 的方式存储和搜索，也能够创建索引。对于非结构化数据，也即对全文数据的搜索主要有两种方法：顺序扫描法，全文检索。安全

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

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

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

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

为何要用全文搜索搜索引擎

以前，有同事问我，为何要用搜索引擎？咱们的全部数据在数据库里面都有，并且 Oracle、SQL Server 等数据库里也能提供查询检索或者聚类分析功能，直接经过数据库查询不就能够了吗？确实，咱们大部分的查询功能均可以经过数据库查询得到，若是查询效率低下，还能够经过建数据库索引，优化SQL等方式进行提高效率，甚至经过引入缓存来加快数据的返回速度。若是数据量更大，就能够分库分表来分担查询压力。

那为何还要全文搜索引擎呢？咱们主要从如下几个缘由分析：

数据类型 全文索引搜索支持非结构化数据的搜索，能够更好地快速搜索大量存在的任何单词或单词组的非结构化文本。例如 Google，百度类的网站搜索，它们都是根据网页中的关键字生成索引，咱们在搜索的时候输入关键字，它们会将该关键字即索引匹配到的全部网页返回；还有常见的项目中应用日志的搜索等等。对于这些非结构化的数据文本，关系型数据库搜索不是能很好的支持。
索引的维护 通常传统数据库，全文检索都实现的很鸡肋，由于通常也没人用数据库存文本字段。进行全文检索须要扫描整个表，若是数据量大的话即便对SQL的语法优化，也收效甚微。创建了索引，可是维护起来也很麻烦，对于 insert 和 update 操做都会从新构建索引。

何时使用全文搜索引擎：

搜索的数据对象是大量的非结构化的文本数据。
文件记录量达到数十万或数百万个甚至更多。
支持大量基于交互式文本的查询。
需求很是灵活的全文搜索查询。
对高度相关的搜索结果的有特殊需求，可是没有可用的关系数据库能够知足。
对不一样记录类型、非文本数据操做或安全事务处理的需求相对较少的状况。

Lucene，Solr， ElasticSearch ？

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

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

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

Lucene

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

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

可扩展的高性能索引

在现代硬件上超过150GB /小时
小RAM要求 - 只有1MB堆
增量索引与批量索引同样快
索引大小约为索引文本大小的20-30％

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

排名搜索 - 首先返回最佳结果
许多强大的查询类型：短语查询，通配符查询，邻近查询，范围查询等
现场搜索（例如标题，做者，内容）
按任何字段排序
使用合并结果进行多索引搜索
容许同时更新和搜索
灵活的分面，突出显示，链接和结果分组
快速，内存效率和错误容忍的建议
可插拔排名模型，包括矢量空间模型和Okapi BM25
可配置存储引擎（编解码器）

跨平台解决方案

做为Apache许可下的开源软件提供，容许您在商业和开源程序中使用Lucene
100％-pure Java
可用的其余编程语言中的实现是索引兼容的

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

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

Solr

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

主要功能列表包括：

全文搜索
突出
分面搜索
实时索引
动态群集
数据库集成
NoSQL功能和丰富的文档处理（例如Word和PDF文件）

ElasticSearch

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

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

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

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

主要功能列表包括：

分布式搜索
多租户
分析搜索
分组和聚合

Elasticsearch vs. Solr的选择

因为Lucene的复杂性，通常不多会考虑它做为搜索的第一选择，排除一些公司须要自研搜索框架，底层须要依赖Lucene。因此这里咱们重点分析 Elasticsearch 和 Solr。

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

历史比较

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

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

Elasticsearch虽然很年轻，但它也本身的一些优点，Elasticsearch 创建在更现代的原则上，针对更现代的用例，而且是为了更容易处理大型索引和高查询率而构建的。此外，因为它太年轻，没有社区能够合做，它能够自由地向前推动，而不须要与其余人（用户或开发人员）达成任何共识或合做，向后兼容，或任何其余更成熟的软件一般必须处理。

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

特征差别比较

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

特征	Solr/SolrCloud	Elasticsearch
社区和开发者	Apache 软件基金和社区支持	单一商业实体及其员工
节点发现	Apache Zookeeper，在大量项目中成熟且通过实战测试	Zen内置于Elasticsearch自己，须要专用的主节点才能进行分裂脑保护
碎片放置	本质上是静态，须要手动工做来迁移分片，从Solr 7开始 - Autoscaling API容许一些动态操做	动态，能够根据群集状态按需移动分片
高速缓存	全局，每一个段更改无效	每段，更适合动态更改数据
分析引擎性能	很是适合精确计算的静态数据	结果的准确性取决于数据放置
全文搜索功能	基于Lucene的语言分析，多建议，拼写检查，丰富的高亮显示支持	基于Lucene的语言分析，单一建议API实现，高亮显示从新计算
DevOps支持	还没有彻底，但即将到来	很是好的API
非平面数据处理	嵌套文档和父-子支持	嵌套和对象类型的天然支持容许几乎无限的嵌套和父-子支持
查询DSL	JSON（有限），XML（有限）或URL参数	JSON
索引/收集领导控制	领导者安置控制和领导者从新平衡甚至能够节点上的负载	不可能
机器学习	内置 - 在流聚合之上，专一于逻辑回归和学习排名贡献模块	商业功能，专一于异常和异常值以及时间序列数据

这里了解更多。

综合比较

另外，咱们在从如下几个方面来分析下：

近几年的流行趋势咱们查看一下这两种产品的Google搜索趋势。谷歌趋势代表，与 Solr 相比，Elasticsearch具备很大的吸引力，但这并不意味着Apache Solr已经死亡。虽然有些人可能不这么认为，但Solr仍然是最受欢迎的搜索引擎之一，拥有强大的社区和开源支持。

安装和配置与Solr相比，Elasticsearch易于安装且很是轻巧。此外，您能够在几分钟内安装并运行Elasticsearch。可是，若是Elasticsearch管理不当，这种易于部署和使用可能会成为一个问题。基于JSON的配置很简单，但若是要为文件中的每一个配置指定注释，那么它不适合您。总的来讲，若是您的应用使用的是JSON，那么Elasticsearch是一个更好的选择。不然，请使用Solr，由于它的schema.xml和solrconfig.xml都有很好的文档记录。
社区 Solr拥有更大，更成熟的用户，开发者和贡献者社区。ES虽拥有的规模较小但活跃的用户社区以及不断增加的贡献者社区。 Solr是真正的开源社区代码。任何人均可觉得Solr作出贡献，而且根据优势选出新的Solr开发人员（也称为提交者）。Elasticsearch在技术上是开源的，但在精神上却不那么重要。任何人均可以看到来源，任何人均可以更改它并提供贡献，但只有Elasticsearch的员工才能真正对Elasticsearch进行更改。 Solr贡献者和提交者来自许多不一样的组织，而Elasticsearch提交者来自单个公司。
成熟度 Solr更成熟，但ES增加迅速，我认为它稳定。
文档 Solr在这里得分很高。它是一个很是有据可查的产品，具备清晰的示例和API用例场景。 Elasticsearch的文档组织良好，但它缺少好的示例和清晰的配置说明。

总结

那么，究竟是Solr仍是Elasticsearch？有时很难找到明确的答案。不管您选择Solr仍是Elasticsearch，首先须要了解正确的用例和将来需求。总结他们的每一个属性。

记住：

因为易于使用，Elasticsearch在新开发者中更受欢迎。可是，若是您已经习惯了与Solr合做，请继续使用它，由于迁移到Elasticsearch没有特定的优点。
若是除了搜索文本以外还须要它来处理分析查询，Elasticsearch是更好的选择。
若是须要分布式索引，则须要选择Elasticsearch。对于须要良好可伸缩性和性能的云和分布式环境，Elasticsearch是更好的选择。
二者都有良好的商业支持（咨询，生产支持，整合等）
二者都有很好的操做工具，尽管Elasticsearch因其易于使用的API而更多地吸引了DevOps人群，所以能够围绕它建立一个更加生动的工具生态系统。
Elasticsearch在开源日志管理用例中占据主导地位，许多组织在Elasticsearch中索引它们的日志以使其可搜索。虽然Solr如今也能够用于此目的，但它只是错过了这一想法。
Solr仍然更加面向文本搜索。另外一方面，Elasticsearch 一般用于过滤和分组 - 分析查询工做负载 - 而不必定是文本搜索。Elasticsearch 开发人员在 Lucene 和 Elasticsearch 级别上投入了大量精力使此类查询更高效(下降内存占用和CPU使用)。所以，对于不只须要进行文本搜索，并且须要复杂的搜索时间聚合的应用程序，Elasticsearch是一个更好的选择。
Elasticsearch更容易上手，一个下载和一个命令就能够启动一切。Solr传统上须要更多的工做和知识，但Solr最近在消除这一点上取得了巨大的进步，如今只需努力改变它的声誉。
在性能方面，它们大体相同。我说“大体”，由于没有人作过全面和无偏见的基准测试。对于95％的用例，任何一种选择在性能方面都会很好，剩下的5％须要用它们的特定数据和特定的访问模式来测试这两种解决方案。
从操做上讲，Elasticsearch使用起来比较简单 - 它只有一个进程。Solr在其相似Elasticsearch的彻底分布式部署模式SolrCloud中依赖于Apache ZooKeeper。ZooKeeper是超级成熟，超级普遍使用等等，但它仍然是另外一个活跃的部分。也就是说，若是您使用的是Hadoop，HBase，Spark，Kafka或其余一些较新的分布式软件，您可能已经在组织的某个地方运行ZooKeeper。
虽然Elasticsearch内置了相似ZooKeeper的组件Xen，但ZooKeeper能够更好地防止有时在Elasticsearch集群中出现的可怕的裂脑问题。公平地说，Elasticsearch开发人员已经意识到这个问题，并致力于改进Elasticsearch的这个方面。
若是您喜欢监控和指标，那么使用Elasticsearch，您将会进入天堂。这个东西比新年前夜在时代广场能够挤压的人有更多的指标！Solr暴露了关键指标，但远不及Elasticsearch那么多。

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

参考：

我的公众号：JaJian

欢迎长按下图关注公众号：JaJian！

按期为你奉上分布式，微服务等一线互联网公司相关技术的讲解和分析。

全文搜索引擎 ElasticSearch 仍是 Solr？