I have been experimenting with storing images in InfluxDB, so far it works fine. I encode the images to a base64 string, send to a MO, then pull the string out the other end and recreate the image.
I have a scenario where I want a short RP (like 5 minutes) where I can remotely trigger screen capture of some remote devices, it would capture fairly infrequently in relation to the 1 second metric data being captured. The metric data will indicate a problem with software or UI programs running on the remote device (think locked down interactive kiosks), which will trigger the screen to be captured every 10 seconds (rolling 5 minute retention period) and sent back for analysis (remote troubleshooting) before the client(s) even notice something was wrong.
My question is, what affect will this type of MO type & size have on the rest of the DB? Is there potential for it to negatively impact the usual metric (a bunch of floats, say 10 fields & 3 tags per MO) storage & retrieval?
We don’t typically test with very long strings like what you might see from base64 encoding screenshots, so I think you’re on the right track if you store the image data in a separate RP from your metrics. That way there will be separate shards, and separate compactions, for the image data. If anything really strange happens, your metric data should be unaffected.
Unfortunately, as of 1.2, the minimum RP duration and minimum shard duration are both 1 hour. Issue 7939 is related. Even at a 1h duration, I would generally expect everything to “just work”, but it’s possible that you may run into some edge cases related to compacting very long strings, if you have many screenshots being gathered at the same time. Otherwise I would expect storage and retrieval to be unaffected.
On a side note: a few months ago, I wrote a proof of concept utility (influx-blob) to split an arbitrary binary file into chunks, encode those chunks with z85, and concurrently store each piece into an InfluxDB instance. The utility isn’t quite production ready – be ready to hack the code – but it may be useful if you run into issues with the current approach.
