当数据量超过200W的时候如果全部加载到内存则不太适合了，因为受JVM最大内存的限制（1.2G到3.6G Linux下），加载超过200W索引页面的时候，JVM会溢出。
以下介绍通过几种方式实现超过1000W的索引页面查询响应时间降低到0.5秒以内。
1、让索引尽可能的简单，非必要的索引字段尽可能的删除掉，索引的字段需要正确的区分那些Index ；那些Tokenize、那些Store。
2、将 indexer.minMergeDocs 和 indexer.mergeFactor 调整到尽可能的大。如果索引的页面大小平均在10K，JVM可用的内存是2.6G，则可以将indexer.minMergeDocs 设置为30000（根据页面尺寸定），这对查询的效率影响巨大。
3、将尽可能多的 segemts合并到一起，可以让 一个 segment 包含100W个document 并根据实际情况调整一个segment 包含的 document的数量 。
4、将所有的 index 合并到一起，如果创建索引的时候 indexer.minMergeDocs 是 足够大，则合并以后的index目录下的文件会很少，这将非常的有利于查询性能的提高（我在我的系统里面把大约400W个document合并到一个segments目录下，然后分成5个segment，最后把400W个索引文档合并到一个index目录下，最后产生的index目录下的文件只有10多个，但文件尺寸非常大）。
5、将索引分布在多个JVM。如果单台服务器的内存很大（超过6G），那么可以在一台计算机上开启多个查询服务器，每个查询服务器启动的JVM内存占用会从400M逐渐增加到2G左右，所以如果单个的查询服务器使用的索引文档超过200W，则需要增加足够的内存以应付查询缓存（查询服务器启动时间越长，缓存的内容越多，内存占用越大）。
6、一般的垂直搜索引擎都需要在Nutch 上再做开发，索引的及时更新都会面临一些问题。
索引超过3000W个页面的查询效率调整暂时不能公开，按照以上方式处理会超过1秒，但小于5秒。