全文搜尋方式總覽
全文搜尋（Full-Text Search）是在大量非結構化或半結構化文字中，依關鍵字、片語或語意找出相關內容的能力。實作方式很多，差異主要在於：要不要獨立搜尋服務、資料量與查詢複雜度、是否需要中文分詞／模糊比對／排序調校，以及維運成本。
下面依常見分類列出主要方案； 本站目前已收錄 OpenSearch 相關筆記。
方式一覽
| 分類 | 代表方案 | 典型情境 |
|---|---|---|
| 資料庫內建 FTS | PostgreSQL、MySQL、SQLite | 資料量中小、希望少一個元件 |
| 專用搜尋引擎（自建） | OpenSearch、Elasticsearch、Solr、Meilisearch、Typesense | 大量文件、複雜查詢、需調校 relevance |
| 託管 / SaaS | Algolia、Azure AI Search、AWS OpenSearch Service | 快速上線、不想自維運叢集 |
| 快取 / 嵌入式 | Redis Stack（RediSearch）、Lucene 衍生函式庫 | 低延遲、資料已在 Redis、或嵌入應用程式 |
| 文件 / NoSQL 內建 | MongoDB Atlas Search、Couchbase FTS | 文件模型為主、搜尋與主資料同叢集 |
| 語意 / 向量搜尋 | pgvector、Pinecone、OpenSearch k-NN | 以語意相似度找內容，常與關鍵字搜尋混合 |
| 簡易替代（非真正 FTS） | LIKE / ILIKE、應用層過濾 | 原型、極小資料集；不建議當正式全文搜尋 |
資料庫內建全文搜尋
直接在既有 RDBMS 上建索引與查詢，適合不想多維運一個搜尋服務、查詢量與資料量在中等以下的場景。
| 資料庫 | 機制概 要 | 備註 |
|---|---|---|
| PostgreSQL | tsvector / tsquery、to_tsvector()、GIN / GiST 索引 | 功能完整，中文常搭配 zhparser 等擴充 |
| MySQL | FULLTEXT 索引（InnoDB / MyISAM） | 5.6+ InnoDB 支援；ngram 可輔助中文 |
| SQLite | FTS5 虛擬表 | 嵌入式、單機、輕量 |
| SQL Server | CONTAINS / FREETEXT、全文目錄 | 企業環境常見 |
優點： 架構簡單、交易與搜尋同一資料源、備份流程一致。
限制： 複雜 relevance、聚合、高併發搜尋時，通常不如專用引擎；進階功能（同義詞、facet、建議詞）需額外開發或外掛。
專用搜尋引擎（自建）
以倒排索引（inverted index）為核心，專門處理搜尋、排序、聚合與分析，適合日誌、商品、文章、知識庫等大量可搜尋內容。
| 方案 | 說明 |
|---|---|
| OpenSearch / Elasticsearch | 同一系譜的分散式搜尋與分析引擎；功能最完整，叢集維運成本較高。本站已有 OpenSearch 筆記。 |
| Apache Solr | 同樣基於 Lucene，偏企業與批次索引場景 |
| Meilisearch | 開源、設定簡單、即時搜尋體驗好，適合產品內搜尋 |
| Typesense | 開源、低延遲、API 友善，常與 Meilisearch 比較 |
| Manticore Search | 從 Sphinx 演進，支援 SQL 介面與即時索引 |
| Sonic | 極輕量、適合小型索引與 autocomplete |
優點： 分詞、模糊搜尋、boost、facet、highlight、聚合等成熟；可水平擴展。
代價： 需同步主資料庫與索引、監控叢集健康、版本升級與 mapping 設計。
託管與 SaaS 搜尋服務
由雲端廠商或第三方負責索引、擴展與可用性，適合快速上線、團隊不想維運 OpenSearch 叢集。
| 服務 | 說明 |
|---|---|
| Algolia | 文件站、電商常見；即時索引與搜尋 UX 佳（本站 Docusaurus 筆記見 Algolia 實作） |
| Azure AI Search（原 Cognitive Search） | 與 Azure 生態整合，支援向量與語意排名 |
| AWS OpenSearch Service | 託管 OpenSearch / Elasticsearch，仍須理解 index 與 shard 設計 |
| Google Programmable Search | 偏網站搜尋框嵌入，客製化深度有限 |
快取層與嵌入式方案
| 方案 | 說明 |
|---|---|
| RediSearch（Redis Stack） | 在 Redis 上做全文與 secondary index，適合已重度使用 Redis 的系統 |
| Apache Lucene | Java 生態底層；ES / Solr 皆基於此 |
| Tantivy（Rust）、Bleve（Go）、Whoosh（Python） | 嵌入應用程式的搜尋函式庫，適合單機或邊緣部署 |
文件資料庫與 NoSQL
| 方案 | 說明 |
|---|---|
| MongoDB Atlas Search / 文字索引 | 文件與搜尋同一產品線，Atlas 上功能較完整 |
| Couchbase Full Text Search | 內建 FTS，適合 Couchbase 為主儲存的專案 |
| Amazon CloudSearch | 較舊的 AWS 託管搜尋，新專案多改 OpenSearch Service |
語意搜尋與混合搜尋
傳統 FTS 依關鍵字匹配；語意搜尋則用 embedding 向量 找「意思相近」的內容。實務上常見 hybrid search：關鍵字 + 向量分數加權。
| 方向 | 代表技術 |
|---|---|
| 向量儲存 | pgvector、Milvus、Qdrant、Pinecone、Weaviate |
| 搜尋引擎內建 | OpenSearch k-NN、Elasticsearch dense_vector |
| 應用層 | 先向量召回，再用 BM25 / 關鍵字重排 |
這類方案適合 FAQ、知識庫、RAG；但需額外處理 embedding 模型、索引更新與評估指標。
簡易替代（通常不算正式 FTS）
| 方式 | 限制 |
|---|---|
LIKE '%keyword%' / ILIKE | 無法分詞、難用索引、效能差 |
應用層載入後 filter / includes | 僅適合極小資料集 |
外部搜尋 API（Google site:） | 無法搜尋私有或未公開內容 |
原型階段可用，正式產品應規劃上述其中一類 FTS 方案。
如何選擇（簡表）
| 需求 | 可優先考慮 |
|---|---|
| 資料已在 PostgreSQL、查詢不複雜 | PostgreSQL FTS |
| 大量文件、複雜查詢、要自建 | OpenSearch / Elasticsearch、Meilisearch、Typesense |
| 不想維運叢集 | Algolia、Azure AI Search、AWS OpenSearch Service |
| 產品內即時搜尋、開源、好上手 | Meilisearch、Typesense |
| 以語意找答案、RAG | 向量 DB 或 OpenSearch k-NN + hybrid |
| 已在用 Redis 且索引不大 | RediSearch |
本站已收錄
- OpenSearch 單節點、Replica 與 Cluster Health 整理 — 叢集健康狀態、primary / replica 分片與開發環境設定
其他方案（PostgreSQL FTS、Meilisearch 等）可依實際專案需求再補充子頁。