Badger storage plugin: query service to support spanKind when retrieve operations for a given service.

[guo0693]

Requirement - what kind of business use case are you trying to solve?

Related to #1920

Update badger reader and writer such that we can retrieve operations by service name and span kind

Problem - what in Jaeger blocks you from solving the requirement?

Proposal - what do you suggest to solve the problem or improve the existing situation?

Any open questions to address

[burmanm]

I'll add notes here so that I don't forget (or if someone else is implementing):

• A single index key is enough for serviceName, operationName + span.Kind indexing

Thus, replace the following code from reader:

		if query.OperationName != "" {
			indexSearchKey = append(indexSearchKey, operationNameIndexKey)
			indexSearchKey = append(indexSearchKey, []byte(query.ServiceName+query.OperationName)...)
		} else {
			indexSearchKey = append(indexSearchKey, serviceNameIndexKey)
			indexSearchKey = append(indexSearchKey, []byte(query.ServiceName)...)
		}

Instead, write a single key with operationIndexKey and in the form of query.ServiceName+query.OperationName+tags.span.kind. Then, in the reader scanning, take into account the length of the searched index key such as query.ServiceName has total length of serviceName+overhead+timestamp+sizeOfTraceID and not more. This can be added to the scanFunction to skip keys which do not match here (or stop searching if we bypassed the match).

In the cache.go, remove two full-table-scans and replace with one which would warm the cache for both services, operations as well any theoretical operations+kind query.

Bonus is one less key written to the db with a slight increase in complexity for reading.

[guo0693]

Not familiar with badger, but should the key be query.ServiceName+tags.span.kind+query.OperationName because we want to get a list of operation names given the service name & span.kind?

[burmanm]

It slightly depends. There's two different use-cases for that information, fetching the list of operations vs fetching the list of traces. For traces, is the span.kind used or not? You should optimize for that use-case and then the "list of operations" for UI purposes is done with the cache.go and a table scan of possible pairs of span.kind + operations meaning it doesn't really matter in which order they are.

To clarify, the list of available operations is done once in the startup and never again before a restart. So don't optimize for that, but optimize for the use-case of traces-fetching where the order for smaller TraceID scanning is more important.

[guo0693]

Make sense. I didn't know it's also used for fetching traces.