[denysvitali]

Because you're suddenly putting metrics (that should belong to a time-series database) into a full-text search database.

The result is a dashboard that takes ages to load just to show a trend in values.

I think it's using the wrong tool for the job, but maybe it's just me.

[beardface]

Elasticsearch is fine for time series data. A lot of tasks are actually easier with time series data. You add a field called `@timestamp` to your documents and a lot of analysis becomes possible, like date histograms, date range queries, ML jobs, etc.

Immutable time series data like logs and metrics are a great fit for Elasticsearch due to the way Lucene stores data. Documents in Lucene are immutable so an update in Elasticsearch is creates a new document and places a tombstone marker on the old one. Immutable data means you don't have to tolerate those inefficiencies.

Dashboards don't load the entire dataset by default. I can't remember what the exact default time range is but I think it's ~15 minutes or so. They're fairly quick to render in Kibana.

Elasticsearch is a great tool for observability data (logs, metrics, and APM data). Elastic's tooling makes a lot of this really easy in most cases.

[nemo44x]

I think you may want to check your mappings/templates. There are a lot of data types for this kind of data and they don't rely on the inverted index that you would use for searching fields. Lucene, which Elasticsearch is built on, has a feature called "doc values" that stores data as column-oriented fields. This makes for the fast aggregations, sorting, and grouping for numeric and text fields.

One of the main strengths of Elasticsearch is that you can use it for searching and aggregating in a single query. But you need to ensure you are searching on fields that are indexed for search and sorting/aggregating on fields that are indexed for that.