12.3. 控制文本搜索 · PostgreSQL 中文文檔 9.3

# 12.3\. 控制文本搜索為了執行全文搜索，這必須有個函數創建來自文檔的`tsvector`和來自用戶查詢的`tsquery`。同時，我們需要以有效的順序返回結果，因此我們需要一個函數比較關于查詢相關性的文檔。可以很好的顯示結果也是很重要的。PostgreSQL為所有這些函數提供支持。 ## 12.3.1\. 解析文檔 PostgreSQL中提供了`to_tsvector`函數把文檔處理成`tsvector`數據類型。 ``` to_tsvector([ `_config_` `regconfig`, ] _document_ text) returns tsvector ``` `to_tsvector`解析文本文檔為記號，減少標記到詞條，并返回一個`tsvector`，其羅列出詞條并連同它們文檔中的位置。該文檔是根據指定的或默認的文本搜索配置處理的。這里有一個簡單的例子： ``` SELECT to_tsvector('english', 'a fat cat sat on a mat - it ate a fat rats'); to_tsvector ----------------------------------------------------- 'ate':9 'cat':3 'fat':2,11 'mat':7 'rat':12 'sat':4 ``` 在上面的例子中我們看到結果`tsvector`不包含詞 `a`, `on`或者 `it`。 `rats`變成`rat`,并且忽略標點符號-。該`to_tsvector`函數內部調用一個分析器，將文檔文本分解成記號并指定每個標記的類型。為每個標記，參閱詞典列表（節[Section 12.6](#calibre_link-1117)），列表因不同的標記類型而不同。第一本詞典_識別_標記發出一個或多個標準_詞匯_ 表示標記。例如，`rats`變成`rat` 因為字典認為詞`rats`是`rat`的復數形式。有些詞被作為_屏蔽詞_（節[Section 12.6.1](#calibre_link-1118)），這樣它們就會被忽略，因為它們出現得太過頻繁以致于搜索中沒有用處。在我們的例子中，它們是`a`, `on`和`it`。如果列表中沒有詞典識別標記，那么它也被忽略。在這個例子中，發生在標點符號處`-`因為事實上沒有詞典分配給它的標記類型（`空間符號`），意味著空間記號永遠不會被索引。語法分析器的選擇，詞典和索引類型的標記是由選定的文本搜索配置決定（節[Section 12.7](#calibre_link-1124)）。可以在同一個數據庫中有多種不同的配置，與提供各種語言的預定義的配置。在我們的例子中，我們使用缺省配置`english`為英語。函數`setweight`可以用于標識一個給定_權重_的`tsvector`的詞條，權重是字母`A`, `B`, `C`或者`D`之一。通常標記來自文檔不同部分的詞條，比如標題正文。之后，這些信息可以用于搜索結果的排序。因為`to_tsvector`(`NULL`)將要返回`空`，當字段可能是空的時候，建議使用`coalesce`。這是體系文檔中創建`tsvector`推薦的方法： ``` UPDATE tt SET ti = setweight(to_tsvector(coalesce(title,'')), 'A') || setweight(to_tsvector(coalesce(keyword,'')), 'B') || setweight(to_tsvector(coalesce(abstract,'')), 'C') || setweight(to_tsvector(coalesce(body,'')), 'D'); ``` 我們使用`setweight`標記已完成的`tsvector`中的每個詞的來源，并且使用`tsvector`連接操作符`||`合并標簽化`tsvector`的值。（節[Section 12.4.1](#calibre_link-1112)詳細介紹了這些操作）。 ## 12.3.2\. 解析查詢 PostgreSQL提供了函數`to_tsquery`和 `plainto_tsquery`將查詢轉換為`tsquery`數據類型。 `to_tsquery`提供比`plainto_tsquery`更多的功能，但對其輸入不寬容。 ``` to_tsquery([ `_config_` `regconfig`, ] _querytext_ text) returns tsquery ``` `to_tsquery`從`_querytext_`中創建一個`tsquery`，它必須由布爾運算符`&` (AND), `|` (OR)和`!` (NOT)分離的單個標記組成。這些運算符可以用圓括弧分組。換句話說，`to_tsquery`輸入必須遵循`tsquery`輸入的一般規律，如節[Section 8.11](#calibre_link-1007)所描述的。不同的是當基本`tsquery`輸入以標記表面值的時候，`to_tsquery`使用指定或默認配置規范每個標記到一個詞，并丟棄所有標記依據配置的屏蔽詞。比如： ``` SELECT to_tsquery('english', 'The & Fat & Rats'); to_tsquery --------------- 'fat' & 'rat' ``` 作為基本`tsquery`輸入，權重（s）可以附屬于每個詞來限制它只匹配那些權重(s)的`tsvector`詞。比如： ``` SELECT to_tsquery('english', 'Fat | Rats:AB'); to_tsquery ------------------ 'fat' | 'rat':AB ``` `*`也可以附屬于一個詞來指定前綴匹配： ``` SELECT to_tsquery('supern:*A & star:A*B'); to_tsquery -------------------------- 'supern':*A & 'star':*AB ``` 這樣的詞將匹配以給定字符串開頭的`tsvector`中的任何詞。 `to_tsquery`也可以接受單引用的短語。當配置包括一個可能觸發這類短語的同義詞詞典庫的時候是很有用的。在下面的例子中，一個詞庫包含規則`supernovae stars : sn`： ``` SELECT to_tsquery('''supernovae stars'' & !crab'); to_tsquery --------------- 'sn' & !'crab' ``` 沒有引號，`to_tsquery`會生成標記語法錯誤，這個標記不是通過AND 或者OR操作符分離的。 ``` plainto_tsquery([ `_config_` `regconfig`, ] _querytext_ text) returns tsquery ``` `plainto_tsquery`變換未格式化的文本`_querytext_`到`tsquery`。分析文本并且歸一化為`to_tsvector`，然后在存在的詞之間插入`&`(AND)布爾算子。比如： ``` SELECT plainto_tsquery('english', 'The Fat Rats'); plainto_tsquery ----------------- 'fat' & 'rat' ``` 請注意，`plainto_tsquery`無法識別布爾運算符，權重標簽，或在其輸入中的前綴匹配標簽： ``` SELECT plainto_tsquery('english', 'The Fat & Rats:C'); plainto_tsquery --------------------- 'fat' & 'rat' & 'c' ``` 在這里，所有的輸入標點符號作為空格符號丟棄。 ## 12.3.3\. 查詢結果關注度相關度試圖衡量哪一個文檔是檢索中最關注的，所以當有很多匹配時，最相關的一個則最先顯示。 PostgreSQL提供了兩個預定義的相關函數，其中考慮了詞法，距離，和結構信息；也就是，他們考慮查詢詞在文檔中出現的頻率，術語在文檔中的緊密程度，以及它們在文檔中的部分的重要性。然而，相關性的概念是模糊的，并且是特定應用程序。不同的應用程序可能需要額外的相關信息，例如，文檔的修改時間。內置的相關函數是唯一的例子。為了以滿足您的特定需求，你可以寫你自己的相關函數和/或與其他因素相結合的結果。當前可用的兩個相關函數： `ts_rank([ ``_weights_` `float4[]`, ] `_vector_` `tsvector`, `_query_` `tsquery` [, `_normalization_` `integer` ]) returns `float4` 基于匹配詞匯頻率的列向量。 `ts_rank_cd([ ``_weights_` `float4[]`, ] `_vector_` `tsvector`, `_query_` `tsquery` [, `_normalization_` `integer` ]) returns `float4` 這個函數計算給定文檔向量和查詢的_覆蓋密度_相關性，正如1999年在雜志“信息處理與管理”中Clarke，Cormack和Tudhope的“一至三項查詢相關性排序”描述的一樣。這些函數需要位置信息的輸入。因此它不能在"剝離"`tsvector`值的情況下運行—它將總是返回零。對于這些函數，可選的`_weights_`參數提供權衡詞的情況能力或多或少地取決于它們是如何被標記的。權重陣列指定順序權重每類詞的頻率。 ``` {D-weight, C-weight, B-weight, A-weight} ``` 如果沒有提供`_weights_`，則利用這些缺省值： ``` {0.1, 0.2, 0.4, 1.0} ``` 通常的權重是用來標記文檔特殊區域的詞，如標題或最初的摘要，所以他們有著比文檔主體中的詞或多或少的重要性。由于較長的文檔有包含查詢詞的機會，它合理的考慮文檔的大小，例如，帶有搜索詞的五個實例的百字文檔可能比千字文檔有更多的相關性。相關接受一個整數`_normalization_`選項，指定文檔長度是否以及如何影響它的排序。整數選項控制一些行為，所以它是一位掩碼：您可以使用`|`（例如，`2|4`）指定一個或多個行為。 * 0（缺省）表示跟長度大小沒有關系 * 1 表示關注度（rank）除以文檔長度的對數+1 * 2表示關注度除以文檔的長度 * 4表示關注度除以范圍內的平均諧波距離，只能使用`ts_rank_cd`實現。 * 8表示關注度除以文檔中唯一分詞的數量 * 16表示關注度除以唯一分詞數量的對數+1 * 32表示關注度除以本身+1 如果指定超過一個的標志位，則在列出順序中應用轉換。需要特別注意的是，相關函數不使用任何全局信息，所以不可能產生一個所需要的1%或100%的公平歸一化。規范化選項32 (`rank/(rank+1)`)可用于所有規模排序到范圍零到一之間，當然，這只是一個表面變化；它不會影響搜索結果的排序。下面是一個例子，僅僅選擇排名前十的匹配： ``` SELECT title, ts_rank_cd(textsearch, query) AS rank FROM apod, to_tsquery('neutrino|(dark & matter)') query WHERE query @@ textsearch ORDER BY rank DESC LIMIT 10; title | rank -----------------------------------------------+---------- Neutrinos in the Sun | 3.1 The Sudbury Neutrino Detector | 2.4 A MACHO View of Galactic Dark Matter | 2.01317 Hot Gas and Dark Matter | 1.91171 The Virgo Cluster: Hot Plasma and Dark Matter | 1.90953 Rafting for Solar Neutrinos | 1.9 NGC 4650A: Strange Galaxy and Dark Matter | 1.85774 Hot Gas and Dark Matter | 1.6123 Ice Fishing for Cosmic Neutrinos | 1.6 Weak Lensing Distorts the Universe | 0.818218 ``` 這是使用歸一化排序的相同例子： ``` SELECT title, ts_rank_cd(textsearch, query, 32 /* rank/(rank+1) */ ) AS rank FROM apod, to_tsquery('neutrino|(dark & matter)') query WHERE query @@ textsearch ORDER BY rank DESC LIMIT 10; title | rank -----------------------------------------------+------------------- Neutrinos in the Sun | 0.756097569485493 The Sudbury Neutrino Detector | 0.705882361190954 A MACHO View of Galactic Dark Matter | 0.668123210574724 Hot Gas and Dark Matter | 0.65655958650282 The Virgo Cluster: Hot Plasma and Dark Matter | 0.656301290640973 Rafting for Solar Neutrinos | 0.655172410958162 NGC 4650A: Strange Galaxy and Dark Matter | 0.650072921219637 Hot Gas and Dark Matter | 0.617195790024749 Ice Fishing for Cosmic Neutrinos | 0.615384618911517 Weak Lensing Distorts the Universe | 0.450010798361481 ``` 排序花費比較多，因為它需要查找每個匹配文檔的`tsvector`，這與I/O綁定，因此慢。不幸的是，它幾乎是不可能避免因實際的查詢往往導致的大量匹配。 ## 12.3.4\. 強調結果為顯示搜索結果，合理顯示每個文檔的一部分以及查詢相關性。通常，搜索引擎顯示標記搜索條件的文檔片段。 PostgreSQL提供了一個函數`ts_headline`實現此功能。 ``` ts_headline([ `_config_` `regconfig`, ] _document_ text, _query_ tsquery [, `_options_` `text` ]) returns text ``` `ts_headline`接受查詢文檔，并從突顯的查詢條件的文檔中返回一個摘錄。配置用來解析`_config_`指定的文檔；如果省略`_config_`，則使用`default_text_search_config`配置。如果指定一個`_options_`字符串，它必須由一個逗號分隔的一個或多個`_option_``=``_value_`對組成。可用選項是： * `StartSel`, `StopSel`:該字符串分隔文檔中出現的查詢詞，以區別于其他摘錄詞。如果它們含有空格或逗號，你必須用雙引號字符串。 * `MaxWords`, `MinWords`:這些數字決定最長和最短的標題輸出。 * `ShortWord`:這個長度或更短的詞在標題的開始和結束被丟棄。三個默認值消除了常見英語文章。 * `HighlightAll`:布爾標志；如果為`真`，整個文檔將作為標題，忽略了前面的三個參數。 * `MaxFragments`:要顯示的文本摘錄或片段的最大數量。默認值零選擇非片段標題的生成方法。一個大于零的值選擇基于片段的標題生成。此方法查找文本片段與盡可能多的查詢詞并在查詢詞周圍延伸這些片段。作為查詢詞的結果接近每一片段中間，每邊都有詞。每個片段至多是`MaxWords` ，并且長度為`ShortWord`或更短的詞在每一個片段開始和結束被丟棄。如果不是所有的查詢詞在文檔中找到，則文檔中開頭的`MinWords`單片段將被顯示。 * `FragmentDelimiter`:當一個以上的片段顯示時，通過字符串分隔這些片段。任何未聲明的選項接受這些缺省： ``` StartSel=, StopSel=, MaxWords=35, MinWords=15, ShortWord=3, HighlightAll=FALSE, MaxFragments=0, FragmentDelimiter=" ... " ``` 比如: ``` SELECT ts_headline('english', 'The most common type of search is to find all documents containing given query terms and return them in order of their similarity to the query.', to_tsquery('query & similarity')); ts_headline ------------------------------------------------------------ containing given query terms and return them in order of their similarity to the query. SELECT ts_headline('english', 'The most common type of search is to find all documents containing given query terms and return them in order of their similarity to the query.', to_tsquery('query & similarity'), 'StartSel = <, StopSel = >'); ts_headline ------------------------------------------------------- containing given <query> terms and return them in order of their <similarity> to the <query>. ``` `ts_headline`使用原始文檔，而不是一個`tsvector`摘要，因此它很慢，應小心使用。一個典型的錯誤是，當只顯示10個文檔時，為_每個_匹配文檔調用`ts_headline`。SQL子查詢可以幫忙，這是一個例子： ``` SELECT id, ts_headline(body, q), rank FROM (SELECT id, body, q, ts_rank_cd(ti, q) AS rank FROM apod, to_tsquery('stars') q WHERE ti @@ q ORDER BY rank DESC LIMIT 10) AS foo; ```