Redis 竟然能當搜尋引擎用：一場被延遲數據重新炒熱的選型討論

2026 年 9 月 10 日，掘金上一篇題為「推薦一個比 ES 快 5 倍的搜尋引擎」的技術長文再次被推上熱門。文章的主角是 Redis Search，Redis 官方在記憶體資料庫上打造的全文搜尋模組。這類「某工具比某工具快幾倍」的標題在技術社羣從不新鮮，但這一篇之所以被反覆轉發，是因為它踩中了很多後端工程師日常最痛的那幾個點：叢集難養、延遲不穩、機器費用壓不下來。

把時間點講清楚：Redis 具備搜尋能力並不是新聞。早在 2021 年，RediSearch 模組就已經對外提供全文檢索，而到了 Redis 8.0，官方把搜尋、向量檢索、二級索引這些能力進一步整併進核心。這篇文章的價值在於它把累積了幾年的能力演進，與工程師當下的成本焦慮接上了線。

為什麼快：從「去倉庫找」變成「桌上拿」

要理解 Redis Search 與 Elasticsearch 的差異，用一個辦公室的比喻就夠了。

Elasticsearch 的本體是 Lucene 索引，資料主要放在磁碟上，查詢時靠記憶體映射檔案來加速。這就像你把所有檔案放在樓下的倉庫，平常把常用的幾箱搬上樓放在手邊，找東西大多很快，但一旦要翻的東西不在手邊那幾箱，就得下樓一趟，時間說不準。

Redis Search 的索引則是全量常駐記憶體，查詢時完全沒有磁碟 I/O，等於把所有檔案都攤在桌上，伸手就拿。這就是延遲差距的來源：文章引用的第三方實測數據顯示，相同硬體條件下，Redis Search 的搜尋延遲 P99 約 1.2 毫秒，Elasticsearch 約 45 毫秒；索引更新時間一邊是 50 毫秒，另一邊是 2 秒。

還有一個工程師比較少注意到的開銷：段合併。Lucene 為了維持查詢效率，需要定期把小索引段合併成大段，這個過程會喫掉大量 CPU 與 I/O，也是查詢延遲抖動的常見來源。Redis Search 的索引採增量更新，少了這個背景打掃的動作，延遲自然穩定。另外 Redis 8.0 的查詢執行支援多執行緒，官方宣稱查詢處理能力可擴展 16 倍。

官方數據要怎麼讀

原文引用了 Redis 官方部落格對 OpenSearch 的基準測試：單客戶端向量搜尋快 18 倍、多客戶端 QPS 高 52 倍、查詢延遲低 106 倍。第三方實測則是索引更新快 40 倍、記憶體在 1TB 資料量下 8GB 對 24GB、並發連線上限五萬對五千。

這些數字方向上合理，因為架構差異就擺在那裡，記憶體對磁碟本來就不是同一量級的較量。但讀數據時有兩件事必須放在心上。

第一，基準測試是廠商自己做的就該打折讀。Redis 拿自家最強的場景去比，是行銷慣例，Elasticsearch 陣營也有自己的對照測試。第二，「省記憶體」的說法要分清楚：Redis Search 常駐記憶體的是索引，這正是它的成本結構所在。當資料量大到索引本身就裝不進記憶體時，帳就不是這樣算了。記憶體的單位價格遠高於磁碟，搜尋場景一旦規模膨脹，Redis 那邊的硬體帳單可能反而比較嚇人。

什麼場景該認真考慮它

回到日常。什麼樣的團隊該把 Redis Search 放進評估清單？

一種是商品搜尋、即時選單過濾、即時通訊記錄檢索這類「查詢量高、資料量中等、延遲要求苛刻」的場景。原本就已經在用 Redis 做快取的系統，等於搜尋功能就住在同一個進程裡，不必為了搜尋再養一套 JVM 叢集，維運複雜度直接降一級。對小團隊來說，「少一套要照顧的系統」往往比快五倍更有感。

另一種是向量檢索。隨著檢索增強生成（RAG）應用普及，很多系統需要一個低延遲的向量資料庫。Redis 8.0 把向量搜尋整進核心，對已經部署 Redis 的團隊來說，等於少引入一個新組件。

反過來說，如果你的需求是海量日誌分析、複雜的聚合報表、需要磁碟級容量與完整生態的企業搜尋，Elasticsearch 仍然是對的工具。它幾十年累積的分詞器、權限體系、視覺化工具鏈，不會被延遲數字抵銷。

這種「同一張桌上擺滿同類工具」的局面，在開發者工具圈已經反覆出現，先前我們整理過三十三個 AI 編程工具擠在同一份清單上的現象，背後的邏輯是共通的：基礎軟體的邊界正在鬆動，原本各司其職的元件，一個個往「多合一」的方向長。

選型前該問自己的三個問題

沒有最好的引擎，只有對得上場景的引擎。評估時與其糾結「快幾倍」，不如先回答三個問題。

資料會長到多大？索引能不能一直塞進記憶體，決定了這條路的天花板。團隊有多少人力顧基礎架構？如果只有一兩個人，砍掉一套 Elasticsearch 叢集的維運負擔，價值可能超過一切性能差距。查詢模式是即時互動還是批次分析？前者 Redis Search 有明顯優勢，後者別折騰。

掘金那篇文章的留言區有個說法值得記下：多數團隊的搜尋延遲問題，根源不在引擎選錯，而在索引設計與查詢寫法。換引擎是最後一步，前面幾步沒檢查，換了也一樣慢。

這場討論真正的訊號，是 Redis 這個人人以為只是快取的老面孔，正在把自己重新定位成文件資料庫、向量資料庫與搜尋引擎的三合一基礎元件。對使用者的意義很實際：下一次系統要加搜尋功能時，選項清單上多了一個比過去輕得多的候選人，而評估它的正確姿勢，是先量自己的資料規模與延遲需求，再回頭看那些漂亮的倍數。