-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Influxdb - Grafana stack is not scalable due to unsupported time roll up #4605
Comments
Highly related to #2625. Not quite a duplicate, but likely a fix for one addresses the other. |
Tangentially related to #1994 as well. |
I also think this should be fixed in InfluxDB. Maybe we could use a dedicated tag which defines the function (mean, count, sum, ...) to use for aggregation? E.g.:
This would lead to better performance on all queries with include a GROUP BY statement, but increases the database size. It could be difficult to figure out what's the optimal size/interval for these precomputed roll ups. I don't know what's Graphite is doing here. |
Largely addressed by #6910 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Still relevant imho as intelligent rollups didn't land |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Still relevant as can be seen in #7198 |
Yes, I also would like to see a solution in Grafana because I do not think InfuxDB will add that feature soon :-( |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I see that still relevant |
I like this simple proposal of having conditional query in Grafana but is it the right place to request this? |
Influxdb has the nice feature to roll up time serie data into larger time buckets via continous queries. This can tremendously speed up a query that needs to display two years of data that was originally sampled at 1Hz.
Grafana will however creates a select query on the original time serie and request a dynamic groupby time based on how far it is zoomed out. Influx will thus crunch all data points in that two year interval. There is no way in Grafana to specify to switch to the time rolled up continous query based on the groupby interval. This could potentially fixed in Grafana, however...
Grafana points out that Graphite automatically rollup its measurements as part of there measurement definition. An queries will thus automatically pick the best internally precalculated time roll up table to execute the query. Graphite therefore always answers within about 100ms. My experience with Influx is that it can take 30sec easily to return the result of a very zoomed out time serie. See grafana/grafana#420 for more details.
This is basically a very nasty interface problem between Grafana and Influxdb and I see no urgency on either side to solve it while it is the number one performance bottleneck in this popular stack as far as I'm concerned.
The question:
Can the influx query engine use the knowledge its continous queries definitions to optimise the query engine path to use the pre calculated continous query data when a time groupby is requested on the original serie?
The text was updated successfully, but these errors were encountered: