Jeremy Hanna updated CASSANDRA-8986:
    Labels: LWT stress  (was: stress)

> Major cassandra-stress refactor
> -------------------------------
>                 Key: CASSANDRA-8986
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8986
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Tools
>            Reporter: Benedict
>            Priority: Major
>              Labels: LWT, stress
> We need a tool for both stressing _and_ validating more complex workloads 
> than stress currently supports. Stress needs a raft of changes, and I think 
> it would be easier to deliver many of these as a single major endeavour which 
> I think is justifiable given its audience. The rough behaviours I want stress 
> to support are:
> * Ability to know exactly how many rows it will produce, for any clustering 
> prefix, without generating those prefixes
> * Ability to generate an amount of data proportional to the amount it will 
> produce to the server (or consume from the server), rather than proportional 
> to the variation in clustering columns
> * Ability to reliably produce near identical behaviour each run
> * Ability to understand complex overlays of operation types (LWT, Delete, 
> Expiry, although perhaps not all implemented immediately, the framework for 
> supporting them easily)
> * Ability to (with minimal internal state) understand the complete cluster 
> state through overlays of multiple procedural generations
> * Ability to understand the in-flight state of in-progress operations (i.e. 
> if we're applying a delete, understand that the delete may have been applied, 
> and may not have been, for potentially multiple conflicting in flight 
> operations)
> I think the necessary changes to support this would give us the _functional_ 
> base to support all the functionality I can currently envisage stress 
> needing. Before embarking on this (which I may attempt very soon), it would 
> be helpful to get input from others as to features missing from stress that I 
> haven't covered here that we will certainly want in the future, so that they 
> can be factored in to the overall design and hopefully avoid another refactor 
> one year from now, as its complexity is scaling each time, and each time it 
> is a higher sunk cost. [~jbellis] [~iamaleksey] [~slebresne] [~tjake] 
> [~enigmacurry] [~aweisberg] [~blambov] [~jshook] ... and @everyone else :) 

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to