什么是全文搜索引擎？
百度百科中的定义：
全文搜索引擎是目前广泛运用的主流搜索引擎。它的事情事理是打算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中涌现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索办法。这个过程类似于通过字典中的检索字表查字的过程。
从定义中我们已经可以大致理解全文检索的思路了，为了更详细的解释，我们先从生活中的数听说起。
我们生活中的数据总体分为两种：构造化数据 和 非构造化数据。
构造化数据： 指具有固定格式或有限长度的数据，如数据库，元数据等。非构造化数据： 非构造化数据又可称为全文数据，指不定长或无固定格式的数据，如邮件，word文档等。当然有的地方还会有第三种：半构造化数据，如XML，HTML等，当根据须要可按构造化数据来处理，也可抽取出纯文本按非构造化数据来处理。
根据两种数据分类，搜索也相应的分为两种：构造化数据搜索和非构造化数据搜索。
对付构造化数据，我们一样平常都是可以通过关系型数据库(mysql，oracle等)的 table 的办法存储和搜索，也可以建立索引。
对付非构造化数据，也即对全文数据的搜索紧张有两种方法：顺序扫描法，全文检索。
顺序扫描：通过笔墨名称也可理解到它的大概搜索办法，即按照顺序扫描的办法查询特定的关键字。
例如给你一张报纸，让你找到该报纸中“RNG”的笔墨在哪些地方涌现过。你肯定须要从头到尾把报纸阅读扫描一遍然后标记出关键字在哪些版块涌现过以及它的涌现位置。
这种办法无疑是最耗时的最低效的，如果报纸排版字体小，而且版块较多乃至有多份报纸，等你扫描完你的眼睛也差不多了。
全文搜索：对非构造化数据顺序扫描很慢，我们是否可以进行优化？把我们的非构造化数据想办法弄得有一定构造不就行了吗？将非构造化数据中的一部分信息提取出来，重新组织，使其变得有一定构造，然后对此有一定构造的数据进行搜索，从而达到搜索相对较快的目的。这种办法就构成了全文检索的基本思路。这部分从非构造化数据中提取出的然后重新组织的信息，我们称之索引。
还以读报纸为例，我们想关注最近英雄同盟S8环球总决赛的新闻，如果都是 RNG 的粉丝，如何快速找到 RNG 新闻的报纸和版块呢？全文搜索的办法便是，将所有报纸中所有版块中关键字进行提取，如\公众EDG\"大众，\"大众RNG\"大众，\公众FW\"大众，\"大众战队\"大众，\"大众英雄同盟\公众等。然后对这些关键字建立索引，通过索引我们就可以对应到该关键词涌现的报纸和版块。把稳差异目录搜索引擎。
二、数据库搜索与全文搜索的比拟
我们的所有数据在数据库里面都有，而且 Oracle、SQL Server 等数据库里也能供应查询检索或者聚类剖析功能，直接通过数据库查询不就可以了吗？确实，我们大部分的查询功能都可以通过数据库查询得到，如果查询效率低下，还可以通过建数据库索引，优化SQL等办法进行提升效率，乃至通过引入缓存来加快数据的返回速率。如果数据量更大，就可以分库分表来分担查询压力。
那为什么还要全文搜索引擎呢？我们紧张从以下几个缘故原由剖析：
数据类型全文索引搜索支持非构造化数据的搜索，可以更好地快速搜索大量存在的任何单词或单词组的非构造化文本。例如 Google，百度类的网站搜索，它们都是根据网页中的关键字天生索引，我们在搜索的时候输入关键字，它们会将该关键字即索引匹配到的所有网页返回；还有常见的项目中运用日志的搜索等等。对付这些非构造化的数据文本，关系型数据库搜索不是能很好的支持。索引的掩护一样平常传统数据库，全文检索都实现的很鸡肋，由于一样平常也没人用数据库存文本字段。进行全文检索须要扫描全体表，如果数据量大的话纵然对SQL的语法优化，也奏效甚微。建立了索引，但是掩护起来也很麻烦，对付 insert 和 update 操作都会重新构建索引。什么时候利用全文搜索引擎：
搜索的数据工具是大量的非构造化的文本数据。文件记录量达到数十万或数百万个乃至更多。支持大量基于交互式文本的查询。需求非常灵巧的全文搜索查询。对高度干系的搜索结果的有分外需求，但是没有可用的关系数据库可以知足。对不同记录类型、非文本数据操作或安全事务处理的需求相对较少的情形。三、三种全文搜索引擎比拟
1、Lucene
Lucene是一个Java全文搜索引擎，完备用Java编写。Lucene不是一个完全的运用程序，而是一个代码库和API，可以很随意马虎地用于向运用程序添加搜索功能。
Lucene通过大略的API供应强大的功能：
可扩展的高性能索引
在当代硬件上超过150GB /小时小RAM哀求 - 只有1MB堆增量索引与批量索引一样快索引大小约为索引文今年夜小的20-30％强大，准确，高效的搜索算法
排名搜索 - 首先返回最佳结果许多强大的查询类型：短语查询，通配符查询，临近查询，范围查询等现场搜索（例如标题，作者，内容）按任何字段排序利用合并结果进行多索引搜索许可同时更新和搜索灵巧的分面，突出显示，连接和结果分组快速，内存效率和缺点容忍的建议可插拔排名模型，包括矢量空间模型和Okapi BM25可配置存储引擎（编解码器）跨平台办理方案
作为Apache容许下的开源软件供应 ，许可您在商业和开源程序中利用Lucene100％-pure Java可用的其他编程措辞中的实现是索引兼容的Apache软件基金会
在Apache软件基金会供应的开源软件项目的Apache社区的支持。
但是Lucene只是一个框架，要充分利用它的功能，须要利用JAVA，并且在程序中集成Lucene。须要很多的学习理解，才能明白它是如何运行的，闇练利用Lucene确实非常繁芜。
2、Solr
Apache Solr是一个基于名为Lucene的Java库构建的开源搜索平台。它以用户友好的办法供应Apache Lucene的搜索功能。作为一个行业参与者近十年，它是一个成熟的产品，拥有强大而广泛的用户社区。它供应分布式索引，复制，负载平衡查询以及自动故障转移和规复。如果它被精确支配然后管理得好，它就能够成为一个高度可靠，可扩展且容错的搜索引擎。很多互联网巨子，如Netflix，eBay，Instagram和亚马逊（CloudSearch）都利用Solr，由于它能够索引和搜索多个站点。
紧张功能列表包括：
全文搜索突出分面搜索实时索引动态群集数据库集成NoSQL功能和丰富的文档处理（例如Word和PDF文件）3、ElasticSearch
Elasticsearch是一个开源（Apache 2容许证），是一个基于Apache Lucene库构建的RESTful搜索引擎。
Elasticsearch是在Solr之后几年推出的。它供应了一个分布式，多租户能力的全文搜索引擎，具有HTTP Web界面（REST）和无架构JSON文档。Elasticsearch的官方客户端库供应Java，Groovy，PHP，Ruby，Perl，Python，.NET和Javascript。
分布式搜索引擎包括可以划分为分片的索引，并且每个分片可以具有多个副本。每个Elasticsearch节点都可以有一个或多个分片，其引擎也可以充当折衷器，将操作委派给精确的分片。
Elasticsearch可通过近实时搜索进行扩展。其紧张功能之一是多租户。
紧张功能列表包括：
分布式搜索多租户剖析搜索分组和聚合四、技能选型
由于Lucene的繁芜性，一样平常很少会考虑它作为搜索的第一选择，打消一些公司须要自研搜索框架，底层须要依赖Lucene。以是这里我们重点剖析 Elasticsearch 和 Solr。
1、特色差异比较
这两个搜索引擎都是盛行的，前辈的的开源搜索引擎。它们都是环绕核心底层搜索库 - Lucene构建的 - 但它们又是不同的。像所有东西一样，每个都有其优点和缺陷，根据您的需求和期望，每个都可能更好或更差。Solr和Elasticsearch都在快速发展，以是，话不多说，先来看下它们的差异清单：
2、综合比较
其余，我们在从以下几个方面来剖析下：
近几年的盛行趋势我们查看一下这两种产品的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的文档组织良好，但它缺少好的示例和清晰的配置解释。五、总结
选型准则概括：
由于易于利用，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精心绘制并供应。
