ES使用中遇到的坑
1.ES分页超过10000条报错
es 默认采用的分页方式是 from+ size 的形式，是一种逻辑上的分页，在深度分页的情况下，采用from,to方式进行分页效率会非常的低,例如以下查询
1 GET /student/_doc/_search
2 {
3 "query":{
4 "match_all": {}
5 },
6 "from":5000,
7 "size":10
8 }
ES并不是单纯的查询5000-5010这10条数据,而是在各个分片上匹配排序并得到5010条数据，协调节点拿到这些数据再进行排序等处理，然后结果集中取最后10条数据返回。随着分页深度的加深，ES的分页效率会越来越低，甚至OOM。
ES为了性能默认情况下限制了分页的深度，如果不做任何配置，ES只能查询前10000条数据，也就是 max_result_window = 10000。如果分页到10000条数据以上，ES会报错。
解决方法：
- 调大max_result_window的值
- 使用scroll进行分页
- 使用search_after进行分页(官方推荐)
2.ES 返回结果total始终是10000
1 {
2 "took" : 48,
3 "timed_out" : false,
4 "_shards" : {
5 "total" : 1,
6 "successful" : 1,
7 "skipped" : 0,
8 "failed" : 0
9 },
10 "hits" : {
11 "total" : {
12 "value" : 1000,
13 "relation" : "eq"
14 },
15 "max_score" : null,
16 "hits" : [
17 {
18 "_index" : "bank",
19 "_type" : "_doc",
20 "_id" : "0",
21 "_score" : null,
22 "_source" : {
23 "account_number" : 0,
24 "balance" : 16623,
25 "firstname" : "Bradshaw"
34 },
35 "sort" : [
36 0
37 ]
38 },
如上是是Es一次普通查询返回的结果集
- hits 用来实际搜索结果集
- hits.total 是包含与搜索条件匹配的文档总数信息的对象
- hits.total.value 表示总命中计数的值（必须在hits.total.relation上下文中解释）
要注意的是hits.total.value返回的值不一定是准确的，默认情况下，hits.total.value是不确切的命中计数，在这种情况下，当hits.total.relation的值是eq时，hits.total.value的值是准确计数。当hits.total.relation的值是gte时，hits.total.value的值是不准确的。需要设置track_total_hits为true，才能使hits.total.value的结果准确
1 GET /student/_doc/_search
2 {
"track_total_hits":true;
3 "query":{
4 "match_all": {}
5 },
6 "size":0
7 }
当然如要统计文档数量我们更推荐使用count，而不是通过hits.total.value来表示.
参数track_total_hits可以控制total值的准确性，可以设为false、true或正整数。
- 当为false时，不再返回total计数，total始终为1；
- 当为正整数时，表示精确的命中文档计数，例如为1000时，此时如果命中结果小于或等于1000时，value是精确的计数，relation是eq，如果命中的结果数大于了1000时，此时value等于1000，relation是gte，如果需要精确统计结果数，这个值要设置的很大或者设为true
- 当track_total_hits设置为true时，hits.total.value的值始终是准确的但是会影响查询性能。
3.terms分桶聚合结果不准确
ES基于分布式，每一个搜索请求都是分发到所有的分片上单独处理，最后汇总结果。聚合也是这样操作。
在 Terms Aggregation 的返回中有两个特殊的数值
doc_count_error_upper_bound：被遗漏的 term 分桶包含的文档有可能的最大值，也就是没有在这次聚合中返回，但是可能存在的潜在聚合的值。sum_other_doc_count: 处理返回结果 bucket 的 terms 以外，其他 terms 的文档总数（总数 -返回的总数），这次聚合中没有统计到的文档数。
因为ES为分布式部署，不同文档分散于多个分片，这样当聚合时，会在每个分片上分别聚合，然后由协调节点汇总结果后返回。聚合结果会按照value从高到低进行排序。terms聚合也可以指定一个size，表示返回聚合的数量，如果设置size为3，则表示返回value排名前三的结果，这时每个分片都只聚合了本分片中排名前三的桶。其他没有统计到的文档数由每个节点返回后，汇总为此元素。sum_other_doc_count显示多少，就表示有多少个文档没有参与此次聚合。所以terms聚合并不是准确的聚合
解决
- 当数据量大时，可以不设置分片，所有数据在一个分片上
- 聚合时调大shard_size 参 数，降低 doc_count_error_upper_bound 来提升准确度默认shard_size = size *1.5 +10
- size调大，提高聚合结果的数量，可以保证结果近似准确。
4.ES时间类型的查询和存储问题
在Elasticsearch内部，不论 date 是什么展示格式，所有date类型数据（时间字符串 or 时间戳等）在 Elasticsearch 内部存储时全部都会转换成 UTC时间戳（并且把时区也会计算进去），最后以milliseconds-since-the-epoch 作为存储的格式。date类型字段上的查询会在内部被转为对long型值的范围查询，查询的结果类型是字符串。
- GMT:格林威治标准时间
- UTC:世界协调时间
- DST:夏日节约时间
- CST:中国标准时间
具体细节参照博客https://blog.csdn.net/lijingjingchn/article/details/106925871
我们的项目中为了避免时区问题用到了两种方案
-
ES中Data类型的数据指定格式化方式，数据存入ES使用 字符串的日期时间，查询ES也直接使用字符串的日期时间
PUT test-date { "mappings": { "time": { "properties": { "date": { "type": "date", "format": "yyyy-MM-dd HH:mm:ss" } } } } } POST test-date/time/1 { "date":"2017-09-15 14:50:16" } GET test-date/time/_search { "query":{ "term": { "date": { "value": "2017-09-15 14:50:16" } } } } -
ES的日期时间使用long类型的时间戳存储，日期时间类型的数据存入ES先用Java将其转为时间戳再存入ES。同样查询时也将日期时间转为时间戳再进行查询
