# Aggregation with terms and cardinality deliver different results **URL:** \ **Category:** Elasticsearch\ **Created:** [May 9, 2018, 10:01am UTC](https://discuss.elastic.co/t/aggregation-with-terms-and-cardinality-deliver-different-results/131155 "2018-05-09T10:01:42Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![Mark\_Harwood](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood/32/10538_2.png) [@Mark\_Harwood](https://discuss.elastic.co/u/Mark_Harwood)\ **Post date:** [May 9, 2018, 11:11am UTC](https://discuss.elastic.co/t/aggregation-with-terms-and-cardinality-deliver-different-results/131155/2 "2018-05-09T11:11:20Z")
> [@Alexander\_Zerr](#): > > Is it possible to get the correct count from ES like MySql or is ES not the best store to handle my data. See [FAB principle](https://discuss.elastic.co/t/background-count-in-significant-terms-not-consistent/55824/8) which is one of those "pick 2 of 3" conundrums. In a **B** ig distributed system you need to pick between completely **A** ccurate or **F** ast responses. Aggregations are tuned for **FB** but if you really need complete accuracy there are ways of breaking up single requests into many slower calls. It's always going to involve a trade-off whatever technology you use. --- _[View the full topic](https://discuss.elastic.co/t/aggregation-with-terms-and-cardinality-deliver-different-results/131155)._