Cassandra Schema - DBA concerns

hi @maxim ,

Our Cassandra DBA have raised below concerns on the schemas created. Pls help address them.

  1. executions and queue_metadata table
    a) Multiple blob type columns
    b) Multiple collection type columns (maps, list set)

Updating Collection type columns in cassandra do lead to tombstones in the table and as the data size grows causes issues with read latencies and high garbage collection on DB side.

The executions table seems to be a table with high partition size, given the number of blobs and collection types it has. Request you share what may be avg partition size of this table. This table is likely to observe tombstones as data grows

  1. All the tables has compaction strategy defined as LevelTieredCompactionStrategy. Request you to share if we have any rationale behind configuring all the tabes with the same compaction strategy.

  2. Secondary indexes are part of the schema. We would suggest to avoid using indexes. Point queries in cassandra run with partition keys and clustering columns in the WHERE clause would give optimal performance
    CREATE INDEX cm_lastheartbeat_idx on cluster_membership (last_heartbeat);
    CREATE INDEX cm_sessionstart_idx on cluster_membership (session_start);