核心提示:采取双索引机制,一搜索,一存储。缺点显然而见1 内存使用方面,明显多加载多一份索引,有相当一部分内存浪费了2 合并或切换索引时,明显多合并或者切换索引的时间与CPU占用率了3 所有结果缓存均在用内存保证.内存用量明显加大.而我当时想设计的思想是,采用单索引机制,索引仅仅用来搜索,采用Tokyocab...
采取双索引机制,一搜索,一存储。缺点显然而见 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的造成的,这个我也不太肯定.反正硬盘读写的灯闪得很厉害.