1、global ordinals
(1)what's this?
当我们使用doc values或者fielddata存储时,在磁盘中存储的值不是真正的字段值,而是一个字典值(ordinal)。当我们进行聚合查询的时候,es会把这个字典值跟真正字段值的映射字典加载到内存中,并对结果集做映射,转化为真正的值。这份映射关系是shard级别的,为这个shard里面是所有segment服务,这也是global的体现。
(2)detail
- 字典关系是lazy init的,只有第一次使用的时候才会加载到内存中。在es的内存表现中提现成fielddata,这也是全keyword的index为什么也会有fielddata使用的原因。只会加载命中的segment的字典不会加载全部。
- 字典关系在shard被触发refresh以后就会失效。下次使用的时候需要再重新构建。所以可以提高refresh_interval的值,减少fresh频率提高字典的生存时间。
2、eager_global_ordinals
(1)what's this?
当在global ordinals的时候,refresh以后下一次查询字典就需要重新构建,在追求查询的场景下很影响查询性能。可以使用eager_global_ordinals,即在每次refresh以后即可更新字典,字典常驻内存,减少了查询的时候构建字典的耗时。
(2)使用场景
因为这份字典需要常驻内存,并且每次refresh以后就会重构,所以增大了内存以及cpu的消耗。推荐在低写高查、数据量不大的index中使用。
(3)使用
PUT my_index/_mapping
{
"properties": {
"tags": {
"type": "keyword",
"eager_global_ordinals": true
}
}}
3、execution_hint
(1)what' this?
上面介绍了global ordinal的使用场景,是doc_values以及fileddata的默认数据架构。除了这种模式,还可以选择map模式。即不再使用字典而是直接把值加载到内存中计算,减去了构建字典的耗时。当查询的结果集很小的情况下,可以使用map的模式不去构建字典。使用map还是global_ordinals的取决于构建字典的开销与加载原始字典的开销。当结果集大到一定程序,map的内存开销的代价可能抵消了构建字典的开销。
(2)how to use?
GET /_search{
"aggs" : {
"tags" : {
"terms" : {
"field" : "tags",
"execution_hint": "map"
}
}
}}
网友评论