php 搜索引擎优化(全文搜索什么是全文搜索引擎？搜索云项目不稳定 )

　　php 搜索引擎优化(全文搜索什么是全文搜索引擎？搜索云项目不稳定

)

　　近日，项目组安排了一项任务。项目中使用了基于 Solr 的全文搜索。但是Solr搜索云项目不稳定，不能频繁查询数据，需要手动全量同步。

　　

　　而且现在还在由其他团队维护，依赖太强，导致Solr服务出现问题，我们的项目基本瘫痪，因为所有依赖的查询都没有结果数据。

　　所以考虑开发一个适配层，如果Solr的搜索出现问题，会自动切换到新的搜索ES。其实这个问题可以通过Solr集群或者服务容错的设计来解决。

　　但是不考虑自己设计的合理性，leader需要开发，所以开始走上搭建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。

　　

　　他们的索引建立是基于倒排索引的方式生成索引，什么是倒排索引？

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

　　Lucene

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

　　可扩展的高性能索引：

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

　　跨平台解决方案：

　　阿帕奇软件基金会：

　　要理解它的工作原理需要大量的学习和理解，而精通 Lucene 确实很复杂。

　　索尔

　　Apache Solr 是一个基于名为 Lucene 的 Java 库构建的开源搜索平台。它以用户友好的方式提供 Apache Lucene 的搜索功能。

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

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

　　Netflix、eBay、Instagram 和亚马逊 (CloudSearch) 等许多互联网巨头都使用 Solr，因为它能够索引和搜索多个站点。

　　主要功能列表包括：

　　弹性搜索

　　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 之前就暴露了一些非常流行的功能（例如，Near Real-Time Search，英文：Near Real-Time Search）。

　　从技术上讲，NRT 搜索的强大功能确实来自于 Solr 和 Elasticsearch 使用的底层搜索库 Lucene。

　　具有讽刺意味的是，人们将 NRT 搜索与 Elasticsearch 联系在一起，因为 Elasticsearch 首次公开了 NRT 搜索。

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

　　特征差异比较

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

　　像所有事物一样，每个事物都有其优点和缺点，并且每个事物都可能更好或更差，具体取决于您的需求和期望。

　　Solr 和 Elasticsearch 都在迅速发展，因此，事不宜迟，这里列出了它们的区别：