问题描述
大家说说Lucene针对以下这种大数据量分页场景，有没有必要改进的。。。真的很痛苦！我们的项目就要求用lucene，不用oracle，数据量又大，分页这里是个性能瓶颈，搞不定啊！TopScoreDocCollectorf=TopScoreDocCollector.create(10000010,false);indexSearcher.search(query,f);TopDocstopDocs=f.topDocs(10000000,10000010);遇到这种大数据量问题，很痛苦，我们的业务数据量是高达上1000万的，按照每页显示10条，查询到上百万页的时候，如果用TopScoreDocCollector.create(10000010,false);这个方法，命中数量就要先查出10000010个ScoreDoc对象在内存里面，然后再截取10000000到10000010，这个过程中会出现一次内存瞬间高涨。。。。即内存里面瞬间会有10000010个ScoreDoc对象，转换成内存大小有近400MB左右，占用内存相当大。针对上面这种大数据量分页场景，真希望lucene能提供一种简洁的分页方法，比如传递两个下标,start和end，直接在最低层返回10000000到10000010的ScoreDoc对象，这样内存里面最大的ScoreDoc只有10个，而不是一次性返回10000010个ScoreDoc对象，将内存撑大到溢出。。。。
解决方案
解决方案二：
我们数据量几亿条也没事啊但是查的数不准比如我查江苏江西的数据也出来了不知道你们那分词库用的什么查出来的数据准吗
解决方案三：
就空格分词，我们业务不复杂，不是搜索引擎软件，但是要求不用数据库，关键是我们软件性能要求高，而且总运行内存只有1G，所以要想管理上千万的数据量，这个Lucene分页查询真的有问题，主要是点击的页数越多，越往后越慢，因为每次都要命中上千万的ScoreDoc，再在内存里面截取，这种方式真的太耗性能了期待高手解决，谢谢
解决方案四：
支持帮顶，我也遇到这个问题!还有建索引时，越往后索引块大了，每次读写都很慢。。。郁闷，咋办
解决方案五：
该问题已解决！！
解决方案六：
怎么解决的求问
解决方案七：
求解决方案lz
解决方案八：
晕死看了半天结局又是“问题已解决”却没解决方案
解决方案九：
解决方案就是查询的时候重写collector接口的实现类，自定义一个collector对象，所有的排序都是基于collector实现的，可以研究这里然后重构一个
解决方案十：
其实100个记录足够用了百度，谷歌搜索也只是告诉你一共有多少，但它也不会傻了吧唧的把所有结果都查出来放到内存里
解决方案十一：
推荐ElasticSearchSolr