Investigate ability to add other long-term storage backends

[valyala]

It would be great if other LTS backends are considered: victoriametrics, m3db, cortex. These backends may provide the following improvements comparing to timescaledb:

• easier to manage
• better compression rate
• better integration with Prometheus ecosystem due to native support for Prometheus querying API, which is used by Grafana for querying Prometheus-compatible datasource
• support for PromQL, which is better suited for typical queries over time series data than SQL, Flux or InfluxQL

[freol35241]

Thanks for an interesting idea. Still trying to grasp the pros/cons/possibilities with this. Some questions that have popped up:

• How do you mean with "easier to manage"? The specific backends? Can you give an example?
• I imagine this would require some kind of platform/framework/plugin architecture of LTSS with each backend as a separate plugin? Do you agree? Or do you envision something totally different?
• Why "just" not implement HA custom component for these other backends directly? Pros/cons?

Interesting read about PromQL, a first for me, thanks.

[valyala]

How do you mean with "easier to manage"? The specific backends? Can you give an example?

For instance, VictoriaMetrics consists of a single self-contained binary, which works out of the box without additional configuration and tuning - see these docs for details.

I imagine this would require some kind of platform/framework/plugin architecture of LTSS with each backend as a separate plugin? Do you agree? Or do you envision something totally different?

I think that it would be better to hardcode other storage backends directly in LTSS. This is easier to do comparing to plugin architecture from development perspective and is better to use from user experience perspective.

[freol35241]

Thanks for some answers, sorry for not getting back earlier, summer vacation time...

I have done some reading up on VictoriaMetrics (nice work!) and the performance seems to be quite impressive in comparison with both TimescaleDB and InfluxDB.

One thing that I have been dwelling on is how to handle the geographical metadata. These are currently treated separately by LTSS to make use of the PostGIS extension to TimescaleDB/PostgreSQL. I assume this would not be a possibility with VictoriaMetrics? Does VictoriaMetrics/PromQL support GIS-enabled queries?

[valyala]

One thing that I have been dwelling on is how to handle the geographical metadata. These are currently treated separately by LTSS to make use of the PostGIS extension to TimescaleDB/PostgreSQL. I assume this would not be a possibility with VictoriaMetrics? Does VictoriaMetrics/PromQL support GIS-enabled queries?

There is no support for GIS-enabled queries in VictoriaMetrics yet. Probably, it will be added in the future. There are the following possibilities exist for working with GIS data in VictoriaMetrics:

• To store coordinates in labels for static sensors which don't change coordinates frequently. For example, temperature{sensor_id="...", latitude="...", "longitude="..."} 12.3. Then it is possible to store additional location-specific labels such as city, building, floor, etc. to all the metrics in order to simplify filtering and grouping the data by these labels via PromQL.
• To store coordinates in a separate time series for sensors with frequently changing coordinates. For instance, latitude{sensor_id="..."} 12.45 and longitude{sensor_id="..."} 43.22. Then it is possible to query sensors with filtering by specific area using MetricsQL queries like the following: temperature if (latitude > 12.34 and latitude < 21.34 and longitude > 45.67 and longitude < 54.76). I think it is possible to add missing GIS-enabled functionality to MetricsQL.

[rds76]

Would be great to add something like "LITE" version setting - without Timescale and GIS, just pure PostgreSQL. Already using your addon with some tweaked code to remove those unwanted dependecy plugins (commented few lines of code on DB creation). Thanks

[freol35241]

@rds76
thanks for the idea. I have created a separate issue for this feature request here: #20

[freol35241]

@valyala
Sorry for my lack of involvement on this topic. My current standpoint is that this is not a prioritized feature of LTSS. Since HA provides a great plugin structure I think it is probably easier to just create another plugin if there is a need for another backend.

[Yamakaky]

@valyala what compression ratio do you expect to get with other backends? With timescaledb compression feature, I get 97-98% compression ratio, 2.3M rows for 19MB total disk size.