有朋友問到，我的這個專案跟lucene的區別，下面說說。
開發這個之前我也考慮過lucene，但在仔細看了lucene之後，有4個地方讓我覺得不舒服，於是突然就萌生了想自己做乙個這樣的東西出來的想法。
1. lucene本身只是乙個檢索框架，需要做成完整的搜尋引擎的話還需要再去學nutch，然後再去研究兩者之間的整合，這過程理解起來不容易；
2. lucene對資料庫的支援度不好，雖說有資料庫擴充套件包，但lucene主頁上的faq也說了，並不理想。而對於大規模資料我比較傾向於資料庫，所以在當時在看lucene時第一想法其實是能不能開發乙個更好的基於資料庫擴充套件包，不過後來發現這個擴充套件好複雜。
3. lucene對中文的支援度不夠(雖然有很多人做了中文的擴充套件就是了）；
4. 最後一點，也是讓我最不舒服的一點，lucene的源**，如果有看的人應該可以發現，很多地方並不是很符合物件導向的，看起來很費勁，也很難理解。例如，因為我英文語法不行，所以英文分析參照了lucene（org.apache.lucene.analysis.porterstemmer這個類），發現lucene的處理方法是傳入乙個字串後，定義全域性變數做下標，利用全域性下標在字串之間移動處理（其中還有一些方法是單純用於移動下標的，意義不明……）。很難表達我當時那種感覺，總之，感覺很彆扭，不自在。或許這樣做可以提高分詞的效能，但我還是比較喜歡物件導向的處理方法；
在之後做jbox的時候，就是根據上面對lucene不滿的地方做的。
1. jbox最首要的目的，是簡單。要讓開發變得更簡單，個人認為，這是框架的首要責任。當然，或許目前我這個作品可能依然不夠簡單性，在後續的版本我會繼續努力改進。
2. jbox第二個目的是純粹的面向資料庫。因為相信有很多人跟我一樣，應用程式都習慣搭建在資料庫上，由其是大規模的資料。目前的版本中，持久層是用hibernate做的，這影響了儲存索引時的效率，我在嘗試寫儲存過程來代替hibernate在儲存的部分的功能，以提高效率，後續的版本會追加這一點；
3. jbox分詞的出發點不是西方文字，而是中文（畢竟還是母語熟悉，其他語言的分詞好難懂，嗚嗚……）。分詞部分完整的我沒有看lucene怎麼實現，jbox的實現方式是利用責任鏈對多語言文字進行切詞，雖然目前僅實現了英文跟中文就是了。（德文的切法正在看lucene的實現中，就如上面所說的，難懂……）；
4. jbox的結構是盡量按物件導向的思想設計的，目前我還在繼續改進中。其實如果單單只是要搜尋引擎的功能，3個月前我就已經做好了。但為了讓其結構更容易理解，更容易擴充套件，更加貼近物件導向，這個過程整整消耗了我3個月時間。（想想真很辛苦，我也要上班養活自己，時間都是擠出來的，唉。）；
5. 最後，類似google那樣相關詞搜尋的功能，lucene沒有吧？這個就如我上面帖子裡說的，我已經實現了，只是還沒整理。相關演算法的**也在審稿中，9月15號後才能知道結果（編輯部回答時15號後在問，沒說15號後多少，嗚……）；
最後，jbox當然不可能代替lucene，我也沒那麼自大去做這種事。例如lucene在檔案索引，資料庫索引方面我是暫時沒打算做的。jbox的當前目的只是，**上的搜尋引擎，其他的檢索還是要lucene。
關於我的部落格
csdn註冊2年多了，我的部落格一直很沉寂。而今天，我決定開啟部落格了。今天和家人打 談到工作的事情，打著打著突然就沉默了，不是別的，只是覺得工作生活很沒意思，我終究還是成了學生時代所看不起的人 蠅營狗苟 庸庸碌碌的上班族。學生時代的光環正在消退，現在的我，激情找不到釋放的口子，興趣被工作時間碾壓殆...
關於我的2106
轉眼間2016走到了盡頭。人們需要儀式感，所以無論情不情願，總要和過去的自己訣別一番。儘管你我都知道，明年不會是乙個更新的自己，只會是乙個更老的自己。只是當你在午夜檢點行藏，追憶過去的365個日夜，回想年初制定的那些計畫，有太多的事情值得仔細思量。知乎是乙個讓人著迷的地方，人們用各式各樣的方式展示他...
關於我的ccf
這應該是這個專題的最後一篇博文了。首先，關於我。我去年9月份就參加過ccf csp的認證，考的自認為還行，260分。也許是感覺太行了，遠超出了我的預想，最後出完成績比大部分上一屆的人考的成績還高，心中不免有一些小驕傲，也就造成了考完試後的那整個學期飄飄然的感覺，都忘了自己是誰了。考完試不久就參加了h...