前言

最近项目组安排了一个任务，项目中用到了基于 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 ？

现在主流搜索引擎大概是: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，因为它能够索引和搜索多个站点。微信搜索公众号：Java项目精选，回复：java 领取资料 。

主要功能列表包括：

• 全文搜索

• 突出

• 分面搜索

• 实时索引

• 动态群集

• 数据库集成

• 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。

所以这里我们重点分析哪一个更好？它们有什么不同？你应该使用哪一个？

历史比较

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

ps：如果您觉文章有用，动动小手点个在看，点个赞再走吧！

—————END—————

资料分享

其实B站已经要非常多资料，但是还是有些小伙伴找不到，资料多了也眼花缭乱，小编找了一批某机构4个月付费培训教程：视频、代码、课件、软件，统统都有，很适合新手学习 。

如何获取？

1. 识别并关注下方公众号，建议复制关键字；
2. 在下面公众号后台回复关键字「666」。

👆长按上方二维码 2 秒
回复「666」即可获取资料

❤️给个「在看」，是对我最大的支持