最近项目组安排了一个任务，项目中用到了基于 Solr 全文搜索，但是应该 Solr 搜索云项目不稳定，数据往往无法查询，需要手动同步。
而且是其他团队维护的，依赖性太强，导致 Solr 当服务出现问题时，我们的项目基本瘫痪，因为所有依赖查询都没有结果数据。
因此，如果考虑开发适配层， Solr 搜索问题，自动切换到新的搜索 ES。其实可以通过 Solr 设计集群或服务容错来解决这个问题。
然而，领导者需要开发而不考虑自己设计的合理性，所以我开始踏上建筑 ES 服务之路，从零开始，因为以前从未接触过 ES，因此，通过本系列记录您的开发过程。
本文总体内容如下：
由 ReyCG 精心绘制和提供
百度百科的定义:
全文搜索引擎是目前应用广泛的主流搜索引擎。其工作原理是计算机索引程序通过扫描文章中的每个单词，为每个单词建立索引，指出文章中单词的数量和位置，当用户查询时，搜索程序根据事先建立的索引进行搜索，并将搜索结果反馈给用户的搜索方法。这个过程类似于通过字典中的搜索表来检查单词。
从定义上，我们可以大致理解全文检索的想法。为了更详细地解释，我们从生活中的数据开始。
我们生活中的数据一般分为两种：
指数据库、元数据等具有固定格式或有限长度的数据。
非结构化数据又称全文数据，是指邮件等不定长或不定格式的数据，Word 文档等。
当然，有些地方会有第三种:半结构化数据，比如 XML，HTML 等待，可根据需要进行结构化数据处理，也可根据非结构化数据提取纯文本进行处理。
搜索也分为结构化数据搜索和非结构化数据搜索两类。
对于结构化数据，我们通常可以使用关系数据库(MySQL，Oracle 等)的 table 存储和搜索的方式，也可以建立索引。
搜索非结构化数据有两种主要方法：
它的一般搜索方法也可以通过文的搜索方法，即按顺序扫描查询特定的关键字。
例如，给你一份报纸，让你在报纸中找到RNG文字出现在哪里。你必须从头到尾扫描报纸，然后标记关键字出现在哪些部分和它的位置。
这种方法无疑是最耗时、最低效的。如果报纸的排版字体很小，而且有很多部分，甚至有很多报纸，扫描后你的眼睛几乎是一样的。
扫描非结构化数据的顺序非常慢。我们能优化它吗？我们不能找到一种方法来使我们的非结构化数据具有一定的结构吗？
提取部分非结构化数据信息，重新组织，使其具有一定的结构，然后搜索具有一定结构的数据，以达到相对较快的搜索目的。
这种方式就构成了全文检索的基本思路。这部分从非结构化数据中提取出的然后重新组织的信息，我们称之索引。
以阅读报纸为例，我们想关注英雄联盟 S8 如果全球总决赛的新闻都是， RNG 如何快速找到粉丝？ RNG 报纸和新闻部分呢？
全文检索的方法是提取报纸所有部分的关键字，如"EDG"，"RNG"，"FW"，"战队"，"英雄联盟"等。
然后为这些关键字建立索引，我们可以通过索引对应关键字的报纸和部分。注意区分目录搜索引擎。
之前有同事问我为什么要用搜索引擎。我们所有的数据都在数据库中，而且 Oracle、SQL Server 还可以在数据库中提供查询检索或聚类分析功能，不能通过数据库直接查询吗？
事实上，我们的大部分查询功能都可以通过数据库查询获得。如果查询效率低，我们也可以通过建立数据库索引来优化 SQL 通过引入缓存来提高效率，甚至加速数据的返回。
如果数据量较大，可以分库分表分担查询压力。那为什么要有全文搜索引擎呢？我们主要分析以下原因:
全文索引搜索支持非结构化数据搜索，可以更好地快速搜索任何单词或短语的大量非结构化文本。
例如 Google，百度网站搜索，他们根据网页上的关键字生成索引，我们在搜索时输入关键字，他们会返回所有与索引匹配的网页；以及常见的项目应用日志搜索等。
关系数据库搜索对这些非结构化数据文本没有很好的支持。
一般传统数据库，全文检索都很鸡肋，因为一般没有人使用数据库存文本字段。
全文检索需要扫描整个表格，即使数据量大 SQL 语法优化也收效甚微。
索引已经建立维护起来也很麻烦 insert 和 update 操作将重建索引。
全文搜索引擎何时使用：
搜索的数据对象是大量的非结构化文本数据。
数十万或数百万甚至更多的文件记录。
基于交互式文本支持大量查询。
全文搜索查询需要非常灵活。
对高度相关的搜索结果有特殊要求，但没有可用的关系数据库。
对不同记录类型、非文本数据操作或安全事务处理的需求相对较少。
现在主流搜索引擎大概是:Lucene，Solr，ElasticSearch。
它们的索引都是根据倒排索引建立的什么是倒排索引？
维基百科:倒排索引(英语:Inverted index），它也通常被称为反向索引，放置在文档或反向文档中，是一种存储在一个文档或一组文档中存储单词的索引方法。它是文档检索系统中最常用的数据结构。
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 真的很复杂。
Apache Solr 是基于名称的 Lucene 的 Java 库中构建的开源搜索平台。它使用用户好的方式提供 Apache Lucene 的搜索功能。
作为一个行业参与者已近十年，它是一个成熟的产品，拥有强大而广泛的用户社区。
它提供分布式索引，复制，负载平衡查询以及自动故障转移和恢复。如果它被正确部署然后管理得好，它就能够成为一个高度可靠，可扩展且容错的搜索引擎。
很多互联网巨头，如 Netflix，eBay，Instagram 和亚马逊（CloudSearch）都使用 Solr，因为它能够索引和搜索多个站点。微信搜索公众号：Java项目精选，回复：java 领取资料 。
主要功能列表包括：
全文搜索
突出
分面搜索
实时索引
动态群集
数据库集成
NoSQL 功能和丰富的文档处理（例如 Word 和 PDF 文件）
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。
所以这里我们重点分析哪一个更好？它们有什么不同？你应该使用哪一个？
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，首先需要了解正确的用例和未来需求，总结它们的每个属性。
记住下面这些要点：
由于易于使用，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 那么多。
总之，两者都是功能丰富的搜索引擎，只要设计和实现得当，它们或多或少都能提供相同的性能。
作者：JaJian
出处：www.cnblogs.com/jajian/p/9801154.html
—————END—————资料分享
其实B站已经要非常多资料，但是还是有些小伙伴找不到，资料多了也眼花缭乱，小编找了一批某机构4个月付费培训教程：视频、代码、课件、软件，统统都有，很适合新手学习 。
如何获取？
1. 识别并关注下方公众号，建议复制关键字；2. 在下面公众号后台回复关键字「」。
👆长按上方二维码 2 秒
回复「666」即可获取资料❤️给个「在看」，是对我最大的支持