[
https://issues.apache.org/jira/browse/CASSANDRA-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-8986:
--------------------------------
Assignee: (was: Benedict)
> 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
> Labels: 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
(v6.3.4#6332)
