I’m wondering is there some fundamental data structure difference between Influxdb 1 and 2.
In Influxdb 1, data is outputted as a regular “horizontal” table, while in Influxdb 2, fields are “vertical” and must be pivoted to become a regular table.
Does that mean in Influxdb 1, all fields of same tag-set are stored together, and is naturally “horizontal”, while in Influxdb 2, all fields are separated (like tags) and must be re-joined (by merge-sort)? If that’s true, does that mean when storing data that will have multiple fields (and all fields are required), It’s better to just use Influxdb 1 so that there is no “joining overhead”?
In another word, in my opinion, Influxdb 1 is like filename=measurement+tag set, content=time+fields, while Influxdb 2 is like filename=measurement+tag set+field key , content=time+one field. Is that true?
Hello @zisisnotzis,
Welcome!
There isn’t a difference in data structure between 1 and 2.
Data is ordered by time, indexed by measurement and tags.
You can’t perform any joining in 1 only in 2.
There’s a lot of differences with Flux vs InfluxQL though.
I suggest reading this on converting InfluxQL to Flux:
I also suggest reading this chapter (specifically the section from serires to tables on disk):
And looking into free Flux courses on InfluxDB University:
Let me know if you have questions on any of those.
Edit: Never mind, I didn’t read the link. But interestingly, I thought measurement, fields, and tags are part of the “table name”, and the “actual table” only contains time and value. It seems that they are actually stored as a string or enum?
Also, I’m curious why influxdb is designed like this, because there are cases where fields will always come together (like coordinate or IP address). Won’t saving those fields together as a fixed size binary much more efficient?
====== OLD ======
Thanks for the reply! By “joining”, I mean fields in Influxdb 1 is outputted as a natural table, while in Inlufxdb 2 they must be be pivoted. Will this pivot result in performance penalty?
Hello @zisisnotzis,
No it shouldn’t result in a performance penalty. You also don’t need to pivot the data to visualize it in the same way that you would in 1.x.
