Change terms aggregation default execution mode for tsdb

[martijnvg]

An tsdb backing index when current time is before index.time_series.end_time will receive a lot of writes. Building global ordinals doesn't make sense, because it is expensive and the next search can't reuse it.

This change changes the default execution mode for tsdb backing indices where this is the case. The default will then be MAP instead of GLOBAL_ORDINALS.

This should improve query latency.

[elasticsearchmachine]

Hi @martijnvg, I've created a changelog YAML for you.

[elasticsearchmachine]

Pinging @elastic/es-analytics-geo (Team:Analytics)

[jpountz]

As discussed today, it would be nice to have another execution mode that maps values to bucket ordinals like the MAP execution mode, but also takes advantage of the TSDB index sort by caching the bucket ordinal of the previous document. Then if the current document has the same value ordinal as the previous document, we know it has the same bucket ordinal as well and we can skip an expensive lookup in a BytesRefHash.

[martijnvg]

I updated the PR to the suggested change, but instead implemented it as a CollectorSource so that much of the MapStringTermsAggregator can be reused. Unfortunately I'm seeing mixed results in the tsdb k8s rally track. I think this has various reasons:

• There is a bug in the data set. The kubernetes.pod.uid field was is a dimension field contains a unique value per document. But in reality there should only 9932 unique pods in this data set (the cardinality of the pod name field is 9932). The suggested optimisation that was added then doesn't help.
• The result of the queries are noisy. Indexing and searching happens at the same time (which is realistic for many use cases and that is the focus of that track). However because of that the query latency can fluctuate. This makes it difficult to see certain improvements.

The trend looks like that the all the last 15 minute searches benefit from this change. While the last 24 hours searches don't benefit from this change and actually report a worse query latency with this change. I suspect having a heuristic is estimate to match with X percent of the documents would make be helpful here.

I will rerun the rally track when the track's data set is regenerated.

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)