Elasticsearch实战(第2版)
上QQ阅读APP看书,第一时间看更新

1.2 搜索已成为新常态

随着数据的指数级增长(从TB到PB再到EB),迫切需要一种能够在大海捞针的情况下成功搜索的工具。曾经被誉为简单搜索的功能,现在已成为大多数组织生存工具箱中的必要功能。默认情况下,客户期望组织能提供搜索功能,以便他们可以在搜索栏中输入内容或浏览搜索下拉列表,快速找到他们需要的东西。

越来越难找到不带小放大镜图标的搜索栏的网站和应用。提供全面的搜索是一种竞争优势。

今天,现代搜索引擎致力于提高速度和相关性,并提供包装在丰富的商业和技术特性中的高级功能。Elasticsearch就是这样一个现代搜索引擎,它以速度和性能为核心,拥抱搜索和分析。在处理像Elasticsearch这样的搜索引擎时,我们会遇到不同类型的数据和搜索方式——结构化数据和非结构化数据及其各自的搜索方式。熟悉这些类型的数据对于理解搜索领域非常重要。下面我们就简要介绍一下结构化数据和非结构化数据。

1.2.1 结构化数据与非结构化(全文)数据

数据主要有两种类型,即结构化数据和非结构化数据。这两类数据之间的根本区别在于数据的存储和分析方式。结构化数据遵循预定义的模式/模型,而非结构化数据是自由格式、无组织且无模式的。

1. 结构化数据

结构化数据是高度组织化的,有明确的形态和格式,符合预定义的数据类型模式。它遵循定义好的模式,并且因结构规范而易于搜索。数据库中的数据被认为是结构化数据,因为在存储到数据库之前,它应该遵循严格的模式。例如,表示日期、数值或布尔值的数据必须采用特定的格式。

对结构化数据的查询会返回精确匹配的结果。也就是说,我们关注的是找到符合搜索条件的文档,而不是它们匹配的程度。这种搜索只有两种结果:要么有结果,要么没有结果——没有“可能”的结果。例如,当搜索“上个月取消的航班”时,期望“可能”取消的航班是没有意义的。结果中可能有零个或多个航班,但搜索不应该返回“与取消的航班接近匹配”的结果。

我们并不关心文档匹配的程度,只关心它们是否匹配,因此结果不附带相关性分数(一个正数,表示结果与查询的匹配程度)。获取上个月取消的所有航班、每周的畅销书或登录用户的活动等传统的数据库搜索就是这样的。

定义 相关性(relevancy)指的是搜索引擎的结果与用户查询的匹配程度。它是一种表示结果与原始查询匹配程度的机制。搜索引擎使用相关性算法来确定哪些文档与用户的查询密切相关(即它们有多相关),并根据结果与查询的匹配程度为每个结果生成一个称为相关性分数的正数。你使用Google搜索时,仔细观察一下搜索结果:顶部的结果与你正在寻找的内容非常相关。因此,我们可以说它们比结果列表底部的条目更相关。Google在内部为每个结果分配了一个相关性分数,并很可能根据这个分数对它们进行排序:分数越高,结果越相关,出现在页面顶部的可能性越大。

2. 非结构化数据

非结构化数据是无组织的,不遵循任何模式或格式。它没有预定义的结构。非结构化数据是大多数现代搜索引擎的主要处理内容。非结构化数据包括博客文章、研究论文、电子邮件、PDF、音频和视频文件等。

注意 除了结构化数据和非结构化数据,还有一类数据——半结构化数据。这种数据基本上处于结构化数据和非结构化数据之间。半结构化数据不过是一些带有元数据描述的非结构化数据。

对于非结构化数据,Elasticsearch提供了全文搜索功能,允许用户在大量非结构化文本中搜索特定的词项或短语。全文(非结构化)搜索尝试找到与查询相关的结果。也就是说,Elasticsearch搜索所有最符合查询条件的文档。例如,如果用户搜索关键词“vaccine”(疫苗),搜索引擎不仅搜索与疫苗接种相关的文档,还会包含关于接种、注射及其他与疫苗相关术语的文档。

Elasticsearch使用相似性算法为全文查询生成相关性分数。分数是一个附加到结果的正浮点数,分数最高的文档表示与查询条件的相关性更大。

Elasticsearch能够高效地处理结构化数据和非结构化数据。它的一个关键特性是能够在同一索引中对结构化数据和非结构化数据进行索引和搜索。这使我们能够一起搜索和分析这两种类型的数据,并获得其他方式难以获得的洞察。

1.2.2 数据库支持的搜索

传统的搜索主要基于关系数据库。早期的搜索引擎基于在多层应用中实现的分层架构,如图1-1所示。

图1-1 基于传统数据库的搜索

使用where和like这样的子句编写的SQL查询为搜索提供了基础,这些解决方案对搜索全文数据以提供现代搜索功能来说,未必是高性能和高效的。

话虽如此,一些现代数据库(如Oracle和MySQL)也支持全文搜索(针对博客文章、电影评论、研究论文等自由文本的查询),但它们在面对大量负载的情况下,可能难以近实时地提供高效的搜索。更多详细信息参见下页的“数据库中的全文搜索”。

分布式搜索引擎(如Elasticsearch)提供的即时可扩展性是大多数数据库所不具备的。一个依赖没有全文搜索能力的后端数据库开发的搜索引擎,甚至可能无法为查询提供相关搜索结果,更不用说提供实时查询结果和应对数据量的增长了。

数据库中的全文搜索

Oracle和MySQL这样的关系数据库也支持全文搜索功能,尽管不如Elasticsearch这样的现代全文搜索引擎功能丰富。但是这两种全文搜索解决方案在存储和检索数据方面有本质的区别,因此在选择使用哪种解决方案之前,我们必须明确自己的需求原型。通常,如果数据模式不会改变或数据量不大,并且我们已经有了一个具备全文搜索能力的数据库引擎,那么用数据库进行全文搜索可能是有意义的。

1.2.3 数据库与搜索引擎

在传统数据库上构建搜索服务时,我们需要考虑并了解我们的需求是否可以由数据库高效且有效地满足。大多数数据库被设计用来存储大量数据,但遗憾的是,由于以下几点原因,它们不太适合用作全文搜索引擎。

索引和搜索性能。全文搜索需要高效的索引及高性能的搜索和分析能力,而传统数据库并未对此进行优化。数据库可能难以索引大量数据,因此可能导致查询性能较差。而像Elasticsearch和Solr这样的搜索引擎是专为处理大量文本数据设计的,并可以近实时地提供搜索结果。搜索引擎可以处理大规模数据,同时索引和搜索数据的速度比传统数据库快得多,因为它们从一开始就是为优化搜索操作设计的。更何况,关系数据库还存在缺乏模糊匹配、词干提取、同义词等高级搜索功能的问题。

搜索。传统数据库的搜索基本上是基于数据值的精确匹配。虽然这适用于对结构化数据进行非搜索相关的查找操作,但对于通常比较复杂的自然语言查询,这是绝对不行的。用户的查询往往存在拼写错误、语法错误或不完整的问题,并且可能包含数据库无法理解的同义词和其他语言结构。

在自然语言查询中,用户可能不会使用他们正在搜索的准确词项(如存在拼写错误),遗憾的是,传统数据库并不支持拼写错误的用户输入。而在现代搜索引擎中,模糊匹配搜索功能(单词相似但不完全相同)解决了这一问题。在传统数据库中,数据通常是归一化的,这意味着它们可能分布在多个表和列中。这可能使在单个查询中跨多个字段搜索数据变得很困难。而且传统数据库也不是为处理全文搜索场景中常见的非结构化数据和半结构化数据设计的。

文本分析和处理。搜索引擎通常需要处理多种语言和字符集,而传统数据库可能并不支持。搜索引擎进行文本分析和处理以提取文本的含义,但传统数据库并没有为此进行设计或者优化。

可扩展性和灵活性。全文搜索引擎是为处理大量数据和高查询负载设计的。当处理大量文本数据时,传统数据库可能遇到扩展性的问题。

搜索引擎从一开始就是为处理非结构化数据设计的,而数据库则是为处理结构化数据设计和优化的。这些限制使传统数据库并不适合用作全文搜索引擎。通常使用诸如Elasticsearch、Solr、Lucene等专门的搜索引擎技术为文本数据提供高级搜索功能。

注意 许多数据库已经将文本搜索功能添加到其功能集。然而,它们可能仍然无法在性能、可扩展性和功能上与专业的全文搜索引擎相媲美。

这并不妨碍我们同时拥抱两种技术:在某些使用场景中,可以同时使用传统数据库和搜索引擎。例如,数据库可用于事务处理,搜索引擎可用于搜索和分析。不过,本书的重点是搜索引擎,尤其是Elasticsearch。下面我们就回顾一下现代搜索引擎的时代。