ES6.3 index Sorting测试

用法：

在索引模板中添加setting指定排序：

"settings" : {

        "index" : {

            "sort.field" : "enter_time",

            "sort.order" : "desc"

        }

}

也可以指定多级排序：

 "settings" : {

        "index" : {

            "sort.field" : ["enter_time", "camera_id"],

            "sort.order" : ["desc","asc"]

        }

}

用来排序的字段有：允许doc_values的boolean, numeric, date 和 keyword类型

效率测试：

ES版本：6.3.2

总数据量：18,433,120

写数据时，history_fss_data_v1_2_sort_two和history_fss_data_v1_2_sort是按照enter_time 降序排序，history_fss_data_v1_2_sort_uuid是按照uuid降序排序。
查询测试时，图片比对之后按照enter_time 升序排序，结果如下：

 

不图片比对，只按时间过滤，查询测试如下：

查询示例：

  curl -XGET "10.45.157.35:9200/history_fss_data_v1_2_sort/_search" -H 'Content-Type: application/json' -d'

{

  "query": {

    "bool": {"filter": {"range": {"enter_time":{"gte":"2018-09-20 00:00:00","lte":"2018-09-26 23:59:29","format":"yyyy-MM-dd HH:mm:ss","time_zone":"+08:00"}}

      }

    }

  },"from":0,"size":20,"sort":{"enter_time":"desc"}}'

 

测试结果如下：

 

 由于上面的测试性能很差，怀疑是机器本身的性能问题，所以将此机器的es换为5.4.0版本，做如下测试：

索引名：czl_history_fss_data
数据量：18,217,302（61.3G）
（1）图片比对时，1800万数据量比对时耗时： 31347ms（23865ms，16454ms）
                12万数据量时比对耗时：13280ms（292ms）
（2）只做过滤查询的，相同的条件：耗时2398ms  过滤出120339条结果

 

在另一台性能较好的es版本为5.4.0的机器上做相同的测试：

索引名：write_history_ly_compare35
数据量：18025200（61.5G）
（1）图片比对时，1800万数据量比对时耗时： 8778ms
                12万数据量时比对耗时：7169ms
（2）只做过滤查询的，相同的条件：耗时只有164ms  过滤出122612条结果

结论：

1、图片比对时，结果排序测试：
经测试，图片比对时，查询结果按照时间升序、降序排序或者按照相似度排序，耗时没有区别

2、分片数测试：

5.4版本的测试中，把索引的分片数适当调大，可以加快检索，但6.3版本的测试，分片调大，（15个分片与5个分片相比）性能反而下降很多，在测的分片个数为15、13、12、5、3时，5个分片的最快（不知道为什么？）

3、磁盘占用空间测试：

索引时使用时间排序可节省大量磁盘空间（但用uuid排序并没有节省磁盘空间，为什么？）

4、index sorting 测试

图片比对查询时，在1800万多的数据中只搜索一段时间的数据（12万多），同样5个分片，按照时间排序的索引耗时1782ms，没有指定排序的索引耗时16267ms，按照uuid排序的索引耗时21031ms

5、过滤查询测试

不图片比对，只有时间过滤查询时，在1800万多的数据中只搜索一段时间的数据（12万多），同样5个分片，对结果按照时间排序时，按照时间排序的索引耗时2031ms，没有指定排序的索引耗时2436ms，按照uuid排序的索引耗时3094ms；对结果按照uuid排序时，按照时间排序的索引耗时3586ms，没有指定排序的索引耗时3863ms，按照uuid排序的索引耗时2525ms。这里可以看出指定排序后，按照相同的方式查询时，性能更好。如果按时间排序，当取其中一个时间段查询时，性能有大幅度提升，如果查询全部的数据，性能提升不明显。

6、track_total_hits参数测试：

官网上讲，当不需要结果总数（total）时，使用"track_total_hits": false可以提高性能，但经过测试，加不加此参数，查询耗时基本没有什么区别。

上面是针对应用的测试，仅供参考。