Solr精心绘制并提供什么是全文搜索引擎(组图)

　　Solr精心绘制并提供什么是全文搜索引擎(组图)

　　最近，项目团队安排了一项任务。在项目中使用了基于Solr的全文本搜索。但是，Solr搜索云项目不稳定，通常不会查询数据，因此需要手动完全同步。

　　

　　此外，它仍然由其他团队维护，并且依赖性过强。 Solr服务失败后，我们的项目就会基本瘫痪，因为所有相关查询都没有结果数据。

　　因此请考虑开发适应层。如果Solr搜索失败，它将自动切换到新的搜索ES。实际上，可以通过Solr群集或服务容错设计来解决此问题。

　　但是我没有考虑自己设计的合理性。领导者需要发展，所以我从头开始构建ES服务，因为我以前从未接触过ES，因此我将通过本系列记录自己的经验。开发过程。

　　本文文章的总体内容大致如下：

　　

　　由ReyCG精心绘制并提供

　　什么是全文搜索

　　什么是全文搜索引擎？百度百科中的定义：

　　全文搜索引擎是当前广泛使用的主流搜索引擎。它的工作原理是计算机索引程序扫描文章中的每个单词，并为每个单词建立一个索引，指示文章中单词的数量和位置。当用户查询时，搜索程序基于。预先建立索引进行搜索，并将搜索结果反馈给用户的搜索方法。此过程类似于通过词典中的搜索单词列表查找单词的过程。

　　从定义来看，我们已经可以大致理解全文搜索的思想了。为了更详细地说明，让我们从生活中的数据开始。

　　我们生活中有两种类型的数据：

　　当然，在某些地方还会有第三种类型：半结构化数据（例如XML，HTML等），可以根据需要将其作为结构化数据进行处理，或者可以将纯文本提取并处理为非结构化数据。

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

　　对于结构化数据，我们通常可以存储和搜索关系数据库的表（MySQL，Oracle等），或创建索引。

　　对于非结构化数据（即搜索全文本数据），有两种主要方法：

　　顺序扫描：您也可以通过文本名称了解常规搜索方法，即以顺序扫描方式搜索特定的关键字。

　　例如，给您一份报纸，找出报纸中“ RNG”一词出现的位置。您绝对需要从头到尾扫描报纸，然后标记出现关键词和出现关键词的部分。

　　无疑，这种方法最耗时，最无效。如果报纸的排版很小，并且有很多版块甚至是几本报纸，那么您在翻新眼睛之后几乎会是相同的。

　　全文本搜索：非结构化数据的顺序扫描非常慢，我们可以对其进行优化吗？仅仅使我们的非结构化数据具有一定的结构还不够吗？

　　从非结构化数据中提取部分信息，对其进行重组以使其具有一定的结构，然后以一定的结构搜索数据，从而达到相对快速搜索的目的。

　　这种方法构成了全文本搜索的基本思想。这部分信息是从非结构化数据中提取出来然后进行重组的，我们称之为索引。

　　以阅读报纸为例。我们想关注英雄联盟S8全球总决赛的消息。如果我们都是RNG的拥护者，我们如何快速找到RNG新闻的报纸和栏目？

　　全文搜索方法是在所有报纸的所有部分中提取关键字，例如“ EDG”，“ RNG”，“ FW”，“ Team”，“ League of Legends”等。

　　然后为这些关键字建立一个索引，通过该索引，我们可以与关键词中出现的报纸和版块相对应。请注意目录搜索引擎之间的区别。

　　为什么要使用全文搜索搜索引擎

　　之前，一位同事问我，为什么要使用搜索引擎？我们所有的数据都在数据库中，Oracle，SQL Server和其他数据库也可以提供查询检索或集群分析功能。可以吗？

　　实际上，我们的大多数查询功能都可以通过数据库查询获得。如果查询效率低，您还可以通过建立数据库索引，优化SQL等来提高效率，甚至可以通过引入缓存来加快数据返回速度。

　　如果数据量较大，则可以拆分数据库和表以共享查询压力。那为什么我们需要全文搜索引擎？我们主要从以下原因进行分析：

　　数据类型

　　全文索引搜索支持非结构化数据的搜索，这可以更好地快速搜索存在的任何单词或单词组的大量非结构化文本。

　　例如，谷歌和百度网站搜索所有基于网页中关键字的索引。当我们在搜索时输入关键字时，它们将返回所有与关键字匹配的网页，即索引；在常见项目中还可以搜索应用程序日志，等等。

　　对于这些非结构化数据文本，没有很好地支持关系数据库搜索。

　　维护索引

　　在一般的传统数据库中，全文搜索非常无味，因为通常没有人使用数据清单文本字段。

　　全文搜索需要扫描整个表。如果数据量很大，即使优化了SQL语法，也几乎没有效果。

　　索引已建立，但是维护很麻烦。索引将被重建以进行插入和更新操作。

　　何时使用全文搜索引擎：

　　Lucene，Solr，ElasticSearch？

　　当前的主流搜索引擎可能是：Lucene，Solr，ElasticSearch。

　　

　　他们的索引创建基于倒排索引方法。什么是倒排索引？

　　维基百科：倒排索引（英语：倒排索引），也通常称为倒排索引，倒排文件或倒排文件，是一种索引方法，用于在全文搜索中存储单词。文档或一组文档。它是文档检索系统中最常用的数据结构。

　　Lucene

　　Lucene是Java全文搜索引擎，完全用Java编写。 Lucene并不是一个完整的应用程序，而是可以轻松用于向该应用程序添加搜索功能的代码库和API。 Lucene通过简单的API提供了强大的功能：

　　可扩展的高性能指数：

　　强大，准确，高效的搜索算法：

　　跨平台解决方案：

　　Apache Software Foundation：

　　需要大量的学习和理解才能了解其工作原理。熟练使用Lucene确实很复杂。

　　Solr

　　Apache Solr是基于Java库（称为Lucene）的开源搜索平台。它以用户友好的方式提供Apache Lucene的搜索功能。

　　作为行业参与者近十年，它是一种成熟的产品，拥有强大而广泛的用户社区。

　　它提供分布式索引，复制，负载平衡查询以及自动故障转移和恢复。如果部署和管理得当，它将成为高度可靠，可扩展且容错的搜索引擎。

　　Netflix，eBay，Instagram和Amazon（CloudSearch）等许多互联网巨头都使用Solr，因为它可以索引和搜索多个站点。

　　主要功能列表包括：

　　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与Solr选择

　　由于Lucene的复杂性，很少将其视为搜索的首选。一些公司需要自己开发搜索框架，底层需要依靠Lucene。

　　因此，在这里我们关注的是哪个更好？它们有何不同？您应该使用哪一个？

　　

　　历史比较

　　Apache Solr是一个成熟的项目，具有庞大而活跃的开发和用户社区以及Apache品牌。

　　Solr于2006年首次向开源发布，长期以来一直占据搜索引擎领域，并且是需要搜索功能的任何人的首选。

　　它的成熟度转化为丰富的功能，而不仅仅是简单的文本索引和搜索；例如构面，分组，强大的过滤，可插入文档处理，可插入搜索链组件，语言检测等。

　　Solr多年来一直主导着搜索领域。然后，在2010年左右，Elasticsearch成为市场上的另一种选择。

　　当时，它没有Solr稳定，没有Solr那么深，没有分享想法，品牌等。

　　Elasticsearch很年轻，但是也有一些优势。 Elasticsearch建立在更现代的原则上，针对更现代的用例，旨在使处理大型索引和高查询率变得更容易。

　　此外，由于它还太年轻并且没有社区可以合作，因此它可以自由前进，而无需与其他人（用户或开发人员）达成任何共识或合作，向后兼容或任何其他更成熟的软件通常必须处理该软件

　　因此，它在Solr之前公开了一些非常流行的功能（例如，近实时搜索，英语：近实时搜索）。

　　从技术上讲，NRT搜索功能确实来自Lucene，Lucene是Solr和Elasticsearch使用的基本搜索库。

　　具有讽刺意味的是，由于Elasticsearch首先公开了NRT搜索，所以人们将NRT搜索与Elasticsearch关联起来。

　　尽管Solr和Lucene都是同一个Apache项目的一部分，但人们首先会期望Solr具有如此苛刻的功能。

　　特征差异的比较

　　这两个搜索引擎都是流行的高级开放源代码搜索引擎。它们都是围绕核心底层搜索库Lucene构建的，但是它们是不同的。

　　就像所有事物一样，每种事物都有其优点和缺点，并且取决于您的需求和期望，每种事物都可能好或坏。

　　Solr和Elasticsearch都在快速发展，所以不用多说，让我们先看一下它们之间的差异列表：