Database design advice needed

#1

Hi all.

I’m working on setting up a machine to log a bunch of control system values (about 2200 of them) for monitoring and logging purposes. They are all basically “key:value” pairs, and I need to log them more or less continuously (once per second). Most of these values are only logged and never queried, unless there is an incident and we need to go back and diagnose the situation, but that will be exceedingly rare (hopefully).

Can anyone suggest a “best practices” approach to this? I have tried putting everything into one monolithic Measurement as “Value:{value} Tag:key={key},foo={bar}”, and also one Measurement per “key”, logging only value (and the auxilliary tags). Both approaches showed a slow, but disconcerting increase in memory usage over the course of a week. We’re planning a year’s retention, so a 4 GB increase per week is going to be a problem. But that might be related to my next question:

Can anyone suggest a good approach to determining reasonable shard durations? We will rarely query data older than an hour or two (for graphs and statistics), so intuitively I’m guessing a short duration, but will this create a lot of overhead?

And finally, if we decide to go for a shorter shard group duration, is there an easy way to dump and re-insert the data we have already gathered? It’s not mission critical, but having historical data to play with would be very useful for the rest of the development. (I tried exporting everything with “influx_inspect export”, but I stopped it after 100 GB of text. :wink: )

Thanks for any advice!

0 Likes

#2

Hi @vidarino ,

this link contains good information concerning shard duration …
shard group duration

hope this answers your questions ?

0 Likes