JavaEye 3.0 開發手記之四：Ruby 平台全文檢索方案選型

Java 平台有成熟的 Lucene，但 Ruby on Rails 陣營的全文檢索選擇較少且各有缺陷。JavaEye 3.0 在全文檢索技術選型上經歷了 Solr、Sphinx、Ferret 三條路線的深度評測，最終確定了「離線索引 + Ferret」的工程化方案。

三大候選方案對比

1. Solr + acts_as_solr

Solr 基於 Lucene 提供 HTTP/XML Web Service，跨語言、功能強、緩存優化好。`acts_as_solr` 插件封裝 Ruby 調用。但致命缺點：每次檢索需跨 HTTP 請求 Solr 服務，單頁多檢索場景下延遲不可接受，JavaEye 放棄此方案。

2. Sphinx + acts_as_sphinx

Sphinx 性能極強（150 萬記錄 1-2 分鐘建索引，GB 級檢索 <0.1s），原生支持 MySQL 整合（SphinxSE 引擎可直接 SQL 查詢），並發優秀。但缺乏中文分詞擴展接口，純 C 實現難以集成中文分詞，遺憾放棄。

3. Ferret + acts_as_ferret (AAF)

Ferret 是 Lucene 的 Ruby 移植（核心 C 實現），API 與 Lucene 高度相容。但問題多：

• 不支持中文分詞
• 索引格式與 Lucene 不兼容
• 索引速度慢、穩定性差
• Windows 下搜索崩潰

無奈之下仍選擇 Ferret，但拒絕使用 AAF 插件：

• AAF 綁定 Model 回調實時更新索引，多進程並發寫入極易衝突，DRb Server 也難解決 Green Thread 瓶頸
• 索引粒度綁定 Model 記錄，無法靈活控制（如不索引隱藏貼）

中文分詞：從簡單到精準

初期使用正則按 UTF-8 單字拆分（`RegexpAnalyzer`），效果尚可。長期需實現詞典最大匹配算法，計劃自研 Ruby 中文分詞器。

工程化突破：離線全量索引

面對 8 萬 Topic、30 萬 Post 的數據量，線上實時索引拖垮服務器。利用「全文檢索不需高實時性」特性：

1. 每晚將數據庫導出下載到本地桌面機
2. 本地導入數據庫、執行全量 Ferret 索引
3. 壓縮打包索引文件上傳至服務器替換

代價：搜索結果延遲 24 小時。收益：線上零索引壓力、索引穩定性由本地可控環境保證。這是資源受限團隊的務實之選。