高效搜索

实时搜索，最重要的就是效率，实时就意味着你只要有更新就要reopen，大量的reopen的效率是很低的，导致搜索变慢。

索引结构 fs+ramX2

更新最大问题就是delete操作，因为delete操作可能是磁盘的，要reopen这个大家伙需要时间会很长，所以要是用filterindexreader，过滤点删除的diocid，这要就不用reopen磁盘索引。

上面的步骤能让你在实时的情况下，不reopen，速度会快上很多。

其他思路可以看看zoie。

另外一个问题就是当数据量很大的时候， 1千万<数据量<1亿，这时候，lucene的速度下降的很厉害，问题在于查找正向文件。所以lucene+nosql的数据库就很有必要，使lucene仅负责搜索。同时nosql的数据库支持分布式，这样能吞吐的数据就更多。

如果数据是实时的，那么缓存的策略就很难做，数据经常变，缓存就成为实时的障碍了，但是是用uid映射后，就能用

利用映射关系作为key，使缓存即能保证性能，有不影响实时。

目前测试了2000w数据，再多mongodb性能就下降的厉害了，没有好的测试机啊。

前面的博客写了，lucene4.0要出自己的filterindexreader了，到时候，可能实现起实时的搜索。会更轻松一点。

搜索，我觉得有几个阶段，和几个比较优挑战的事情

1、控制精度和召回率，实效性和高并发（初级）

--通过分词和构建query来控制，实效和高并发，已方面通过程序，另一方面又换运行环境。

2、数据完整性，不管任何情况，保证一条数据都不丢失

--工作中经常有需要停止搜索服务的时候，这时候更新的一些数据就丢失了（更新以http形式），数据抓取端是不管

     搜索服务是否正常工作的，所以单独做了一台增量的服务器，做了个短线续传的功能。

3、分布式、大规模数据搜索，1亿条以上的长字段全文检索。

--lucene分布式一直是个头疼的问题，hadoop结合lucene还没有比较成熟的（nutch除外），apache推荐katta，

     但是可定制性又不好，是不是该叛变到sphinx下。自己写一个，估计相当的耗时。

4、数据挖掘。智能搜索

--以前一直在用搜索的角度解决数据挖掘应该做的事，现在看来走了些弯路。这段时间主要看看数据挖掘，再提升提升

     搜索质量。搜索质量到最后，拼得就数数据挖掘了