[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690482#comment-17690482
]
Josh McKenzie commented on CASSANDRA-18134:
-------------------------------------------
bq. to write compatible stuff if a feature flag is off is more complex than
making sure we can write old version sstables
I've always found our "drop the previous version's ser/deser code like it's hot
and YOLO on to the new thing" stance on our various formats and versions
perplexing. Seems like it'd be minimal effort to keep at least n-1 version
writers around so we can better handle mixed version clusters (to allude to
Yuki's recent comment on CASSANDRA-8110), plus it'd arguably make the downgrade
process Claude's looking into a lot more straightforward and "native".
bq. Medium term, 5 is probably preferable
I agree w/this sentiment; adding a 3rd token to the versioning that we can
increment in minors as needed is the most flexible and "reality-complimentary"
design of the ones listed above IMO.
> Improve handling of min/max clustering in sstable
> -------------------------------------------------
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
