Lucene 後分類功能
全文檢索在實務上有許多不同的應用，例如查詢的相關度分數處理、查詢詞的相關提示字元、查詢結果的自動分群與相關詞、查詢結果排名與分數回饋等等，但真正最具有價值的算是查詢結果後分類這個功能，也就是所謂的 Faceted Search。
在 Lucene 上，若也想要有查詢結果能依指定索引欄位進行後分類，那麼 Solr 會是最佳選擇，不必去碰底層的 Lucene，所有的查詢動作都透過 XML/JSON 等 HTTP 方式向 Search Server 查詢，並取回查詢結果，也支援 Faceted Search 功能。當然，要刻程式去呼叫 Search Server 也成，用 Solrj 沒有什麼事是辦不到的。
如果一切都想自己來而不想用 Solr 的話，那麼底層放 Lucene，一般的建索引跟查詢動作都沒問題，要後分類功能時，再補上 bobo-browse 套件就萬事俱備，照著網站提供的範例，就輕鬆擁有後分類的功能了，不過事情如果那麼單純就不會有這篇文的出現了。
遇到的狀況是，設定好要後分類的索引欄位，經過查詢後的確可以拿到後分類的結果，也就是分好類的 item 集合，但是 item 相關的後分類數卻都是為零，看起來應該是在每次分類時，沒有把 hitCount 值做累加，造成值永遠為零的囧境。
臨時的解法是自己手動改 com.browseengine.bobo.api.BrowseResult 這支 class，多加上一個 public method，用來把後分類的 item 集合重新 collect() 過 hitCount 值，確保每個 item 都能被算到︰
public void collect(String facet_field) {
if (null != facet_field && !"".equals(facet_field)) {
for (int i = 0; i < this.getHits().length; i++) {
BrowseHit browseHit = getHits()[i];
if (null != browseHit) {
((FacetCountCollector) this.getFacetMap().get(facet_field)).collect(browseHit.getDocid());
}
}
}
}
這個 method 被呼叫的時機點在 BrowseResult.browse() 取回後分類結果後，再依指定的索引欄位名稱跑一次 collect()，如此一來後分類的 item 名稱有了，每個 item 含的資料筆數也有了。
效能還不敢保證，自己只有小量測試，只先確保出來的資料是對的，至於要怎麼調，就再說吧。
後記︰
自己在全文檢索的經驗都只侷限在公司的產品上，在經過這次短暫的 Lucene 洗禮後，才發現人家做的是有多麼的不同。
感受比較深的比較算是 coding 這方面，API 的用法主要是開發者在思考時的切入角度不同。Lucene 的 API 是訴求使用者直接掌控索引資料，在進行全文檢索時，API 提供較細緻的參數與屬性讓使用者知道在做什麼事，實際的邏輯都放在 API 中，因此是在＂操作＂索引檔案。
而以前的經驗則是透過 API 來＂連線＂Search Server，再告知 Search Server 要做什麼事，有點類似 Solrj 的做法，所有的邏輯都在 Search Server 上完成，client 端不太需要知道自己在做什麼，只要把參數丟過去，結果收回來，就差不多完工了。
做法上各有各的優缺點，也值得做為我們產品研發的借鏡。
