<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ThinkChat2.0新版上線,更智能更精彩,支持會話、畫圖、視頻、閱讀、搜索等,送10W Token,即刻開啟你的AI之旅 廣告
                # 12.1\. 介紹 全文搜索(或只是_文本搜索_)提供滿足_查詢_的識別自然語言_文檔_的能力, 并且任意地通過相關性查詢進行排序。搜索最常見的類型是找到所有包含給定的_查詢術語_的記錄,并且以_相似性_的查 詢順序返回它們。 `query`和`similarity`的概念是非常靈活的,取決于特定的應用。最簡單的 搜索認為`query`是一組詞,并且`similarity`為文檔中的查詢詞出現的頻率。 文本搜索操作符已經在數據庫中存在多年。PostgreSQL為文本數據類型提供`~`, `~*`, `LIKE`和`ILIKE`操作符,但它們缺乏許多通過現代信息系統要求的必要屬性: * 沒有語言的支持,即使是英語。正則表達式是不充分的,因為他們不能很容易地處理派生詞, 比如, `satisfies` 和`satisfy`。你可能會丟失包含`satisfies`的文檔, 雖然你可能會發現他們在尋找`satisfy`。使用`OR`搜索多個派生形式是可能的,但這很繁瑣, 而且容易出錯(有些詞可能會有上千的派生詞)。 * 他們沒有提供搜索結果的分類(排序),當成千的匹配文檔被發現時,這使得它們無效。 * 他們往往比較緩慢,因為沒有索引的支持,因此他們必須為每一個搜索處理所有文檔。 全文索引允許文檔被_預處理_,并且為后邊的快速搜索保存一個索引。預處理包括: * _解析文檔__標記_。標識不同類別的記號是非常有用的, 例如,數字,詞,復合詞,電子郵件地址,這樣他們可以用不同的方法來處理。原則上令牌類依賴于具體的應用, 但出于大多數的目的,可以使用一組預定義的類。PostgreSQL使用_解析器_來 執行這一步。提供了一種標準的解析器,以及為特定的需求創造的自定義分析器。 * _轉換標記為__詞_。詞是一個字符串,就像一個標記,但它已經_標準化_, 這樣同一個詞的不同形式是一樣的。例如,標準化幾乎總是包括可折疊的大寫字母到小寫字母,往往涉及刪除后綴(如英語中 的`s` 或者`es` )。這允許搜索找到同一個詞的不同形式,沒有繁瑣的輸入所有可能的變種。同時,這一步 通常刪除_屏蔽詞_,這是很常見的,他們對于搜索無用。(總之,標記是文檔文本的原片段,而詞匯被認 為是有用的索引和搜索的詞。)PostgreSQL使用_詞典_執行這一步。提供各種標準詞典, 以及為特定的需求創造的自定義詞典。 * _為優化搜索存儲預處理文檔_。比如,每個文檔可以表示為標準化詞匯排序數組。 伴隨著詞匯往往為_鄰近排序_存儲位置信息,這是理想的。因此包含查詢詞的"密集"區域的 文檔比分散查詢詞分配到一個更高的順序。 字典允許細粒度控制如何使用合適的字典規范化標記。你可以: * 定義不被索引的屏蔽詞。 * 使用Ispell映射同義詞到一個詞。 * 使用同義詞詞典將短語映射到一個詞。 * 使用Ispell詞典將詞的不同形式映射到一種范式。 * 使用Snowball詞根規則將一個詞的不同形式映射到一種范式。 一種數據類型`tsvector`用于存儲預處理文檔,以及類型`tsquery` 表示處理的查詢([Section 8.11](#calibre_link-1007))。 為這些數據類型提供很多的函數和操作符([Section 9.13](#calibre_link-1137)),其中最重要的是匹配運算符`@@`,將在[Section 12.1.2](#calibre_link-1101)中介紹。 全文搜索可以使用索引進行加速([Section 12.9](#calibre_link-1129))。 ## 12.1.1\. 文檔是什么? 一個_文檔_是全文搜索系統的搜索單元;例如,雜志上的一篇文章或電子郵件消息。 文本搜索引擎必須能夠解析文檔,而且可以存儲它們父文檔詞(關鍵詞)的聯系性。之后, 這些聯系用來搜索包含查詢詞的文檔。 在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 mid = did AND mid = 12; ``` > **Note:** 注意:實際上,在這些示例查詢中,`coalesce`使用時應防止一個獨立的`NULL`屬性導致整個文檔的`NULL`結果。 另外一個可能性是在文檔系統中作為簡單的文本文檔存儲。在這種情況下,數據庫可以用于存儲全 文索引并且執行搜索,同時使用一些唯一標識從文件系統中檢索文檔。然而,從外部檢索文件,數據庫 需要擁有超級用戶權限或者特殊函數支持,因此比把所有數據保存在PostgreSQL中相比較, 這往往不太方便。同時,保持所有的數據在數據庫里面允許輕松訪問文檔的元數據以幫助索引和顯示。 為了文本搜索目的,每個文檔必須減少到預處理`tsvector`格式。在文檔的`tsvector`表示形式上完整的執行搜索 和排序—當為了顯示給用戶來選擇文檔時,只需要檢索原文本。因此我們常說的`tsvector`作為文檔,當然它僅僅是 完整文檔的一種緊湊表示。 ## 12.1.2\. 基本文本匹配 PostgreSQL中的全文搜索基于匹配算子`@@`,如果一個`tsvector`(document)匹配一個`tsquery`(query), 則返回`true`。不管哪個數據類型先被重寫: ``` SELECT 'a fat cat sat on a mat and ate a fat rat'::tsvector @@ 'cat & rat'::tsquery; ?column? ---------- t SELECT 'fat & cow'::tsquery @@ 'a fat cat sat on a mat and ate a fat rat'::tsvector; ?column? ---------- f ``` 正如上面例子表明,一個`tsquery`不僅僅是原文本,更多的是一個`tsvector`。一個包含搜索條件的`tsquery`, 必須是已經標準化的詞,并且可能使用AND, OR, 和 NOT操作符連接多個術語(詳情請見[Section 8.11](#calibre_link-1007))。 函數`to_tsquery`和`plainto_tsquery`在將用戶書寫文本轉換成一個合適的`tsquery`是非常有幫助的。 比如通過標準化文本中的詞。類似的,`to_tsvector`用于解析和標準化文檔字符串。因此在實踐中文本搜索匹配 可能看起來更像這樣: ``` SELECT to_tsvector('fat cats ate fat rats') @@ to_tsquery('fat & rat'); ?column? ---------- t ``` 觀察這個匹配可能不會成功,如果寫成這樣: ``` SELECT 'fat cats ate fat rats'::tsvector @@ to_tsquery('fat & rat'); ?column? ---------- f ``` 由于這兒沒有發生詞`rats`的標準化。一個`tsvector`的元素是詞,假設已經被標準化,所以`rats`不匹配`rat`。 `@@`操作符也支持`text`輸入,允許一個文本字符串的顯示轉換為`tsvector`或者在簡單情況下忽略`tsquery`。 可用形式是: ``` tsvector @@ tsquery tsquery @@ tsvector text @@ tsquery text @@ text ``` 我們已經看到了前面兩種,形式 `text` `@@` `tsquery`等價于`to_tsvector(x) @@ y`。`text` `@@` `text`等價于 `to_tsvector(x) @@ plainto_tsquery(y)`。 ## 12.1.3\. 配置 上面是所有簡單文本搜索例子。如前所述,全文搜索功能還有能力做更多事情:忽略索引某個詞(屏蔽詞), 過程同義詞和使用復雜解析,比如:不僅僅基于空白格的解析。這些功能通過_文本搜索配置_控制。 PostgreSQL來自多語言的預先定義的配置,并且你也可以很容易的創建你自己的配置(psql的`\dF` 命令顯示了 所有可用配置)。 在安裝期間選擇一個合適的配置,并且在`postgresql.conf`中相應的設置[default_text_search_config](#calibre_link-1138)。 如果為了整個集群使用同一個文本搜索配置你可以使用`postgresql.conf`中的值。為了在集群中使用不同配置,但是在任何其他一個數據庫的同一 配置中使用`ALTER DATABASE ... SET`。否則,你可以在每個會話中設置`default_text_search_config`。 每個依賴于配置的文本搜索函數有一個可選的`regconfig`參數,因此可以明確聲明使用的配置。 僅當忽略這些參數的時候,才使用`default_text_search_config`。 為了更方便的建立自定義文本搜索配置,從簡單的數據庫對象中建立了配置。 PostgreSQL文本搜索功能提供了四種類型的配置相關的數據庫對象: * _文本搜索解析器_打破文檔標記,并且分類每個標記(比如,詞和數字)。 * _文本搜索詞典_把標記轉換成規范格式并且拒絕屏蔽詞。 * _文本搜索模板_提供潛在的詞典功能(一個詞典簡單的指定一個模板,并且為模板設置參數)。 * _文本搜索配置_選擇一個解析器,并且使用一系列詞典規范化語法分析器產生的標記。 文本搜索解析器和模板是從低層次的C函數建立的;因此它需要C程序能力開發新產品, 并且需要超級用戶權限安裝到數據庫中(在PostgreSQL發布的`contrib/`范圍內有附加解析器和模板的實例)。 因為詞典和配置僅僅參數化并且連接到一些潛在的解析器和模板上,創建一個新的詞典或者配置不需要特定的權限。 創建自定義詞典和配置實例出現在本章節的后面。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看