Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add FindTraceIDs to the spanstore.Reader interface #1241

Closed
vprithvi opened this issue Dec 6, 2018 · 2 comments
Closed

Add FindTraceIDs to the spanstore.Reader interface #1241

vprithvi opened this issue Dec 6, 2018 · 2 comments
Assignees

Comments

@vprithvi
Copy link
Contributor

vprithvi commented Dec 6, 2018

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

Have an caching layer which retrieves full traces from cache.

Finding traces matching a criterion involves finding matching traceIDs and then retrieving them. These are separate concerns for both ES and C*.
I would like the interface to maintain these as separate concerns so that a caching layer may make decisions on where to retrieve traces from.

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

The current interface,
FindTraces(ctx context.Context, query *TraceQueryParameters) ([]*model.Trace, error)
is pretty coarse and doesn't allow for easily inserting a cache.

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

Add a FindTraceIDs(ctx context.Context, query *TraceQueryParameters) ([]model.TraceID, error) to the spanstore.Reader interface

@yurishkuro
Copy link
Member

yurishkuro commented Dec 6, 2018

+1, always wanted it.

Don't quite agree with your stated use case, but where it's definitely useful is when splitting span storage (e.g. a KV store like Cassandra) and span indexing (e.g. Pinot).

One issue with adding it to the Reader is how the query service is going to use it. E.g. if it always does Find first, followed by Get, then it introduces unnecessary 2nd query to the database even when the request could've been resolved in one query. However, by having FindTraceIDs in the interface allows us to implement a decorator Reader that implements Get by calling Find on one storage and then Get on another.

@vprithvi
Copy link
Contributor Author

vprithvi commented Dec 6, 2018

Having FindTraceIDs in the interface allows us to implement a decorator Reader that implements Get by calling Find on one storage and then Get on another.

Precisely - this is exactly what I want to do!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants