如題，做lucene搜尋引擎時遇到的問題，不太會web程式設計。只知道jsp支援從頁面調後台，沒用什麼框架。
現在給出自己的一些設計思路，不一定高效，不一定主流。
我後台有個searchservice，其中有函式，大致是這樣的：
public searchresults search(string keyword);要求1. 硬性要求： 同一次搜尋，只呼叫一次search函式。即從第n頁轉到第m頁時，不應該再去呼叫search（邏輯上應該搜一次就夠了）
要求2. 非硬性要求： 頁面之間盡量不要傳遞bean（不會，現學麻煩）
要求1要滿足，有兩種方法
方法1.1. 頁面之間傳遞searchresults引數，這與要求2矛盾，先不考慮
方法1.2. 在後台搞乙個能定製返回第幾頁的資訊的函式，如getresults(int pageindex)，這實際上是在後台把也分好，前台直接呼叫
畫了3小時左右，將方法1.2.實現出來了，發現速度太慢，因為後台是直接把所有資料全搜出來，然後放全記憶體裡進行分頁。
像google那樣的引擎100%採取的是某種lazy-fetch策略。
改吧。
好了，畫了5個小時，改了個lazy-fetch版的出來。在這需要說明，我頁面的顯示結果
並非直接來自索引。實際上，我是用索引取出物件（我的物件是開源專案，簡稱專案）名稱，然後再用名稱去查資料庫，取出結果中要顯示的其他字段。那麼之前的耗時可能是有兩方面：
1. 從索引中取出hit doc中專案名稱的耗時，如果有》10^4的結果，這會很顯著
2. 通過名稱去查資料庫的耗時，我用了hibernate，但資料量一大，耗時還是顯著
經過簡單分析，我認為2的耗時更大。因此考慮將其defer到各個頁面(lazy-fetch，即進入每個頁面在去針對該頁做步驟2，這樣一次取的資料量就在10~20 tuple這個量級了)。
這裡為什麼不把步驟1也defer呢？我有我的考慮。在我的應用中，索引搜尋的hit doc與顯示的結果專案並非一一對應，而是
好，現假設1可以defer，即
每頁去取自己的hit document，從中找到專案名字段。因此
每頁都應知道自己的hit document是哪些。
但是一頁結果（比如對應20條條目）究竟能對應幾個，哪幾個hit document，必須在知道後才能確定。迴圈依賴，這事沒法做。
最後就只defer了2，不知道我這種模式下能否defer 1，請高人支招。。。（我猜谷歌等要麼就是defer了1的，要麼就是他的索引和顯示條目之間嚴格11對應，響應速度那麼快）
使用lucene對搜尋結果排序
lucene預設根據匹配度對搜尋結果降序排,如果對某個域進行排序?通常分兩步 step1 建索引時 newfield audittime row.get audittime tostring 關鍵點是你需要排序的字段建索引時應該採用 field.index.un tokenized,至於需不需要 f...
使用lucene對搜尋結果排序
lucene預設根據匹配度對搜尋結果降序排,如果對某個域進行排序?通常分兩步 step1 建索引時 newfield audittime row.get audittime tostring 關鍵點是你需要排序的字段建索引時應該採用 field.index.un tokenized,至於需不需要 f...
lucene 對搜尋結果進行排序
1 在indexsearcher類中包含了幾個可過載的search方法，有乙個對結果進行排序的search方法宣告為 search query,sort public classsortingexample private directory directory public sortingexam...