Thoughts on time series database design #149
Replies: 3 comments 1 reply
-
Here are the Thingsboard database schemas. |
Beta Was this translation helpful? Give feedback.
-
Sorry for missing this. For some reason, I do not receive notifications of new discussions, only issues. I'll look into this, but just as a quick comment, since Dan took over the project, Paricia has been using TimescaleDB as backend with one table per day (the default in TimescaleDB+Django, but can be changed to a different thing). I'm not entirely sure what you mean one table per time series. Let's say we have a station uploading data for the precipitation for two months. Is this block of data a time series or does it refer to something else entirely different? |
Beta Was this translation helpful? Give feedback.
-
We also need to keep in mind that as we have moved away from direct SQL calls, but we use higher level Python, we might need to worry more about the performance of operations in Python - using pandas dataframes - than the operations in the database as we will not be doing much beyond querying data out of it. |
Beta Was this translation helpful? Give feedback.
-
Here are some pointers that may be of use for the database design:
Thingsboard is an IoT platform that handles large sensor time series, and supports different database options, including PostgreSQL as the default option. I have not looked in detail at the database schema but it seems to use a table per time series. At first thought this would seem a suitable option for us as well, as most operations on time series will do so on a single time series. Few need to pull multiple time series together.
Thingsboard also supports TimescaleDB and Cassandra. This is probably not needed for us on the short term, but staying close to the Thingsboard schema may help adopting these solutions on the longer term if we would choose to do so.
Beta Was this translation helpful? Give feedback.
All reactions