Hello @matias,
I recommend option A.
Essentially you just don’t want to encode a bunch of information in a measurement.
Like instead of
weather.texas.austin temp=77
You want to encode data in tags where applicable
weather city=austin,state=texas temp=777
The drawbacks to A would be minimal…I can think of the following though:
-the different fields are completely unrelated and you’re shoving too many different fields in the same measurement. Let’s say you have 1000 fields (group 1) that you frequently need to query simultaneously and another 500 fields (group 2) that you need to query simultaneously as well. Rather than filtering through 1500 fields to return data from group 1 or group 2, you should store group 1 and group 2 in different measurements.
-maybe you’re building an app on top of influxDB and you’re serving client data. Perhaps you want to keep the data more isolated by storing data in different measurements. Although there aren’t any security benefits to storing data in different measurements (only buckets).
-you don’t ever intend on performing calculations across fields or ever querying for multiple fields simultaneously. you could reduce your flux query by one filter function/one line of code if you keep schema B. But I think this is unrealistic.
I hope this helps! Thanks for your question.
