正文：
最近项目组安排了一个任务，项目中用到了基于 Solr 的全文搜索，但是该 Solr 搜索云项目不稳定，常常查询不出来数据，须要手动全量同步。
而且它还是其他团队在掩护，依赖性太强，导致 Solr 做事一出问题，我们的项目也基本瘫痪，由于所有的依赖查询都无结果数据了。
以是考虑开拓一个适配层，如果 Solr 搜索出问题，自动切换到新的搜索 ES。实在可以通过 Solr 集群或者做事容错等设计来办理该问题。
但是先不考虑本身设计的合理性，领导须要开拓，以是我开始踏上了搭建 ES 做事的道路，从零开始，由于之前完备没打仗过 ES，以是通过本系列来记录下自己的开拓过程。
本篇文章的总体内容大致如下图：
由 ReyCG 精心绘制并供应
什么是全文搜索什么是全文搜索引擎？百度百科中的定义：
全文搜索引擎是目前广泛运用的主流搜索引擎。它的事情事理是打算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中涌现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索办法。这个过程类似于通过字典中的检索字表查字的过程。
从定义中我们已经可以大致理解全文检索的思路了，为了更详细的解释，我们先从生活中的数听说起。
我们生活中的数据总体分为两种：
1、构造化数据：指具有固定格式或有限长度的数据，如数据库，元数据等。
2、非构造化数据：非构造化数据又可称为全文数据，指不定长或无固定格式的数据，如邮件，Word 文档等。
当然有的地方还会有第三种：半构造化数据，如 XML，HTML 等，当根据须要可按构造化数据来处理，也可抽取出纯文本按非构造化数据来处理。
根据两种数据分类，搜索也相应的分为两种：构造化数据搜索和非构造化数据搜索。
对付构造化数据，我们一样平常都是可以通过关系型数据库(MySQL，Oracle 等)的 table 的办法存储和搜索，也可以建立索引。
对付非构造化数据，也即对全文数据的搜索紧张有两种方法：
1、顺序扫描
2、全文检索
顺序扫描：通过笔墨名称也可理解到它的大概搜索办法，即按照顺序扫描的办法查询特定的关键字。
例如给你一张报纸，让你找到该报纸中“RNG”的笔墨在哪些地方涌现过。你肯定须要从头到尾把报纸阅读扫描一遍，然后标记出关键字在哪些版块涌现过以及它的涌现位置。
这种办法无疑是最耗时的最低效的，如果报纸排版字体小，而且版块较多乃至有多份报纸，等你扫描完你的眼睛也差不多了。
全文检索：对非构造化数据顺序扫描很慢，我们是否可以进行优化？把我们的非构造化数据想办法弄得有一定构造不就行了吗？
将非构造化数据中的一部分信息提取出来，重新组织，使其变得有一定构造，然后对此有一定构造的数据进行搜索，从而达到搜索相对较快的目的。
这种办法就构成了全文检索的基本思路。这部分从非构造化数据中提取出的然后重新组织的信息，我们称之索引。
还以读报纸为例，我们想关注英雄同盟 S8 环球总决赛的新闻，如果都是 RNG 的粉丝，如何快速找到 RNG 新闻的报纸和版块呢？
全文检索的办法便是，将所有报纸中所有版块中关键字进行提取，如\公众EDG\"大众，\"大众RNG\"大众，\"大众FW\公众，\"大众战队\"大众，\公众英雄同盟\公众等。
然后对这些关键字建立索引，通过索引我们就可以对应到该关键词涌现的报纸和版块。把稳差异目录搜索引擎。
为什么要用全文搜索搜索引擎之前，有同事问我，为什么要用搜索引擎？我们的所有数据在数据库里面都有，而且 Oracle、SQL Server 等数据库里也能供应查询检索或者聚类剖析功能，直接通过数据库查询不就可以了吗？
确实，我们大部分的查询功能都可以通过数据库查询得到，如果查询效率低下，还可以通过建数据库索引，优化 SQL 等办法提升效率，乃至通过引入缓存来加快数据的返回速率。
如果数据量更大，就可以分库分表来分担查询压力。那为什么还要全文搜索引擎呢？我们紧张从以下几个缘故原由剖析：
数据类型
全文索引搜索支持非构造化数据的搜索，可以更好地快速搜索大量存在的任何单词或单词组的非构造化文本。
例如 Google，百度类的网站搜索，它们都是根据网页中的关键字天生索引，我们在搜索的时候输入关键字，它们会将该关键字即索引匹配到的所有网页返回；还有常见的项目中运用日志的搜索等等。
对付这些非构造化的数据文本，关系型数据库搜索不是能很好的支持。
索引的掩护
一样平常传统数据库，全文检索都实现的很鸡肋，由于一样平常也没人用数据库存文本字段。
进行全文检索须要扫描全体表，如果数据量大的话纵然对 SQL 的语法优化，也奏效甚微。
建立了索引，但是掩护起来也很麻烦，对付 insert 和 update 操作都会重新构建索引。
什么时候利用全文搜索引擎：
1、搜索的数据工具是大量的非构造化的文本数据。
2、文件记录量达到数十万或数百万个乃至更多。
3、支持大量基于交互式文本的查询。
4、须要非常灵巧的全文搜索查询。
5、对高度干系的搜索结果有分外需求，但是没有可用的关系数据库可以知足。
6、对不同记录类型、非文本数据操作或安全事务处理的需求相对较少的情形。
Lucene，Solr，ElasticSearch ？现在主流的搜索引擎大概便是：Lucene，Solr，ElasticSearch。
它们的索引建立都是根据倒排索引的办法天生索引，何谓倒排索引？
维基百科：倒排索引（英语：Inverted index），也常被称为反向索引、置入档案或反向档案，是一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。它是文档检索系统中最常用的数据构造。
Lucene
Lucene 是一个 Java 全文搜索引擎，完备用 Java 编写。Lucene 不是一个完全的运用程序，而是一个代码库和 API，可以很随意马虎地用于向运用程序添加搜索功能。Lucene 通过大略的 API 供应强大的功能：
可扩展的高性能索引：
1、在当代硬件上超过 150GB /小时。
2、小 RAM 哀求，只有 1MB 堆。
3、增量索引与批量索引一样快。
4、索引大小约为索引文今年夜小的 20-30％。
强大，准确，高效的搜索算法：
1、排名搜索：首先返回最佳结果。
2、许多强大的查询类型：短语查询，通配符查询，临近查询，范围查询等。
3、现场搜索（例如标题，作者，内容）。
4、按任何字段排序。
5、利用合并结果进行多索引搜索。
6、许可同时更新和搜索。
7、灵巧的分面，突出显示，连接和结果分组。
8、快速，内存效率和缺点容忍的建议。
9、可插拔排名模型，包括矢量空间模型和 Okapi BM25。
10、可配置存储引擎（编解码器）。
跨平台办理方案：
1、作为 Apache 容许下的开源软件供应 ，许可您在商业和开源程序中利用 Lucene。
2、100％-pure Java。
3、可用的其他编程措辞中的实现是索引兼容的。
Apache 软件基金会：
1、得到 Apache 软件基金会供应的开源软件项目的 Apache 社区的支持。
2、但是 Lucene 只是一个框架，要充分利用它的功能，须要利用 Java，并且在程序中集成 Lucene。
3、须要很多的学习理解，才能明白它是如何运行的，闇练利用 Lucene 确实非常繁芜。
Solr
Apache Solr 是一个基于名为 Lucene 的 Java 库构建的开源搜索平台。它以用户友好的办法供应 Apache Lucene 的搜索功能。
作为一个行业参与者已近十年，它是一个成熟的产品，拥有强大而广泛的用户社区。
它供应分布式索引，复制，负载平衡查询以及自动故障转移和规复。如果它被精确支配然后管理得好，它就能够成为一个高度可靠，可扩展且容错的搜索引擎。
很多互联网巨子，如 Netflix，eBay，Instagram 和亚马逊（CloudSearch）都利用 Solr，由于它能够索引和搜索多个站点。
紧张功能列表包括：
1、全文搜索
2、突出
3、分面搜索
4、实时索引
5、动态群集
6、数据库集成
7、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 可通过近实时搜索进行扩展。其紧张功能之一是多租户。紧张功能列表包括：
1、分布式搜索
2、多租户
3、剖析搜索
4、分组和聚合
Elasticsearch vs Solr 的选择由于 Lucene 的繁芜性，一样平常很少会考虑它作为搜索的第一选择，打消一些公司须要自研搜索框架，底层须要依赖 Lucene。
以是这里我们重点剖析哪一个更好？它们有什么不同？你该当利用哪一个？
历史比较
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 都在快速发展，以是，话不多说，先来看下它们的差异清单：
理解更多：http://solr-vs-elasticsearch.com/
综合比较
其余，我们再从以下几个方面来剖析下：
①近几年的盛行趋势
我们查看一下这两种产品的 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，首先须要理解精确的用例和未来需求，总结它们的每个属性。
记住下面这些要点：
1、由于易于利用，Elasticsearch 在新开拓者中更受欢迎。但是，如果您已经习气了与 Solr 互助，请连续利用它，由于迁移到 Elasticsearch 没有特定的上风。
2、如果除了搜索文本之外还须要它来处理剖析查询，Elasticsearch 是更好的选择。
3、如果须要分布式索引，则须要选择 Elasticsearch。对付须要良好可伸缩性和性能的云和分布式环境，Elasticsearch 是更好的选择。
4、两者都有良好的商业支持（咨询，生产支持，整合等）。
5、两者都有很好的操尴尬刁难象，只管 Elasticsearch 因其易于利用的 API 而更多地吸引了 DevOps 人群，因此可以环绕它创建一个更加生动的工具生态系统。
6、Elasticsearch 在开源日志管理用例中霸占主导地位，许多组织在 Elasticsearch 中索引它们的日志以使其可搜索。虽然 Solr 现在也可以用于此目的，但它只是错过了这一想法。
7、Solr 仍旧更加面向文本搜索。另一方面，Elasticsearch 常日用于过滤和分组，剖析查询事情负载，而不一定是文本搜索。
8、Elasticsearch 开拓职员在 Lucene 和 Elasticsearch 级别上投入了大量精力使此类查询更高效(降落内存占用和 CPU 利用)。
9、因此，对付不仅须要进行文本搜索，而且须要繁芜的搜索韶光聚合的运用程序，Elasticsearch 是一个更好的选择。
10、Elasticsearch 更随意马虎上手，一个下载和一个命令就可以启动统统。Solr 传统上须要更多的事情和知识，但 Solr 最近在肃清这一点上取得了巨大的进步，现在只需努力改变它的荣誉。
11、在性能方面，它们大致相同。我说“大致”，由于没有人做过全面和无偏见的基准测试。对付 95％ 的用例，任何一种选择在性能方面都会很好，剩下的 5％ 须要用它们的特天命据和特定的访问模式来测试这两种办理方案。
12、从操作上讲，Elasticsearch 利用起来比较大略，它只有一个进程。Solr 在其类似 Elasticsearch 的完备分布式支配模式 SolrCloud 中依赖于 Apache ZooKeeper，ZooKeeper 是超级成熟，超级广泛利用等等，但它仍旧是另一个生动的部分。
13、也便是说，如果您利用的是 Hadoop，HBase，Spark，Kafka 或其他一些较新的分布式软件，您可能已经在组织的某个地方运行 ZooKeeper。
14、虽然 Elasticsearch 内置了类似 ZooKeeper 的组件 Xen，但 ZooKeeper 可以更好地防止有时在 Elasticsearch 集群中涌现的恐怖的裂脑问题。
15、公正地说，Elasticsearch 开拓职员已经意识到这个问题，并致力于改进 Elasticsearch 的这个方面。
16、如果您喜好监控和指标，那么利用 Elasticsearch，您将会进入天国。这个东西比新年前夜在时期广场可以挤压的人有更多的指标！
Solr 暴露了关键指标，但远不及 Elasticsearch 那么多。
总之，两者都是功能丰富的搜索引擎，只要设计和实现得当，它们或多或少都能供应相同的性能。
