全文檢索引擎解決什麼痛？與 OLTP / OLAP 資料庫在 System Design 版圖中的座標。

當使用者輸入「分散式 交易 一致性」這類模糊關鍵字，期望在毫秒內從數十億文件中找到最相關結果時，傳統 B-Tree 索引的 LIKE '%keyword%' 或全表掃描完全無法承受。搜尋與分析引擎（Search & Analytics Engine）的核心使命，是以倒排索引（Inverted Index）為基礎，提供全文檢索、相關性排序、聚合分析能力。

以 Elasticsearch（ES） 為代表的全文檢索引擎，在現代架構中幾乎總是旁路索引（Sidecar Index）：authoritative data 仍存於 PostgreSQL / MongoDB 等 OLTP，透過 CDC 或雙寫同步到 ES 承擔跨 shard 搜尋；而 ClickHouse / BigQuery 等 OLAP 則負責大規模聚合報表。三者職責不重疊。

面試高分：能說清楚「為什麼搜尋不直接打 OLTP」以及 ES 在資料流中的位置。

從「文件 → 詞彙」翻轉為「詞彙 → 文件列表」——全文檢索的資料結構基石。

正排索引（Forward Index）記錄「每份文件包含哪些詞」；倒排索引則反過來：每個 term（詞項） 對應一個 posting list（倒排列表），列出包含該 term 的所有 document ID，並附帶詞頻（TF）、位置（position）等 metadata 供評分與短語匹配使用。

ES 中的索引層次

• Index：邏輯命名空間（類似 database），如 products。
• Shard：Index 的水平切分，每個 shard 是獨立的 Lucene index，支援分散式搜尋與寫入。
• Segment：Shard 內不可變（immutable）的 Lucene 片段；寫入先進 memory buffer，refresh 後 flush 成新 segment。
• Document：JSON 文件，含 _id 與 mapping 定義的 fields。

四個層次的包含關係

關鍵在於這四者不是平級，而是層層包含：一個 Index 水平切成多個 Shard，每個 Shard 是一份獨立的 Lucene index、內部由多個不可變 Segment 疊成，Segment 裡才真正存放各 Document 的倒排索引。

巢狀關係 Index ⊃ Shard ⊃ Segment ⊃ Document：搜尋時 coordinating node 把 query 扇出到各 shard，各 shard 在自己的 segment 上查倒排索引，再彙整結果。

Posting List 結構示意

假設三份文件經 Analyzer 後得到 term，倒排索引大致如下：

查詢「分散式 交易」= 取各 term 的 posting list 做交集（AND）或聯集（OR），再依評分排序。

文字如何變成 term？Index-time 與 Search-time 的分析管線必須一致。

使用者看到的「分散式系統」在寫入索引前，會經過 Analyzer 管線拆解成可索引的 term。ES 的 Analyzer 由三部分組成：

1. Character Filters：預處理字元流（如 HTML strip、正規化全形半形）。
2. Tokenizer：切分 token 流（如 standard 依標點切、ik_max_word 中文分詞）。
3. Token Filters：後處理 token（lowercase、stop words、stemming、同義詞）。

Mapping 中常見：title 用 text + analyzer；status 用 keyword 做 filter/aggregation。

Index Analyzer vs Search Analyzer

寫入時用 index analyzer，查詢時用 search analyzer。兩者可以不同（例如 index 用 ik_max_word 提高 recall，search 用 ik_smart 提高 precision），但必須在設計時成對定義，否則 query term 與 index term 對不上會零結果。

端到端追蹤：一個 term 如何從寫入走到命中

以中文欄位示範這條「刻意不對稱」的鏈：index 端用 ik_max_word 切到最細粒度以拉高 recall（存下最多可能被查到的 term），search 端用 ik_smart 切得保守以拉高 precision——兩條管線不同，但共享的 term 讓查詢仍能命中。

Near Real-time 的可搜尋性窗口，以及 BM25 如何把 posting list 變成排序分數。

Refresh：為什麼寫入後不能立刻搜到？

新 document 先寫入 shard 的 memory buffer（Indexing Buffer），此時對搜尋不可見。Refresh 將 buffer flush 成新的 Lucene segment，並開放給搜尋——這就是 ES「近即時（Near Real-time, NRT）」的來源。

• 預設 index.refresh_interval = 1s：最多約 1 秒延遲可搜。
• 大量 bulk 寫入時可暫設 -1 關閉自動 refresh，寫完再手動 refresh，避免每秒建 segment 拖垮 merge。
• refresh=wait_for：寫入 API 阻塞直到下次 refresh，適合「寫完立刻讀」但會拉高寫入延遲。

Relevance Scoring：BM25

ES 預設使用 BM25（Best Matching 25）計算 query 與 document 的相關性。核心直覺：

• TF（Term Frequency）：term 在 doc 中出現越多次，分數越高（但有飽和，避免堆砌關鍵字）。
• IDF（Inverse Document Frequency）：越稀有的 term 權重越高——「的」到處都有，「Raft」很稀有。
• Field Length Norm：短欄位（如 title）中命中 term 比長欄位（body）更有價值。

實務調參常用 boost：title 權重 ×3、tags ×2、body ×1。function_score 可疊加業務因子（銷量、距離、新鮮度 decay）。

Query context（計分）vs Filter context（yes/no + cache）是 ES 查詢優化的核心分界。

模擬 Analyzer 分詞、posting list 交集、以及 refresh 前後的可搜尋性。

下方內建三份技術文章摘要。輸入查詢後，QUERY PIPELINE 會一步步演出「查詢字串 → 分詞 → 逐 term 查 posting list → 依操作符合併 docId → BM25 排序」的完整鏈條。切換 OR / AND 操作符可直接看到 posting list 取聯集還是交集；「寫入新 Doc」+「Refresh」則呈現 NRT 可見性——未 refresh 的 doc 不會出現在結果中。

Demo 簡化真實 BM25（無 field norm 飽和曲線），但保留 term 分詞 → posting list 合併（OR 聯集 / AND 交集）→ TF×IDF 排序的完整直覺與 refresh 可見性語意。

ES 叢集怎麼設計？與 OLTP 如何同步？什麼時候不該用 Elasticsearch？

Elasticsearch 叢集核心概念

• Master-eligible nodes：叢集狀態管理（index/shard 分配），奇數節點防 split-brain（ES 7+ 用 quorum 選主）。
• Data nodes：持有 shard 資料，執行 indexing / search。
• Coordinating node：Scatter-gather——把查詢分發到各 shard，合併結果（query then fetch 兩階段）。
• Replica：shard 副本，提升讀吞吐與 HA；寫入需 primary + replica 確認（依 wait_for_active_shards）。

ES + OLTP + OLAP 三層是大型電商 / SaaS 的標準搜尋分析分層。