转聚合查询变慢详解Elasticsearch的GlobalOrdinals与HighCardinality

  假设有10亿条数据&＃xff0c;每条数据有一个字段status&＃xff08;keyword类型&＃xff09;&＃xff0c;其值有三种可能性&＃xff1a;status_pending、status_published、status_deleted&＃xff0c;那么每条数据至少需要14-16 Bytes&＃xff0c;也就是说需要将近15GB内存才能装下所有数据。

Doc | Term
-------------------------------
0 | status_pending
1 | status_deleted
2 | status_published
3 | status_pending


  为了减少内存使用&＃xff0c;考虑将字符串排序后进行编号&＃xff0c;形成一张映射表&＃xff0c;然后在每条数据中使用相应字符串的序号来表示。通过这样的设计&＃xff0c;可以将所需内存从15 GB减少为1 GB左右。
  这里的映射表&＃xff0c;或者说映射表中的序号&＃xff0c;就是Ordinals。

Ordinal | Term
-------------------------------
0 | status_deleted
1 | status_pending
2 | status_publishedDoc | Ordinal
-------------------------------
0 | 0 # deleted
1 | 2 # published
2 | 1 # pending
3 | 0 # deleted


什么是Global Ordinals? 

  当我们对status字段做Terms聚合查询时&＃xff0c;请求会透过Coordinate Node分散到Shard所在的Node中执行&＃xff0c;而针对每个Shard的查询又会分散到多个Segment中去执行。
  上述的Ordinals是per-segment ordinals&＃xff0c;是针对每个Segment里面的数据而言&＃xff0c;意味着同一个字符串在不同的per-segment ordinals中可能对应的序号是不同的。比如&＃xff0c;在Segment 1中只有status_deleted&＃xff08;0&＃xff09;和status_published&＃xff08;1&＃xff09;两个值&＃xff0c;而Segment 2中有3个值&＃xff1a;status_deleted&＃xff08;0&＃xff09;&＃xff0c;status_pending&＃xff08;1&＃xff09;&＃xff0c;status_published&＃xff08;2&＃xff09;。
  这样就面临一个抉择&＃xff1a;方案一&＃xff0c;在完成per-segment的查询后&＃xff0c;将相应的序号转换成字符串&＃xff0c;返回到Shard层面进行合并&＃xff1b;方案二&＃xff0c;构建一个Shard层面的Global Ordinals&＃xff0c;实现与per-segment ordinals的映射&＃xff0c;就可以在Shard层面完成聚合后再转换成字符串。
  经过权衡&＃xff0c;Elasticsearch&＃xff08;Lucene&＃xff09;选择了方案二作为默认方法&＃xff1a;构建Global Ordinals。

为何会影响聚合查询?

  构建Global Ordinals的目的是为了减少内存使用、加快聚合统计&＃xff0c;在大多数情况下其表现出来的性能都非常好。之所以会影响到查询性能&＃xff0c;与其构建时机有关&＃xff1a;

• 由于Global Ordinals是Shard级别的&＃xff0c;因此当一个Shard的Segment发生变动时就需要重新构建Global Ordinals&＃xff0c;比如有新数据写入导致产生新的Segment、Segment Merge等情况。当然&＃xff0c;如果Segment没有变动&＃xff0c;那么构建一次后就可以一直利用缓存了&＃xff08;适用于历史数据&＃xff09;。
• 默认情况下&＃xff0c;Global Ordinals是在收到聚合查询请求并且该查询会命中相关字段时构建&＃xff0c;而构建动作是在查询最开始做的&＃xff0c;即在Filter之前。

  这样的构建方式&＃xff0c;在遇到某个字段的值种类很多&＃xff08;即下文所述的High Cardinary问题&＃xff09;时会变的非常慢&＃xff0c;会严重影响聚合查询速度&＃xff0c;即使Filter出来的document很少也需要花费很久&＃xff0c;也就是上文笔者遇到的问题&＃xff0c;即在High Cardinary情况下&＃xff0c;构建Global Ordinals非常慢。因为我们新加的hash字段对于每条数据都不一样&＃xff0c;所以当写入越来越多的数据后&＃xff0c;聚合查询越来越慢&＃xff08;大概超过5000W条之后&＃xff09;。

有哪些优化方法&＃xff1f;

  虽然在Lucene 7.1中&＃xff0c;针对global ordinals的构建有些优化&＃xff08;LUCENE-7905&＃xff09;&＃xff0c;但是仍然不能避免这样的问题。目前有这样几种优化方法&＃xff08;或者说是缓解之法&＃xff0c;目前尚未发现完美的方法&＃xff09;&＃xff1a;

• 增加Shard个数。因为Global Ordinals是Shard层面的&＃xff0c;增加Shard个数也许可以缓解问题&＃xff0c;前提是&＃xff1a;第一&＃xff0c;要能确定有问题的字段的值种类可以通过该方式减少在单个Shard中的量&＃xff1b;第二&＃xff0c;确保Shard的个数增加不会影响到整体的性能。
• 延长refresh interval&＃xff0c;即减少构建Global Ordinals的次数来缓解其影响&＃xff0c;前提是要能接受数据的非实时性。
• 修改execution_hint的值。在Terms聚合中&＃xff0c;可以设置执行方式是map还是global_ordinals&＃xff0c;前者的意思是直接使用该字段的字符串值来做聚合&＃xff0c;即无需构建Global Ordinals。这样的方式&＃xff0c;适用于可以确定匹配文档数据量的场景&＃xff0c;并且不会引起内存的暴增&＃xff0c;比如在笔者的业务场景中&＃xff0c;每次只查询2小时内的数据量。这也是当前我们的优化方法。

GET /_search
{"aggs" : {"tags" : {"terms" : {"field" : "status","execution_hint": "map" }}}
}


  相信看完上文&＃xff0c;读者已经知道什么是High Cardinality了。所谓High Cardinality&＃xff0c;指的是Large Number of Unique Values&＃xff0c;即某个字段的值有很多很多种&＃xff0c;比如笔者业务中的那个hash字段。在Elasticsearch&＃xff0c;High Cardinality会带来各种问题&＃xff0c;百害而无一利&＃xff0c;所以应该尽量避免&＃xff0c;避免不了也要做到心中有数&＃xff0c;在出问题时可以及时调整。

• High Cardinality会导致构建Global Ordinals过程变慢&＃xff0c;从而导致聚合查询变慢、内存使用过高。
• High Cardinality会导致压缩比率降低&＃xff0c;从而导致存储空间增加&＃xff0c;特别是像hash值这样完全随机的字符串。
• 对High Cardinality字段执行Cardinality聚合查询时&＃xff0c;会受到精度控制从而导致结果不精确。

  本文结合笔者在实践过程中遇到的由High Cardinality引起Global Ordinals构建过慢&＃xff0c;从而导致聚合查询变慢的问题&＃xff0c;阐述了Global Ordinals和High Cardinality两个核心概念&＃xff0c;希望对遇到类似问题的人有所帮助。目前&＃xff0c;针对我们的业务场景&＃xff0c;相关的调整有&＃xff1a;第一&＃xff0c;使用"execution_hint": "map"来避免构建Global Ordinals&＃xff1b;第二&＃xff0c;尝试在数据上传端增加对压缩友好的唯一键来作为去重对象&＃xff0c;比如uuid4&＃xff1b;第三&＃xff0c;减小index的切割时间&＃xff0c;比如从weekly index变成daily index&＃xff0c;从而降低index中单个shard的数据量。