什麼時候 Postgres 的全文檢索功能會不夠用？
概述 Postgres 全文檢索在九個方面不如以搜尋為中心的資料庫。
全文檢索指的是將部分或全部文字查詢與資料庫中儲存的文件進行比對。與傳統的資料庫查詢相比，即使是部分比對，全文檢索也能提供結果。它允許為使用者建立更靈活的搜尋介面，從而使他們能夠更快地找到準確的結果。
從簡單的應用程式內搜尋到瀏覽龐大的電子商務產品目錄，全文檢索的使用案例數不勝數。它非常普遍，以至於 Postgres 和其他關聯式資料庫都包含了用於全文檢索的專用 API。遺憾的是，Postgres 在多個方面不如以搜尋為中心的資料庫。
1. 複雜的設定
為了提供相關的結果，全文檢索應能容忍錯字、允許同義詞和允許部分比對。此外，結果排名需要高度客製化，以適應企業的特定需求。在 Postgres 上設定全文檢索需要全面的設定，並且通常需要擴充功能，而這些擴充功能在使用託管雲端服務時無法使用。
建立資料庫索引、編寫查詢和排名演算法很快就會超出領域知識的範圍，並需要搜尋、索引和語言學方面的專業知識。當處理旨在應對 Postgres 全文檢索限制的混雜擴充功能所帶來的限制時，最佳化效能會變得更加困難。
相反地，以搜尋為中心的資料庫開箱即用，就配備了最先進的功能，例如錯字容忍度、前綴搜尋、模糊比對、同義詞和可自訂排名。
2. 分面搜尋
分面搜尋允許使用者透過廣泛的類別來細化搜尋結果。它經常在電子商務應用程式中使用。例如，服裝店可以實作按品牌、尺寸或評分範圍等分面篩選。
電子商務網站上的分面搜尋（請參閱示範）
針對單個分面實作篩選就已經夠棘手了。但是分面可以採用多種形式：類別標籤、價格範圍或最低評分。針對所有類型實作篩選是非常具有挑戰性的。無論如何，最難實作的查詢是彙總結果以建立分面計數。這在大型資料集上會變得非常耗費資源。
使用 Postgres 實作分面搜尋的複雜性會隨著分面數量的增加而呈指數級成長。僅分面搜尋就成為Elasticsearch 或 Meilisearch等搜尋引擎的強大賣點，它們配備了最佳化的一流 API 來處理分面篩選和計數。
3. 錯字容忍度
預設情況下，Postgres 全文檢索無法處理拼寫錯誤。使用者通常會安裝 pg_trgm 擴充功能來解決此限制。（再次說明，此解決方案並非始終在託管 Postgres 中可用。）此擴充功能特別引入了新的運算子來比較字串之間的相似度，以及針對搜尋最佳化的 GIN 和 GIST 索引。
新的索引允許對全文檢索進行更多設定，但是選擇 GIN 和 GIST 索引並非始終容易。此外，新的運算子沒有考慮到單字鄰近度、空格分隔符或單字大小。特別是，這使得使用 Postgres 難以實現真正的模糊比對。
理想情況下，以搜尋為中心的資料庫應該允許為單字查詢與多字查詢設定不同的規則。Meilisearch 就是這種情況，它允許針對特定欄位完全停用錯字容忍度。這使得使用者可以透過唯一的識別碼（例如書籍的國際標準書號 (ISBN)）進行搜尋。
ISBN 欄位已停用錯字容忍度（請參閱示範）
4. 語言支援
使用拉丁字母的語言與其他語言（如阿拉伯語或中文）之間的語言特性差異很大。截至 Postgres 15，全文檢索詞典不適用於簡體中文和繁體中文、韓語和日語等語言。這意味著要針對不同的語言採用特定的實作。
要查看Postgres 全文檢索支援的語言清單，您可以在 Postgres 中執行 `\dFd` 命令。
在 Amazon RDS 等託管環境中，語言支援限制會被放大，在這些環境中，使用者無法存取檔案系統。此受限存取會阻止他們實作自訂詞典、詞幹分析器、同義詞等。
Meilisearch 在所有使用空格分隔單字的語言之上，針對中文、日語、韓語、希伯來語等語言提供了最佳化的語言支援。
由於其活躍的開放原始碼社群，Meilisearch 受益於母語人士為改進特定語言功能所做的貢獻
5. 支付後端成本
Postgres 是一個旨在與伺服器端語言通訊的資料庫。當建立面向公眾的用戶端應用程式時，這意味著在資料庫之上建立 API 以與用戶端通訊。除了額外的開發時間外，建立這樣的 Proxy 還會帶來其他問題。
首先是延遲問題：向 API 發出請求，然後該 API 在返回結果之前查詢資料庫，這必然會花費一些時間。這不會影響專用的搜尋引擎，因為它們配備了旨在向終端使用者傳遞資料的公開 API。
現在是第二個問題：安全性。搜尋引擎 API 從一開始就設計為供公眾使用。並且安全功能已內建於該使用案例中。預設情況下，API 金鑰會限制搜尋請求，而租戶權杖啟用多租戶等進階功能。
使用租戶權杖來限制對文件的存取權限（請參閱示範）
6. 擴展限制
人們有充分的理由希望將所有資料保留在單一資料庫中。但是，將與搜尋相關的資料儲存在主資料庫中會帶來巨大的技術影響。Postgres 在大型資料集上執行全文檢索查詢的成本很高，尤其是在對結果進行排名和計算分面計數時。
單體式資料庫通常會成為需要擴展的應用程式的瓶頸。當您可以避免時，請勿向此資源增加不必要的與搜尋相關的成本。當您使用高流量建立面向使用者的應用程式時，這些成本只會成倍增加。
與關聯式資料庫不同，像是 Meilisearch 這類的全文本搜尋引擎使用反向索引，這種資料結構會建立資訊冗餘，以加速資訊檢索。它的設計目的是執行搜尋操作，並且在大數據集上效能自然會優於關聯式資料庫。而且，當搜尋使用量激增時，只需要擴展單一服務。
7. 相關性
正如我們之前提到的，相關的搜尋需要容錯字、自訂排名和同義詞。在現代應用程式中，使用者期望結果在每次按鍵時更新，這需要前綴搜尋。但 Postgres 的全文搜尋 ts_rank 函數僅允許屬性加權。當使用 pg_trgm 擴充功能時，開發人員需要自行根據相似性實作排序。
在以搜尋為中心的資料庫中，結果排名、屬性優先級、匹配的單字數量和查詢的精確度等概念都是一等概念。它們匹配高階 API，允許對搜尋行為進行明確的微調。這使得非技術、業務利害關係人更容易理解這些概念。這被認為是 Bookshop 選擇 Meilisearch 作為其電子商務搜尋的關鍵原因。
8. 錯失 InstantSearch 函式庫
在搜尋體驗方面，網站和應用程式通常會實作相同的使用者介面模式：文字搜尋欄、多面向的核取方塊列表、範圍滑桿、排序選單、頁面導覽等等。開源的 InstantSearch 函式庫以 JavaScript、iOS 和 Android 的 SDK 形式提供了所有這些功能的實作，以小工具的形式提供。
當上市時間至關重要時，很難忽略這些優點。在 Algolia 的支持下，InstantSearch 函式庫被廣泛採用，並且一些搜尋引擎資料庫都配備了與 InstantSearch 相容的 API。請閱讀我們的 Nuxt 電子商務搜尋指南，以了解如何使用 Vue 實作 InstantSearch 小工具。> 偏好 React？請閱讀我們關於使用 React 搭配 InstantSearch 的教學。</Callout>
9. 雲端支援有限
在外包伺服器的佈建、維護和擴展是雲端時代的常見策略。團隊可以專注於為使用者提供價值，而不是管理伺服器。Postgres 與其他資料庫一樣，在各種雲端產品中提供受管服務。不幸的是，受管服務通常會有局限性。
就 Postgres 而言，實作最先進的全文搜尋需要安裝擴充功能。此外，微調語言字典和更多配置需要存取檔案系統。不幸的是，這意味著許多功能在雲端環境中無法使用。
為了實現基礎架構的委派，搜尋引擎通常會提供專用的雲端服務。這些客製化的平台不會妥協，並允許使用完整的搜尋功能。此外，客戶還可以從針對其搜尋使用案例量身定制的優質 SLA、支援和其他企業服務中受益。
Postgres 是一個出色且靈活的資料庫，可以實作許多自訂的 All-in-one 解決方案。它的全文搜尋功能可能足以滿足基本搜尋，但在即時搜尋和相關性問題方面則略顯不足。這些限制在大數據集上會變得更糟。這是很自然的，因為 Postgres 是資料庫，而不是搜尋引擎。
Meilisearch 是一個開源搜尋引擎，旨在建立快速且相關的搜尋體驗。它的目標是在為最終使用者提供最先進體驗的同時，提供簡單直觀的開發人員體驗。您可以透過在本機執行 Meilisearch 或在 Meilisearch Cloud 上免費建立帳戶來試用。
深入了解 Meilisearch 可以為您的業務帶來的價值
如需了解更多關於 Meilisearch 的資訊，您可以加入 Discord 上的社群，或訂閱電子報。您可以查看產品路線圖並參與產品討論來了解更多關於產品的資訊。
