[Lens] Unique count aggregation should have control for precision threshold and warning about estimates

[wylieconlon]

The default precision value of the Cardinality aggregation is 3,000 documents: above 3,000, the precision will drop off. The max value is 40,000 in Elasticsearch. Users should be able to tune this parameter in Lens. I propose that we use a numeric text input with validation instead of a slider, but the second-best option would be grouped button at 1000, 3000, 10000, and 40000 thresholds.

Lens should also provide some helper text to indicate that this is not a precise aggregation. I propose that we put this helper text in the editor panel for Unique count, and that the text should be:

Unique count is precise only when the count is lower than the precision threshold. The estimate will be more accurate for higher thresholds, which uses more server resources.

This text is trying to indicate that the queries won't be slower, but that there are other costs associated to running the high-precision queries. This is based on some of the docs here: https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-cardinality-aggregation.html

cc @cchaos do you agree with the proposal to use a numeric input instead of grouped buttons? A slider would be a bad option here since there aren't many possible options. No design needed.

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[cchaos]

To understand your sentence here:

A slider would be a bad option here since there aren't many possible options.

How would you be able to limit the input in a numeric input?

[wylieconlon]

By using the isInvalid property and not updating the state when it's invalid? Even if we didn't limit it on our end, Elasticsearch would cap the value at request time.

[cchaos]

But how would they know what values are valid if you truly are restricting them? With the EuiRange you could give them very specific allowed increments and values that they can select by using the ticks.

[wylieconlon]

@cchaos I like that proposal, I think we could use a slider with with predefined increments at 1000, 3000, 10000, and 40000 thresholds. I don't think we need the extra color indicator, just a slider with predefined ticks.

[cchaos]

Sweet! You'll probably also want to shorten the labels to 1k, 3k... etc so they don't bump into each other with all those zeros.

[dej611]

+1 https://discuss.elastic.co/t/kibana-calculations-give-wrong-results/339778/11

[markov00]

+1 #179934

[bradquarry]

In my opinion we should not surface an imprecise aggregation type in our core visualization engine to handle what many would expect to be an exact deterministic aggregation result. This impacts business reporting for customers and they seek alternatives.