今天对一个5千万的一个索引的一个普通字段update_time和一个nested的字段sales_info.from 字段做一个range查询，对比一下延迟情况
查询大概100W 量级的结果时
从接过来看，当搜索大概100W的结果时，两者差别不大，都能在20ms的量级时间内完成，而nested 查询会稍微多一点点
查询大概1000W 量级的结果时
这是我连续执行多次的结果，从这个结果可以开始看出差距了
查询大概5000W 量级的结果时
从结果来看，结果集越大，差距就越明显，这里一方面可以看出，结果集非常多时，其实range的查询效率并不是十分理想，所以尽量避免这种会有1000W以上的结果集的range；另一方面，为什么nested在大结果集的时候性能差那么远呢？其实只要profile一下：
尽管两个查询是用的next doc count 都差不太多，但是由于上面是直接使用了IndexOrDocValuesQuery，所以最后算出来就是parent的docIdSets 而下面的查询用的是ESToParentBlockJoinQuery，虽然查出了两千多W结果，然而最后还需要对这两千多万的结果做一次parentJOIN，拿到ParentId的结果集，这个运算在超过一千万的级别以上时耗时就很客观了。
通过上面这样一个简单的测试，还是建议以后在index规划时，尽量避免采用nested方式，并且在对nested字段做大结果集查询时就要小心为妙了！
