搜索引擎优化毕业论文(搜索引擎应用场景在全文检索、加快检索效率方面应用广泛而本小节)

　　搜索引擎优化毕业论文(搜索引擎应用场景在全文检索、加快检索效率方面应用广泛而本小节)

　　搜索引擎设计

　　

　　一、前言

　　所谓搜索引擎是一种检索技术，它根据用户的需求和一定的算法，采用特定的策略，从互联网上检索信息并反馈给用户。搜索引擎应用场景广泛应用于全文检索，加快检索效率。本节主要介绍我们工作中使用较多的两个中间件Solr和ElasticSearch。

　　二、搜索引擎组件介绍

　　2.1 常见场景

　　在项目开发过程中，遇到全文搜索加速搜索效率业务场景时，经常会用到Solr或者ES（ElasticSearch）组件来解决问题，那么我们先简单了解一下相关设计

　　全文搜索：一般网络用户适合使用全文搜索引擎。这种搜索方式方便、简单，易于获取所有相关信息。但是，搜索到的信息过于复杂，需要用户一一浏览和识别所需信息。尤其是当用户没有明确的搜索意图时，这种搜索方式非常有效。如果是基于全文搜索业务开发，无疑可以使用更成熟的搜索引擎来快速上手并实现其功能。

　　检索效率：当开发过程中数据量比较大，使用分布式数据库、添加库索引、SQL优化等效率提升不明显时，很多开发者会选择非关系型数据存储方式（如Solr、ES） ,Mongdb) 提高​​检索效率

　　2.2 如何选择组件

　　荧光素

　　Lucene 是一种全文搜索引擎架构，提供了完整的查询引擎、索引引擎和部分文本分析引擎。Lucene 为开发者提供了相当完善的工具包，可以轻松实现强大的全文搜索功能

　　索尔：

　　Solr是Apache下的顶级开源项目，用Java开发，是一个基于Lucene的全文搜索服务器。Solr 提供了比 Lucene 更丰富的查询语言，同时实现了可配置性、可扩展性以及索引和搜索性能的优化。Solr可以独立运行，运行在Jetty、Tomcat等Servlet容器中，Solr索引实现非常简单。使用 POST 方法将描述 Field 及其内容的 XML 文档发送到 Solr 服务器。Solr根据xml文档进行增删改查。指数。Solr搜索只需要发送一个HTTP GET请求，然后解析Solr返回的Xml、json等格式的查询结果来组织页面布局。Solr 不提供构建 UI 的功能。

　　弹性搜索：

　　ElasticSearch 是一个基于 Lucene 框架的分布式搜索引擎，也是为数不多的基于 JSON 索引的搜索引擎之一。ElasticSearch 特别适合在云计算平台上使用

　　三者的概念

　　1）三者之间的联系，solr和elasticsearch都是基于Lucene的！

　　2）Lucene 是一个开源的全文搜索引擎工具包。它不是一个完整的全文搜索引擎。Lucene 提供了完整的查询引擎和索引引擎。目的是为软件开发者提供一个简单易用的Toolkit，方便​​地在目标系统中实现全文搜索功能，或者构建一个基于Lucene的全文搜索引擎。

　　solr 和 elasticsearch 都是基于这个工具包制作的一些包

　　3）Solr 是一个基于 Lucene 的查询服务器，带有 HTTP 接口，封装了很多 Lucene 的细节。您自己的应用程序可以直接使用HTTP GET/POST 请求如.../solr?q=abc 进行查询。维护和修改索引。目标是构建企业级搜索引擎系统。它是一个可以独立运行的搜索引擎服务。Solr 可以快速构建企业搜索引擎。Solr还可以高效的完成网站的搜索功能。

　　4）Elasticsearch 也是一个基于全文搜索引擎 Apache Lucene 的搜索引擎。采用的策略是分布式实时文件存储，每个字段都有索引，以便于搜索。

　　技术选型 Lucene VS Solr VS Elasticsearch(ES) Lucene使用起来比较灵活，但是需要处理搜索引擎系统架构和其他附加功能的实现。

　　Solr 为您做的更多，但它是一个高级框架。Lucene的很多新特性无法及时向上传递，所以有时候你可能会发现自己需要一个Lucene支持的功能，但是在Solr上却看不到相关的接口。

　　Solr使用zookpper进行分布式管理，elasticsearch本身具有分布式协调管理功能；solr比elasticsearch更全面，solr官方提供的功能更多，而elasticsearch本身更注重核心功能，高级功能多由第三方插件提供。假如; solr 在传统搜索应用中表现优于elasticsearch，elasticsearch 在实时搜索应用中表现优于solr！（常见面试题）

　　一般总结：

　　传统搜索：从静态数据库中过滤出符合条件的结果。这样的结果通常是不可变的和静态的。（可选的solr）

　　实时搜索：是指用户的搜索结果实时变化。（可选）

　　就个人而言，我仍然需要看一下数字。即使实时搜索量不大，solr也可以。

　　Lucene：可以实现搜索，但是需要大量的开发工作。索引库的维护优化、查询优化等问题需要我们自己解决。不建议

　　三、搜索引擎组件设计

　　日志记录在项目开发中是必不可少的。下面以日志监控为例来说明如何使用搜索引擎组件。

　　问题：如何处理系统API调用和系统操作日志？

　　3.1 我们可以分析一下这类日志的以下特点：

　　大量日志

　　需要实时统计，效率比较高

　　少量数据丢失，不影响统计

　　日志需要以图形方式显示

　　...

　　3.2 组件选择后，我们可以初步选择以下分类进行本场景的技术选择

　　数据库：mongo、Redis

　　消息队列：kafka

　　搜索引擎：ES、MQ

　　日志推送：filebeat（小）、flume（数据量大有优势，大数据技术栈，支持分布式）

　　部署方式：docker，脚本安装

　　3.3 方案选择，我们可以用普通的ELK来解决（组件略有调整）

　　ELK解决方案（可以解决微服务的分布式日志）：Elasticsearch、Logstash、Kibana

　　其中，Elasticsearch是一个基于Lucene，分布式，通过Restful交互的近实时搜索平台框架。

　　Logstash 是 ELK 的中央数据流引擎。用于从不同的目标（文件/数据存储/MQ）采集不同格式的数据，过滤后支持输出到不同的目的地（文件/MQ/redis/elasticsearch/kafka等）。

　　Kibana可以通过友好的页面展示elasticsearch数据，提供实时分析功能

　　

　　

　　上述架构对数据源服务器的性能影响较大，因为需要在需要采集的数据源服务器上安装运行Logsash，然后对采集到的数据进行实时过滤。过滤过程耗时且资源密集。过滤完成后转入ES。以下是优化后的架构图

　　

　　

　　架构图中加入了Kafka作为缓冲存储功能。运行在数据源上的Logstash采集器采集数据后，作为生产者直接传输给Kafka。注意这里省略了过滤动作，这样对数据源服务器的影响最小，因为Kafka大家都知道它的读写性能非常高。另一方面，我们需要独立部署一个专用的消费者Logstash。这个Logstash负责对过滤后的数据进行过滤和传输给ES。Kibana 仍会读取 ES 数据以供稍后显示。

　　这种架构不仅性能好，而且耦合度低。（另外整个部署采用docker部署，尽量解决运维学习成本，为了不影响应用效率，es-kibana等组件和应用在不同的服务器上）

　　ES为Kibana的展示和分析的效率提供了重要的保障，可以实时展示数据动态。

　　四、总结

　　本节简要介绍 Solr 和 ES 两个组件。可以根据具体业务选择搜索引擎组件。同时介绍了ELK解决方案采集日志，了解ES组件定位。搜索引擎在开发中被广泛使用。你可以了解更多。组件