seq搜索引擎优化至少包括那几步?(第一章Solr简单介绍速览：·搜索引擎处理的数据特性)

　　seq搜索引擎优化至少包括那几步?(第一章Solr简单介绍速览：·搜索引擎处理的数据特性)

　　第一章是对Solr的简单介绍

　　本章快速概述：

　　·搜索引擎处理的数据特征

　　·常见的搜索引擎用例

　　·Solr核心模块介绍

　　·选择Solr的理由

　　·功能概述

　　伴随着社交媒体、云计算、移动互联网、大数据等技术的快速发展。我们正在迎来一个激动人心的计算时代。软件架构师开始面临的主要挑战之一是如何处理庞大的全球用户群生成和使用的海量数据。此外，用户开始期望在线软件应用程序将始终稳定可用。并且可以一直保持响应，这个阶段的应用对扩展性和稳定性提出了更高的要求。为了满足这些需求，一些专门的非关系型数据存储和处理技术被统称为NoSQL（Not Only SQL）技术。开始获得越来越多的青睐。这些系统并不强制要求所有数据都存储在之前已成为事实上的标准的关系数据模型中。它共享一个通用的设计模式。匹配数据存储处理引擎和特定数据类型。换句话说，NoSQL 技术针对特定数据类型的特定类型问题进行了性能优化。由于对可扩展性和性能的需求不断增加，各种 NoSQL 技术和传统关系型数据库开始混合使用。这样的跨界架构越来越流行。NoSQL 技术针对处理特定数据类型的特定类型问题进行了性能优化。由于对可扩展性和性能的需求不断增加，各种 NoSQL 技术和传统关系型数据库开始混合使用。这样的跨界架构越来越受欢迎。NoSQL 技术针对处理特定数据类型的特定类型问题进行了性能优化。由于对可扩展性和性能的需求不断增加，各种 NoSQL 技术和传统关系型数据库开始混合使用。这样的跨界架构越来越受欢迎。

　　一种数据处理解决方案可以吃遍全世界的日子已经一去不复返了。

　　本书主要讨论一种特殊的NoSQL技术。即 Apache Solr。与她的其他非关系型兄弟一样，Solr 针对特定类型的问题进行了优化。具体来说，Solr 是一种可扩展的高速部署，针对搜索海量文本中心数据和对返回结果的相关性进行排序进行了优化。

　　这句话读起来有点混乱。只是没关系。让我们分解一下这个定义中的亮点：

　　可扩展性：Solr 可以将索引和查询处理操作分发到集群中的多个服务器。

　　·高速部署：Solr是开源软件，安装配置非常方便。可以直接根据安装包中的Sample配置启动。

　　·优化搜索功能：Solr搜索速度够快。对于复杂的搜索查询，Solr 可以实现亚秒级处理。通常一个复杂的查询可以在几十毫秒内处理

　　·海量文本：Solr专为处理百万级别的海量文本而设计，能够很好地处理海量数据。

　　文本中心的数据：Solr 针对搜索收录自然语言的文本内容（例如电子邮件）进行了优化。网页、简历、PDF 文档，或推特、微博、博客等社交内容，都适合用 Solr 处理。

　　·结果按相关性排序：Solr的搜索结果按照结果文档与用户查询的相关程度进行排序，保证最相关的结果会先返回。

　　在本书中，您将学习如何使用 Solr 来设计和实现可扩展的搜索解决方案。

　　我们的学习之旅从了解 Solr 支持的数据类型和典型用例开始。

　　这样你就可以更好地了解 Solr 在整个现代软件应用架构全景中的位置，以及 Solr 旨在处理哪些问题。

　　1.1我需要搜索引擎吗？

　　我们推测你已经有了一些使用搜索引擎的想法，否则你不会打开这本书。所以。我们不浪费时间去弄清楚你为什么开始考虑 Solr，让我们直接讨论一些干货。查看数据和用例的各个方面。在决定是否使用搜索引擎之前，您必须回答哪些问题？这最终将归结为如何深入了解您的数据和您的用户。选择合适的技术，同时满足两者的需求。

　　让我们从讨论哪些数据属性适合搜索引擎开始。

　　1.1.1 在文本中心管理数据

　　合理选择与数据匹配的存储和处理引擎，是现代软件应用架构的标志性要求之一。假设你是一个优秀的程序员，那么你应该知道根据数据在算法中的使用方式来选择最合适的数据结构。例如，假设您需要实现高速随机搜索，则不会使用链表结构来存储数据。

　　同样的原则也适用于搜索引擎的选择。以下是适合使用 Solr 等搜索引擎处理的数据的四个主要特征：

　　文本中心的数据

　　读取的数据远多于写入的数据

　　面向文档的数据

　　灵活的架构

　　或许这里应该增加第五个数据特征，即：海量数据。那就是“大数据”，但我们主要关注的是 Solr 与其他 NoSQL 技术不同的主要特性。处理大量数据的能力并不是它们的主要区别之一。

　　虽然这里有像 Solr 这样的搜索引擎可以有效处理的数据类型的四个主要特征，但这只是一个粗略的指导方针，而不是一个严格的标准。

　　让我们深入讨论这些数据特征，看看为什么它们对搜索如此重要。我们现在只关注概念，详细的实现细节将在后面的章节中讨论。

　　文本中心的数据

　　您一定见过人们使用术语“非结构化数据”来描述搜索引擎处理的数据。我们觉得“非结构化”这个词有点含糊，因为无论是基于人类语言生成的文档都是隐式结构化的。

　　要理解“非结构化”一词，您可以从计算机的角度来考虑它。

　　在计算机眼中，文本文档就是一串字符流。这个字符流必须通过特定的语言规则解析出语义结构。天赋被找回了。这就是搜索引擎的工作。

　　我们觉得术语“以文本为中心的数据”更适合描述 Solr 处理的数据类型。因为搜索引擎设计的初衷是提取文本数据的隐藏结构并生成相关索引，以提高查询和检索的效率。“文本中心的数据”一词隐含地表示文档中的文本信息包括用户感兴趣的查询内容。

　　当然，搜索引擎也支持非文本数据，比如数字数据。但其主要优势在于基于自然语言处理文本数据。

　　我之前说的是“文本”。其实“中心”部分也很重要。假设您的用户对文本部分的内容不感兴趣，那么搜索引擎可能不是处理您问题的最佳选择。例如，对于员工创建差旅费用报告的应用程序，每个报告都收录一些结构化数据，例如日期。费用类型、汇率、数量等。另外，每笔费用后可能会附上一些备注。用于描述成本的一般情况。

　　这种应用程序是一种收录文本信息的应用程序。但它不是“以文本为中心的数据”的样本。由于会计部门使用这些员工的费用报表来生成月度费用报表，因此它不是通过查找备注中的文本信息来实现的。正文不是这里关注的主要内容。简单的说。也就是说，并非所有收录文本信息的数据都适合搜索引擎处理。

　　所以现在花几分钟思考一下您的数据是否是“以文本为中心的数据”。主要考虑的是用户是否会使用数据中的文本信息进行检索。

　　假设答案是肯定的，那么搜索引擎很可能是一个不错的选择。

　　我们将在第 5 章和第 6 章讨论如何使用 Solr 的文本分析来提取文本数据的结构细节。

　　读取的数据远多于写入的数据：

　　搜索引擎可以有效处理的数据的另一个特征是“读取的数据远多于写入的数据”。首先需要说明的是，Solr 同意更新索引中现有文档的内容。您可以将“读多于写”解释为对文档进行读取操作的频率远高于创建和更新文档的频率。但是不要狭隘地理解你根本不能写数据，否则你将被限制在特定频率更新数据。事实上，Solr4 的一个关键特性是“近实时查询”。此功能允许您每秒索引数千个文档，并且几乎可以立即找到这些新添加的文档。

　　“读取的数据远多于写入的数据”背后的关键点是，在您的数据写入 Solr 后，在其生命周期中应该多次读取。

　　可以理解，搜索引擎主要不是用来存储数据的。主要用于查询存储的数据（一个查询请求就是一个读操作）。因此，假设您需要非常频繁地更新数据。那么搜索引擎可能不太适合你的需求，其他的NoSQL技术，比如Cassandra，可能更适合你的高速随机写入需求。

　　面向文档的数据

　　到目前为止，我们一直在使用更通用的术语“数据”，但实际上搜索引擎处理文档数据。在搜索引擎中。一个文档是一个独立的字段集合，每个字段只存储数据值。不能嵌套以收录其他值范围。换句话说。在 Solr 等搜索引擎中，文档都是扁平的，文档之间没有相互依赖。Solr中“扁平化”的概念比较松散。一个取值范围可以容纳多个数据值，但取值范围不能嵌套并且收录子范围。

　　换句话说，您可以在一个范围内存储多个数据值。但是您不能在该范围内嵌套其他范围。

　　Solr 中这种面向文档的扁平化方法可以很好地处理文档数据。例如，网页、博客。pdf文件等。那么如果你想使用 Solr 来处理关系数据库中的结构化数据呢？在这种情况下，您需要首先提取关系数据库中跨表存储的数据以对其进行解构。然后把它放在一个扁平的、独立的文档结构中。我们将在第 3 章中学习如何处理此类问题。

　　您还需要考虑文档数据中哪些值范围需要存储在 Solr 中，哪些值范围需要存储在其他系统（例如，数据库）中。简单的说。搜索引擎只存储需要检索的数据和用于显示检索结果的数据。

　　举个例子。假设您有一个在线视频的搜索索引。您不应该希望将视频文件本身存储在 Solr 中。一个合理的解决方案应该是将大型视频文件放在内容分发网络 (CDN) 上。通常你只需要在搜索引擎中存储满足搜索要求的最少数据。刚才的在线视频示例清楚地表明，Solr 不应被视为一种通用的数据存储技术。Solr 的工作是找到用户感兴趣的视频文件，而不是自己存储视频文件。

　　灵活的架构

　　最后搜索引擎数据的主要特点是灵活的模式。

　　这意味着查询索引中的文档不需要具有统一的结构。在关系数据库中，表中的每一行数据都必须具有相同的结构。在 Solr 中，文档可以有不同的范围。当然，同一个索引中的文档应该至少有每个人都拥有的范围的一部分，以便于检索，但并不要求所有文档中的范围结构完全相同。

　　举个例子。假设您要制作一个用于查找出租和出售房屋的搜索应用程序。显然，每个上市文件都有一个位置。房间数、卫浴数等常用价值范围，根据是出租还是出售而有所不同。不同的财产文件会有不同的取值范围。待售物业将有售价范围和物业税价值范围。出租房屋文件将具有不同的价值范围，例如月租和宠物政策。

　　综上所述，搜索引擎Solr专门针对处理文本中心进行了优化，阅读远远超过写作，并且是面向文档的。它用于具有灵活 Schema 的数据。Solr 不是通用的数据存储和处理技术，这也是它区别于其他 NoSQL 技术的主要因素。

　　有许多不同的数据存储和处理解决方案可供选择。优点是您不必再费力寻找可以满足您所有需求的通用技术解决方案。搜索引擎在某些特定任务上表现良好。但是，其他方面的表现却很差。这意味着在大多数情况下，您可以将 Solr 用作关系数据库和其他 NoSQL 技术的强大补充，而不是取代后者。

　　现在我们已经讨论了 Solr 优化的数据类型，让我们来讨论 Solr 等搜索引擎主要解决的实际用例。

　　了解这些用例可以帮助您了解搜索引擎技术与其他数据处理技术的不同之处。

　　1.1.2 常见的搜索引擎用例

　　在本节中，我们来看看像 Solr 这样的搜索引擎可以做什么。正如我们在 1.1. 部分 1 中提到的。这些讨论本质上只是指导方针，不要将它们视为严格的使用规则。在我们开始之前。你需要意识到，如果你想做一个优秀的搜索服务，门槛是非常高的。

　　今天的用户习惯于使用快速高效的网络搜索引擎，如 Google 和 Bing。而且很多热门网站也有自己强大的搜索解决方案，可以帮助用户高速获取自己想要的信息，所以用户对搜索服务并不陌生，会很挑剔。当你在评估像 Solr 这样的搜索引擎时，或者在设计你自己的搜索计划时，你必须有根。应将用户体验视为高优先级。

　　主关键字查询

　　显然，作为搜索引擎，首先要能够支持主关键词查询。

　　这也是搜索引擎的主要功能之一。只是关键词查询功能值得在这里强调，因为这是用户使用搜索引擎最典型的方式。

　　很少有真正的用户想要填写一个非常完整和复杂的搜索表单，一出现就进行搜索。考虑到 关键词 搜索功能将是用户与搜索引擎之间最常见的交互方式。这个基本功能必须能够为用户提供非常好的用户体验。

　　一般来说，用户希望输入几个简单的关键词就能得到很好的搜索结果。

　　这听起来像是一个简单的匹配任务：只需将查询字符串与文档匹配即可。只需考虑几个必须解决的问题才能获得良好的用户体验：

　　·相关结果必须快速返回，大多数情况要求一秒内返回

　　·当查询字符串出现拼写错误时，用户可以主动更正

　　·当用户进入时，通过自己主动完成建议，减少用户输入负担，这在移动应用中并不常见

　　·处理查询字符串中的同义词和同义词

　　·匹配收录查询字符串语言变体的文档

　　· 短语处理。用户是想匹配词组中的所有词，还是只匹配词组中的一些词

　　·处理一些一般介词，如“a”、“an”、“of”、“the”等。

　　·假设最上面的查询结果让用户不舒服。如何向用户返回许多其他查询结果

　　如您所见，没有使用特定的处理方法。这么一堆问题，会很难实现这么简单的功能。但是，有了像 Solr 这样的搜索引擎，这些功能可以立即得到满足，并且变得非常容易实现。在你为用户提供了一个强大的关键词搜索工具之后，那么你就需要考虑如何根据结果和查询请求的相关性来展示查询的结果，从而引出下一个用例. 对搜索返回的查询结果进行排序。

　　排序的搜索结果

　　搜索引擎会返回查询的“顶级”结果。在SQL中查询关系型数据库时，一行数据记录要么匹配返回的查询，要么忽略不匹配的查询，查询结果也按照数据记录的某个列属性进行排序。对于搜索引擎，返回的结果文档根据分数降序排列。分数表示文档与查询的匹配程度。匹配分数是根据一系列因素计算出来的。但一般来说，分数越高。表示结果文档和查询之间的相关性越高。

　　有几个因素决定了结果文档按相关性排序的重要性。首先，现代搜索引擎一般存储着海量的文档，数量都在数百万甚至数十亿。假设不正确的查询结果按相关性排序。那么用户就会被海量的返回结果淹没，无法清晰有效地浏览搜索结果。其次。用户使用其他搜索引擎的经验，让用户习惯于使用几个关键词来获得好的查询结果。它还使用户通常不那么耐心。

　　他们希望搜索引擎能够按自己的意愿工作，而不管他们输入的信息是否完全正确。例如，对于移动应用程序的后台搜索服务，用户会期望搜索服务在输入一些可能收录拼写错误的简短查询词后返回正确的搜索结果。

　　假设您想手动干预排序结果，您可以为特定文档、值范围或查询字符串添加权重，或者直接增加文档的相关性分数。例如，如果您想将新添加的文档推送到顶部位置，您可以通过根据创建时间改进文档的排序来实现。我们将在第 3 章中学习文档排序。

　　除了关键词咨询

　　使用像 Solr 这样的搜索引擎，用户可以输入几个 关键词 以获得一些搜索结果。然而，对于许多用户来说，这只是查询交互的第一步。他们需要能够继续浏览查询结果。驱动信息发现的交互对话过程也是搜索引擎的一个主要应用场景。往往让用户在搜索之前不是很准确地知道自己想要查询什么样的信息。他们事先不知道您的系统中存储了哪些信息。一个好的搜索引擎可以帮助用户不断提炼自己的信息需求，一步步的到达最需要的信息。

　　这里的核心思想是在返回用户初始查询对应的文档结果的同时，为用户提供一个工具，让他们可以不断改进查询，获取更多需要的信息。换句话说。除了返回匹配的文档之外，您还应该返回一个工具，让用户知道下一步该做什么。举个例子。可以根据属性对查询结果进行分类，方便用户根据需要进一步浏览。

　　这样的功能叫做Faceted-Search，这也是Solr的亮点之一。

　　我们将在1.的第2节看到一个房地产分类检索的例子，分类检索功能的细节将在第8章介绍。

　　哪些搜索引擎不适合...

　　最后。我们来讨论一些不适合应用搜索引擎的用例场景。

　　第一的。搜索引擎的一般设计是为每个查询返回一个小文档集，通常包括 10 到 100 个结果文档。通过 Solr 内置的结果分页功能，可以获得很多其他的结果文档。对于一个查询结果，有数百万个文档。假设您要求一次返回所有匹配的文档，那么您将等待很长时间。

　　查询本身会运行得非常快，但是从索引结构中重建数百万个文档绝对是一项非常耗时的任务。由于Solr这种存储取值范围在硬盘上的搜索引擎，在假设需要一次生成大量查询结果的情况下，仅适用于高速生成少量文档结果。在这种存储方式下生成大量的文档结果会消耗大量的时间。

　　另一个不适合应用搜索引擎的使用场景是深度分析任务场景，需要读取索引文件的大​​部分子集。

　　即使你避免了结果分页技术刚刚提到的问题。假设一个分析需要读取索引文件中的大量数据。你也会遇到非常大的性能问题，因为索引文件的底层数据结构并不是为大量读取而设计的。

　　我们前面提到了一点。但是这里我还是要再次强调一下。也就是说，搜索引擎技术不适合查询文档之间的关系。Solr 确实能够支持基于父子关系的查询。但它不支持复杂关系数据结构之间的查询。在第三章。您将学习如何将关系数据结构调整为适合 Solr 处理查询的平面文档结构。

　　最后，大多数搜索引擎没有直接的文档级安全支持，至少 Solr 没有。

　　假设您需要严格管理文档权限，则只能在搜索引擎之外想办法。

　　至此我们已经了解了适合搜索引擎处理的用例场景和数据类型。下一步是讨论 Solr 可以做什么。以及这些功能是如何实现的。在下一节中，您将了解 Solr 的主要功能是什么。以及她如何实施软件设计原则，例如外部系统集成、可扩展性和高可用性。