I sense another definitive guide in our future. š The more I think about the operations aspects I can see plenty of places for use case guidance. Which seems like the right place to tackle this as it gets closer to a release. UCS is a good example of that.
On Tue, Mar 10, 2026 at 3:29āÆAM Alex Petrov <[email protected]> wrote: > Several more quotes that intersect between CEP-57 and CEP-60: > > from CEP-57: > > To treat this problem we should allow users to specify a tableās > atomicity level, for example `partition`, `row` or `none`, and prevent > splitting inside the specified level. > > While implementing flexible placements, we intend to allow tables > belonging to the same keyspace to have ranges that are split between the > nodes differently. Our understanding that this aligns well with CEP-57, > since every table will likely have different partitions with hotspots in > different places. CEP-60 will allow making split points at any point in the > table, and things like repair and streaming for such split tables will just > work out of the box. > > > Implementing a, or improving the existing, mechanisms of collecting load > statistics to form the input of automatic redistribution of data. > > There definitely will be some intersection here, since we are going to be > collecting subrange metrics for load. CEP-60 does not include > change-in-load-triggered automatic redistribution, since our intention was > to limit the scope of CEP, but our ultimate goal does include > auto-balancing. I have a separate document describing all metrics we'll be > adding in detail. It was not included to CEP for scope reasons, but I will > make sure to loop in CEP-57 authors once we start working on this. > > On Mon, Mar 9, 2026, at 11:54 PM, Alex Petrov wrote: > > Great question! > > If one decides to enable tablets and use default flexible placement > mechanism/algorithm, it will pick the best possible fit for the tablet. Of > course one can always override this or pick a custom tablet placement > algorithm. > > Tokens wonāt become less pronounced for things like routing, streaming, or > repair. The only place where this CEP moves from tokens will be the concept > of a node owning a token and token ring derived replication. > > For simplicity I suppose it might be easier to say ārepair tablet Xā or > āreplace replica Y in tablet Zā, etc. But then, tablet is just a > replicated range. > > On Mon, Mar 9, 2026, at 11:31 PM, Patrick McFadin wrote: > > > Thanks, that helps. > > I agree that if tokens remain the underlying range coordinate system, then > CEP-57 is not immediately inconsistent with CEP-60. > > My question is about operators and migrations(my favorite topic). As > clusters move from classic token-derived placements to flexible placements, > should operators continue to think in token-bounded ranges, or do tokens > become mostly an internal detail, and the operational model shift to > tablets or table-specific placement units? > > Patrick > > > On Mon, Mar 9, 2026 at 2:37āÆPM Alex Petrov <[email protected]> wrote: > > > In short, CEP-60 doesnāt suggest weāre moving away from tokens. It adds an > optional opportunity to allow placements to be decoupled from token > ownership. In other words, owned range will still have start and end > tokens, so I donāt see any inconsistency here. > > Iād also like to highlight that anyone who prefers token ownership as a > way of generation of placement maps, this will still be possible, and there > are no plans or intentions for deprecating this. > > Does this clarify relation to CEP-57 for you? > > > On Mon, Mar 9, 2026, at 10:09 PM, Patrick McFadin wrote: > > > I do, actually. I finally got my head around CEP-60 and wanted to ask > about an inconsistency. Your proposal is trying to move away from tokens, > but CEP-57 requires them. From CEP-57: > > the key should be constructed as: ByteComparable.sequence(Token(X, Y), > Serialization(X, Y), A, B, C) > > How is this going to be reconciled? Stay on tokens or change CEP-57? > > Patrick > > On Sat, Mar 7, 2026 at 4:54āÆAM Alex Petrov <[email protected]> wrote: > > > Thanks Jon! Very excited to be working on this. > > Since there has been not much discussion, and from conversations with some > folks on slack and elsewhere it seems like we might be ready to move this > to a vote. > > I will hold it off until Monday in case someone else had any thoughts. > > > > On Tue, Feb 24, 2026, at 10:57 PM, Jon Haddad wrote: > > Alex, > > 12 years ago I filed CASSANDRA-8494 hoping someone much smarter than me > would take on the Herculean effort of completely reworking how we manage > our data. This CEP addresses my wish for incremental bootstrap and also > incorporates tablets, which have been on my radar for a long time. This > work will address some of Cassandra's biggest pain points today for > operators. > Thank you so much for this. I cannot overstate my enthusiasm for this > CEP!! > > Jon > > > On Tue, Feb 24, 2026 at 12:17āÆAM Alex Petrov <[email protected]> wrote: > > > Hi everyone, > > We'd like to propose CEP-60: Flexible Placements [1] for adoption by the > community. Building on CEP-21's Transactional Cluster Metadata [2], CEP-60 > enables incremental, resumable operations, improved cluster density, and > flexibility of data placements / ownership. > > CEP-60 benefits all users by further improving reliability of ownership > operations. With flexible placements, clusters maintain near-optimal load > balance at any size without explicit rebalancing phases. Ownership changes > are broken into smaller sub-range steps that benefit from zero-copy > streaming. > > CEP-60 is designed for incremental delivery: range-aware compaction, > routing key abstractions, and metrics collection are useful on their own > and will ship independently of the flexible placements feature. Existing > token-based and vnode clusters will continue to work (while benefitting > from incremental ops), and flexible placements can be enabled (and later > disabled, if ever needed) on a per-keyspace basis. > > The CEP is linked here: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-60:+Flexible+Placements > > Looking forward to the discussion of this CEP here on the dev list. > > Thanks! > > [1] > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-60:+Flexible+Placements > [2] > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata > > > > > >
