Tokyocabinet+Lucene搜索框架

这篇文章来自同事的博客，一篇很好的博客，大家没有注意就沉了，趁这次公司新平台开发的机会，被我发现了。重新贴上来，给大家一个惊喜。更多精彩请访问原文地址：

 

原文地址：http://kernaling-wong.iteye.com/blog/477163

原文标题：tokyocabinet与lucene在搜索上的应用

 

开场白: 一个多月没有写博客了,今天就写点这一个月工作情况吧.新的公司搜索框架最后却不能成功上线运行这点令我很遗憾,结果还是使用旧有的.
背景:
   现在公司一直使用的搜索框架由于内存的使用上及搜索速度和索引的切换方面有比较大的缺憾，首先这里简单说一下以前的搜索框架吧,采取双索引机制,一搜索，一存储。缺点显然而见
   1  内存使用方面,明显多加载多一份索引,有相当一部分内存浪费了
   2  合并或切换索引时,明显多合并或者切换索引的时间与CPU占用率了
   3  所有结果缓存均在用内存保证.内存用量明显加大.

   而我当时想设计的思想是,采用单索引机制,索引仅仅用来搜索,采用Tokyocabinet作为索引内容的保存索引.同时使用Tokyocabinet可 以作为其实搜索结果的缓存,目的在于尽量减少对内存的依赖.但经过好几次实验发现tokyocabinet在长时间,高并发及多线程下速度未能令人满意, 特别在硬盘有其他程序不停读写时效率更低下,有时取出一个document对象居然用了20ms所以决定取消这个机制,改用从lucene的索引中直接取 出document,即以前的搜索索引现在增加了保存内容的功能了.索引大小也由以前索引的1G左右猛增到现在的2.7G左右(250W个 Document)[如图]



大家看完这一个图以后,都应该知道整一个搜索框架的性能瓶颈在哪里.同时我也总结一点这一个特点吧

1  搜索出来的结果存入缓存并不是一个阻塞的过程,而是把搜索结果交给其他线程去做,提高搜索反应速度
2  加载及合并与切换索引的时候比以前快约30%,内存使用满负载运行1天1夜,内存不超过2G
3  搜索结果及搜索缓存队列中增加了java.util.concurrent包下的应用,特别在多线程下效果表现不错,CPU占用率比以前低

缺点:
1  最大的缺憾就是搜索索引体积过大令大高负载的时候令返回结果集的时的速度变慢,在低并发量的时候,返回结果一直都没有问题,只是搜索满负载的时候才会出现,这也是我设计时失误了.
2  硬盘的频繁读写,正所谓省了内存害了硬盘.之前测试跑了几天后发现把公司内部服务器的一个硬盘给搞夸了，不知道是不是tokyocabinet的造成的,这个我也不太肯定.反正硬盘读写的灯闪得很厉害.

后记:
   最终,新的搜索框架因为在高负载的表现未如理想所以公司决定不启用这个新的搜索框架,辛苦这一个多月来的工作在这里画上一个句号,不过还是能学到很多东西,起码对tokyocabinet这个怪兽级的东西反而更充满信心.下面就给一此图看看这一个月内工作成果吧.
公司网站
http://www.jobui.com   是一个职位搜索引擎
http://www.baicai.com 是一个人才网站,提供了职位搜索,简历搜索,公司信息搜索等功能
不过很是很感谢我的同事与我的技术总监,他们为我提供了很多帮助.

搜索框架已经在普通负载下的测试结果

第一次 搜索"公司"


第二次 搜索"公司",因为使用了tokyocabinet的作为结果缓存


再来第一次 搜索"经理"


第二次 搜索"经理"



欢迎大家提出宝贵的意见,
欢迎转载  请注明出处 kernaling.wong  http://kernaling-wong.iteye.com/blog/477163

评论

4 楼 faiinlove 2009-11-05  

fanfq 写道

我们公司也在做一个垂直搜索，我们用的是三方的api主要在android手机上应用，性能很不错，但是一些个性化的搜索及其他功能很繁琐。

针对个性化和特殊应用，应该使用策略模式，对不同的应用，加载不同的策略！

3 楼 fanfq 2009-11-04  

我们公司也在做一个垂直搜索，我们用的是三方的api主要在android手机上应用，性能很不错，但是一些个性化的搜索及其他功能很繁琐。

2 楼 caoyangx 2009-11-04  

希望有相关文档就可以了。

1 楼 faiinlove 2009-11-04  

有没有demo啊？