How to manage Cassandra schemas

[yurishkuro]

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

There are some PRs in progress that alter the database schema (e.g. #979, #793).

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

We do not have established process on versioning the schema.

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

n/a

Any open questions to address

• Do we want a new versioned file for every change in the schema?
• How do we do evolutions?
  • Should each new schema version come with an upgrade script, like ALTER TABLE ... ADD column type;?
  • Should we provide data migration scripts, e.g. to rewrite dependencies in [cassandra] Remove SASI index from dependencies table #793?

[jpkrohling]

Do we want a new versioned file for every change in the schema?

Yes.

How do we do evolutions?

There are quite a few solutions out there for RDMBS that would apply here as well, at least conceptually. One popular choice is liquibase (looks like they do support Cassandra!). Basically, whenever the script runs, it checks a "version" table and see which migrations need to be executed. For most operations, there should be a "up" (apply) and a "down" (rollback) step.

For Kubernetes environments, I'm expecting the Operator to handle this, by running the create-schema batch job backed by the docker image jaegertracing/jaeger-cassandra-schema.

Should we provide data migration scripts, e.g. to rewrite dependencies in #793?

What happens if we don't? Would the data store be left in an unusable state?