全文检索 以及 lucene solr ElasticSearch 区别

什么是全文搜索引擎？

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

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

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

结构化数据： 指具有固定格式或有限长度的数据，如数据库，元数据等。
非结构化数据： 非结构化数据又可称为全文数据，指不定长或无固定格式的数据，如邮件，word文档等。
当然有的地方还会有第三种：半结构化数据，如XML，HTML等，当根据需要可按结构化数据来处理，也可抽取出纯文本按非结构化数据来处理。

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

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

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

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

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

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

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

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

数据类型
全文索引搜索支持非结构化数据的搜索，可以更好地快速搜索大量存在的任何单词或单词组的非结构化文本。
例如 Google，百度类的网站搜索，它们都是根据网页中的关键字生成索引，我们在搜索的时候输入关键字，它们会将该关键字即索引匹配到的所有网页返回；还有常见的项目中应用日志的搜索等等。对于这些非结构化的数据文本，关系型数据库搜索不是能很好的支持。

索引的维护
一般传统数据库，全文检索都实现的很鸡肋，因为一般也没人用数据库存文本字段。进行全文检索需要扫描整个表，如果数据量大的话即使对SQL的语法优化，也收效甚微。建立了索引，但是维护起来也很麻烦，对于 insert 和 update 操作都会重新构建索引。

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

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

ElasticSearch简介

Elasticsearch 是一个开源的搜索引擎，建立在一个全文搜索引擎库 Apache Lucene™ 基础之上。

它使全文检索变得简单， 通过隐藏 Lucene 的复杂性，取而代之的提供一套简单一致的 RESTful API。

Elasticsearch 不仅仅只是一个全文搜索引擎。 还具有如下功能：

一个分布式的实时文档存储，每个字段 可以被索引与搜索
一个分布式实时分析搜索引擎
能胜任上百个服务节点的扩展，并支持 PB 级别的结构化或者非结构化数据
可以把ElasticSearch看成是一个搜索引擎数据库，有数据库知识即可快速入门

ElasticSearch应用场景
1、维基百科

2、Stack Overflow（国外的技术问答论坛）

3、GitHub（开源代码管理），搜索上千亿行代码

4、电商网站，检索商品

5、日志数据分析，logstash采集日志，ES进行复杂的数据分析（ELK技术，elasticsearch+logstash+kibana）

主要用于近实时的全文搜索和数据分析

Solr简介

Apache Solr基于业界大名鼎鼎的java开源搜索引擎Lucene，Lucene更多的是一个软件包，还不能称之为搜索引擎，而solr则完成对lucene的封装，是一个真正意义上的搜索引擎框架。在过去的十年里，solr发展壮大，拥有广泛的用户群体。solr提供分布式索引、分片、副本集、负载均衡和自动故障转移和恢复功能。如果正确部署，良好管理，solr就能够成为一个高可靠、可扩展和高容错的搜索引擎。不少互联网巨头在使用，如Netflix，eBay，Instagram和Amazon（CloudSearch）。

ElasticSearch vs Solr
热度对比
两者在google中的搜索热度，在2013年后，Elasticsearch与Solr相比具有很大的吸引力，但Solr仍然很流行，Solr具有强大的开源社区支持。

安装与配置
相对来说，Elasticsearch更易于安装和配置，学习成本更低。Solr的安装和配置比ElasticSearch要复杂一些。

索引和搜索
数据源
Solr接受来自不同来源的数据，包括XML文件，逗号分隔符（CSV）文件和从数据库中的表提取的数据以及常见的文件格式（如Microsoft Word和PDF）。

Elasticsearch 还支持其他来源的数据，例如ActiveMQ，AWS SQS，DynamoDB（Amazon NoSQL），FileSystem，Git，JDBC，JMS，Kafka，LDAP，MongoDB，neo4j，RabbitMQ，Redis，Solr和Twitter。还有各种插件可用。

搜索
Solr专注于文本搜索，而Elasticsearch则常用于查询、过滤和分组分析统计，Elasticsearch背后的团队也努力让这些查询更为高效。

因此当比较两者时，对那些不仅需要文本搜索，同时还需要复杂的时间序列搜索和聚合的应用程序而言，毫无疑问Elasticsearch是最佳选择。

索引
两者都支持使用停用词和同义词来匹配文档。

在Solr中，索引间进行join必须是单个分片和其他节点上的副本集进行关联来搜索文档间关系（例如SQL连接）。而Elasticsearch提供更高效的has_children和top_children查询来检索这样的相关文档。

可扩展性和分布式
Elasticsearch非常易于扩展，拥有足够多的需要大集群的使用案例。

Solr 基于Apache ZooKeeper也实现了类似ES的分布式部署模式。ZooKeeper是成熟和广泛使用的独立应用程序。

相对比，Elasticsearch有一个内置的类似ZooKeeper的名为Zen的组件，通过内部的协调机制来维护集群状态。

可以说Elasticsearch天生就是分布式的，是转为云而设计，是分布式首选。

社区
Solr有一个广泛的开源社区。任何人都可以贡献给Solr，新的Solr开发人员或代码提交者只能根据功能选择。

Elasticsearch在技术上是开源的，所有贡献者都可以访问源代码，用户可以进行更改并提供。但最终的变化由Elastic（运行Elasticsearch和其他软件的公司）的员工确认和完成。因此，Elasticsearch更多地由单个公司驱动，而不是整个社区。

Solr贡献者和提交者跨越多个组织，而Elasticsearch提交者仅来自Elastic。还有人指出，Solr的强大社区有一个健康的项目管道和许多知名公司参与。这些成员还通过在整个开发和工程过程中做出贡献来投资该平台。

两者都有很好的用户群和丰富的开发人员社区，但ElasticSearch相较于Solr更新。 Solr已经存在了更长的时间，所以它的生态系统是发达的，拥有更大的用户群。

选Solr 还是 Elasticsearch?
Elasticsearch由于其易用性而在较新的开发人员中更受欢迎
但是如果你已经在使用solr了，请继续使用它，因为迁移到Elasticsearch并不会带来具体的优势
如果您需要它来处理分析查询以及搜索文本，Elasticsearch是更好的选择，特别是收集日志，做分析处理

结论
基于以下几个原因，建议使用ElasticSearch

1、易于安装和配置，学习和使用成本较低（ElasticSearch入门简单，只要有数据库和编程知识，solr略复杂）；

2、支持单机也支持分布式，内置了分布式组件，降低了学习和使用成本（Solr通过Apache ZooKeeper实现分布式，需要额外的学习成本）；

3、除了搜索之外，ElasticSearch还支持实时的过滤、分析、统计功能，可以为我们后续的功能扩展提供支持；

4、在创建索引的同时进行搜索，ElasticSearch比Solr更优，而我们的场景需要实时的创建索引（Solr创建索引的时候会堵塞IO）；

5、随着数据量增加ElasticSearch无明显的性能损失（Solr会明显变慢）；

https://www.cnblogs.com/gezifeiyang/p/10999238.html
https://www.cnblogs.com/jajian/p/9801154.html