We have developed an application that stores time series data for heating controllers.
Controllers push readout data (around 35 data points) on a scheduled manner and each controller can have a slightly different set of data points from each other.
Originally we were storing all the readouts for all controllers of a given customer inside a single measurement per customer inside a single database. That is, a single database for all of our customers, but each customer has its own measurement in which all its controllers write their data. The readout is tagged after the controller id.
We were not performing any sort of down-sampling and the default retention policy was inifinte.
As the project progresses we are about to start down-sampling the data for query performance reasons and we also want to pre-calculate some useful aggregations.
If we continued with the “current” schema, we would be creating a new measurements per customer to contain the various aggregations we want to pre-calculate and we would be creating multiple retention policies for the down-sampled data.
If this the way forward? Or do you foresee cardinality problems as more customers are added in the future?
An alternative we are thinking as well would be a database per customer, with a measurement with multiple retention policies for the incoming readouts and extra measurements for aggregations?
It all boils down to: is it better for us to have a single database with more measurements vs having multiple databases with less measurements each.
Thanks in advance