Closed codefromthecrypt closed 5 years ago
note annotation_query would be shorter per span as it only needs to concat annotation and tag pairs (as opposed to also putting in the service name, because the local_endpoint covers this part)
note annotation_query would be shorter per span as it only needs to concat annotation and tag pairs (as opposed to also putting in the service name, because the local_endpoint covers this part)
i don't get this. when we search against that index we still are searching for local_serviceName:annotation
or local_serviceName;tag_key;tag_value
.
i don't get this. when we search against that index we still are searching for local_serviceName:annotation or local_serviceName;tag_key;tag_value.
I mean to say that the serviceName can be refined independent of the ball of tags. for example, span.local_serviceName = foo filtered before annotationQuery. So instead of redundantly encoding the service name in the annotationQuery concatenation, access it as a field.
My assumption is that this could be more efficient, but might be wrong. At any rate, it would be easier to read.
Make sense?
Make sense?
Yup. I've put the extra column in and the extra SASI on it, so to achieve this. It could well be that two SASI indexes working together like this is not faster than having the bigger single SASI. Benchmarking later in the PR will prove that.
The branch has been updated, the main code looks roughly in shape, next to do is get the tests compiling and working.
Resolved via #1758
The cassandra3 type isn't finalized, so we have an opportunity to drop support for complexity around binary annotations and nested endpoints. This might result in the ability of using SASI to index service names (as they are fields in the span now as opposed to nested parts of binary annotation or annotation).
I don't know how well this would go with indexing, but here are the salient changes.
cc @openzipkin/cassandra