Hi @karl -
I’m not sure if you’re using influxv2 OSS or cloud but my advice here should apply to both. The storage engine uses gzip compression for strings already. If you convert the dict to a base64 string, you won’t get the compression advantage (since you already compressed it essentially). I suspect you are storing many of these dicts with overlapping key names. I would not compress in advance to allow compression across dicts.
If these dicts become very long strings, you may run into the length limit (~64k roughly I believe). Additionally, I would store the string as a field so that it is not indexed (i.e. don’t use a tag for this value). Indexing longs strings is expensive and you said you don’t need to query for these directly.
This is my expectation, depending on the characteristics of your data and how it serializes, your mileage may vary. If you’re on influx oss, you’ll be able to A/B test different approaches and the impact on data volume on disk and query time. My general suggestion is to stick the serialized value into a field and continue until the performance is unsatisfactory and then you can iterate on improving it.
Let us know how it works out! Storing metadata like this is a nice use case.