Field value types cannot differ within a shard, but they can differ across shards.
So what’s a shard:
Each shard contains a specific set of series. All points falling on a given series in a given shard group will be stored in the same shard (TSM file) on disk.
And a series is:
A logical grouping of data defined by shared measurement, tag set, and field key.
I kind of read this as “one shard contains only one series” but now I realize it doesn’t actually say so.
So which series share a shard and which end up in different shards (and thus can have different types for the same field)?
@AndreKR Field types are scoped to a measurement. While it’s true that different shards can contain the same field of different types, this is more of a quirk than a feature and will lead to issues down the line (especially if you’re planning to upgrade to v3). Best practice is to always ensure a field has the same type when in the same measurement. Trust me, this will make your life easier.
A shard is essentially a storage mechanism that uses time bounds to segment or partition data. A single shard can contain multiple series, but it will only contain points between timeA and timeB. At query time, the query engine can quickly identify what shards contain the queried data, read only those shards, and ignore all the rest. This makes queries much more performant.
However, if you query a field that changes type between shards and your query reads data from shards with a differing type, you will get a type conflict at query time.
Like I said, being able to change the type of a field between shards is more of a quirk than a feature. There’s a reason for it, but it’s an edge case.
