Open wyndhblb opened 8 years ago
agreed.
the spec currently says
the metric (timeseries) identity is directly tied to the metric key (if any) and tags values (but not their order).
did you see anything that contradicted this concept, or some wording that should be changed?
i think just a little clarity, i read the but not their order
as saying not the "value" order. Perhaps just changing it to
the metric (timeseries) identity is directly tied to the metric key (if any) and tags values independent on the tags name ordering.
it's also a bit confusing that if the metric key
is determined by the tags themselves, what is the metrics key
other then the identity of the tags? Unless you are assuming some format as follows
mykey name=val name=val metaname=val value time
But is that not the same thing as
what|type=mykey name=val name=val metaname=val value time
I realize it's up to the storage engine to determine it's "Unique ID" factor. But a bit of clarity around this can help with other systems that may to interact with the storage engine from other systems.
Since tagging formats and systems tend to have alot of "pass through" context (much like HTTP headers). "Unique-ness" or IDs should not be based on the tag ordering, as down stream systems can continue to add tags. And like HTTP headers the "value" is what is important (labels are important to, but their ordering is not). So i propose that any "unique-id" generator needs to sort the tags by name.
In this fashion
name1=val1 name2=val2
andname2=val2 name1=val1
really mean the same thing and thus should not be considered "different"i.e.
input of
nameZ=val1 nameY=val2
would be converted whenever the ID was generated tomakeMeYourStorageId("nameY=val2 nameZ=val1")