De-conflate local from remote service names

[codefromthecrypt]

Especially mentioned in #1794, local and remote service names are undeniably serving different use cases, yet currently conflated in the api.

/services -> only local serviceNames
/remoteServices?serviceName=X -> new: only remote serviceNames for auto-complete
/spans?remoteServiceName=X -> new: to restore functionality @llinder mentioned

cc @openzipkin/ui @bulicekj

[codefromthecrypt]

oh wow.. cassandra tests pass now :) someone quick take a photo!

[codefromthecrypt]

@zeagord you and I both forgot to check this!

[codefromthecrypt]

@zeagord here was the secret to causing us to figure out if we really work when schema isn't updated

[zeagord]

:) I totally forgot about this.

[codefromthecrypt]

I am nearly done the hard parts. just have to implement query support for cassandra and cassandra v1. after that, it is easy

[codefromthecrypt]

@openzipkin/cassandra I'm a little stuck on the best way to model the remoteServiceName=X query.

I'm thinking about adding this for the remote service index. only other option I can think of is adding a SASI field on spans of r_service. thoughts?

CREATE TABLE IF NOT EXISTS zipkin2.trace_by_service_remote_service (
    service       text,             //-- service name, or blank to support queries without service name
    remote_service  text,             //-- remote service name
    bucket        int,              //-- time bucket, calculated as ts/interval (in microseconds), for some pre-configured interval like 1 day.
    ts            timeuuid,         //-- start timestamp of the span, truncated to millisecond precision
    trace_id      text,             //-- trace ID
    PRIMARY KEY ((service, remote_service, bucket), ts)
)
   WITH CLUSTERING ORDER BY (ts DESC)
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy'}
    AND default_time_to_live =  259200
    AND gc_grace_seconds = 3600
    AND read_repair_chance = 0
    AND dclocal_read_repair_chance = 0
    AND speculative_retry = '95percentile'
    AND comment = 'Secondary table for looking up a trace by remote service name. service column may be blank (when only looking up by remote_service). bucket column adds time bucketing to the partition key, values are microseconds rounded to a pre-configured interval (typically one day). ts column is start timestamp of the span as time-uuid, truncated to millisecond precision.';

Note: this would be in addition to trace_by_service_span, and require a client-side join if other parameters are sent (similar to how we do with annotation query).

Another option is to extend trace_by_service_span multiplying rows there by remote service name. This would be simpler to query... Not sure what's better? throwing this out to get feedback.

[michaelsembwever]

is adding the tables trace_by_service_remote_service and remote_service_by_service the only actual change in the file's diff?

[codefromthecrypt]

yes, the other changes were moving the indexing near the tables they indexed as it was confusing me (at the cost of confusing you in this review.. sorry)

[codefromthecrypt]

cassandra 3.11.3+ done (except some unit tests which all around need to be added but saving for later)
next up cassandra 2.2+ impl (cassandra-v1)

[codefromthecrypt]

will merge this prior to the cassandra v1 impl as it was too hard to see what changed #2492

[codefromthecrypt]

ok cassandra v1 "done" (same quality caveat)

now I will do a quality sweep including unit tests and README updates. if the build is green, it is testable

[codefromthecrypt]

only task left is unit test sweep.. doing that now.