# 12.1.导言
全文搜索(或文本搜索)提供识别自然语言的能力文件满足查询,并可以选择按与查询的相关性对它们进行排序。最常见的搜索类型是查找包含给定内容的所有文档查询词并按顺序将其返回相似性回答这个问题。关于查询
和相似性
非常灵活,取决于具体应用。最简单的搜索查询
作为一组单词和相似性
作为文档中查询词的频率。
文本搜索操作符在数据库中已经存在多年了。PostgreSQL已经~
,~*
,喜欢
和我喜欢
文本数据类型的运算符,但它们缺乏现代信息系统所需的许多基本属性:
没有语言支持,即使是英语。正则表达式是不够的,因为它们不能轻松处理派生词,例如,
满足
和满足
.您可能会错过包含满足
,尽管您可能希望在搜索时找到它们满足
.可以使用或者
搜索多个派生形式,但这很乏味且容易出错(有些单词可能有数千个派生词)。它们不提供搜索结果的排序(排名),这使得它们在找到数千个匹配文档时无效。
它们往往很慢,因为没有索引支持,因此它们必须为每次搜索处理所有文档。
全文索引允许文档被预处理并保存一个索引以供以后快速搜索。预处理包括:
将文档解析为代币*.识别各种类型的标记很有用,例如数字、单词、复杂单词、电子邮件地址,以便可以不同地处理它们。原则上,令牌类取决于特定的应用程序,但对于大多数目的来说,使用一组预定义的类就足够了。PostgreSQL 使用一个parser* 执行此步骤。提供了标准解析器,并且可以根据特定需求创建自定义解析器。
将令牌转换为词位*.词位是一个字符串,就像一个记号,但它一直是归一化从而使同一个词的不同形式变得相似。例如,规范化几乎总是包括将大写字母折叠成小写字母,并且经常涉及删除后缀(例如
s
或者es
(用英语)。这允许搜索找到同一单词的变体形式,而无需繁琐地输入所有可能的变体。此外,此步骤通常会消除停止说话*,这些词非常常见,对搜索没有用处。(简而言之,标记是文档文本的原始片段,而词素是被认为对索引和搜索有用的单词。)PostgreSQL使用*使用字典*执行此步骤。提供了各种标准词典,并可根据具体需要创建自定义词典。存储为搜索而优化的预处理文档。例如,每个文档都可以表示为规范化词素的排序数组。除了词素,通常还需要存储位置信息以用于接近度排名,因此,与具有分散查询词的文档相比,包含更“密集”的查询词区域的文档的排名更高。
字典允许细粒度地控制令牌的规范化方式。使用适当的词典,您可以:
定义不应编入索引的停止词。
使用Ispell将同义词映射到单个单词。
使用同义词库将短语映射到单个单词。
使用Ispell字典将单词的不同变体映射到规范形式。
使用雪球词干分析器规则将单词的不同变体映射到规范形式。
数据类型
tsvector
用于存储预处理的文档,以及tsquery
用于表示已处理的查询(第8.11节)。这些数据类型有许多可用的函数和运算符(第9.13节),其中最重要的是匹配运算符@@
,我们在第12.1.2节.使用索引可以加速全文搜索(第12.9节).
# 12.1.1.什么是文件?
A.文件是全文搜索系统中的搜索单元;例如,一篇杂志文章或电子邮件。文本搜索引擎必须能够解析文档并存储词素(关键字)与其父文档的关联。之后,这些关联用于搜索包含查询词的文档。
对于PostgreSQL中的搜索,文档通常是数据库表行中的文本字段,或者可能是此类字段的组合(串联),可能存储在多个表中,或者动态获取。换句话说,一个文档可以从不同的部分构造出来进行索引,而它可能不会作为一个整体存储在任何地方。例如:
SELECT title || ' ' || author || ' ' || abstract || ' ' || body AS document
FROM messages
WHERE mid = 12;
SELECT m.title || ' ' || m.author || ' ' || m.abstract || ' ' || d.body AS document
FROM messages m, docs d
WHERE m.mid = d.did AND m.mid = 12;
# 笔记
实际上,在这些示例查询中,合并
应该用来防止一次无效的
属性,以避免导致无效的
整个文档的结果。
另一种可能是将文档作为简单文本文件存储在文件系统中。在这种情况下,数据库可用于存储全文索引和执行搜索,并可使用某些唯一标识符从文件系统检索文档。然而,从数据库外部检索文件需要超级用户权限或特殊功能支持,因此这通常不如将所有数据保存在PostgreSQL中方便。此外,将所有内容都保存在数据库中可以方便地访问文档元数据,以帮助索引和显示。
出于文本搜索的目的,每个文档都必须简化为预处理文档tsvector
总体安排搜索和排名完全在tsvector
文档的表示——只有在选择向用户显示文档时,才需要检索原始文本。因此,我们经常提到tsvector
作为文件,但它当然只是完整文件的紧凑表示。
# 12.1.2.基本文本匹配
PostgreSQL中的全文搜索基于匹配运算符@@
,返回符合事实的
如果tsvector
(文档)与tsquery
(质询)。先写入哪种数据类型无关紧要:
SELECT 'a fat cat sat on a mat and ate a fat rat'::tsvector @@ 'cat & rat'::tsquery;
?column?
### 12.1.3. Configurations
The above are all simple text search examples. As mentioned before, full text search functionality includes the ability to do many more things: skip indexing certain words (stop words), process synonyms, and use sophisticated parsing, e.g., parse based on more than just white space. This functionality is controlled by *text search configurations*. PostgreSQL comes with predefined configurations for many languages, and you can easily create your own configurations. (psql's `\dF` command shows all available configurations.)
During installation an appropriate configuration is selected and [default\_text\_search\_config](runtime-config-client.html#GUC-DEFAULT-TEXT-SEARCH-CONFIG) is set accordingly in `postgresql.conf`. If you are using the same text search configuration for the entire cluster you can use the value in `postgresql.conf`. To use different configurations throughout the cluster but the same configuration within any one database, use `ALTER DATABASE ... SET`. Otherwise, you can set `default_text_search_config` in each session.
Each text search function that depends on a configuration has an optional `regconfig` argument, so that the configuration to use can be specified explicitly. `default_text_search_config` is used only when this argument is omitted.
To make it easier to build custom text search configurations, a configuration is built up from simpler database objects. PostgreSQL's text search facility provides four types of configuration-related database objects:
* *Text search parsers* break documents into tokens and classify each token (for example, as words or numbers).
* *Text search dictionaries* convert tokens to normalized form and reject stop words.
* *Text search templates* provide the functions underlying dictionaries. (A dictionary simply specifies a template and a set of parameters for the template.)
* *Text search configurations* select a parser and a set of dictionaries to use to normalize the tokens produced by the parser.
Text search parsers and templates are built from low-level C functions; therefore it requires C programming ability to develop new ones, and superuser privileges to install one into a database. (There are examples of add-on parsers and templates in the `contrib/` area of the PostgreSQL distribution.) Since dictionaries and configurations just parameterize and connect together some underlying parsers and templates, no special privilege is needed to create a new dictionary or configuration. Examples of creating custom dictionaries and configurations appear later in this chapter.