用法：
在索引模板中添加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可以提高性能，但经过测试，加不加此参数，查询耗时基本没有什么区别。
上面是针对应用的测试，仅供参考。
