cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-8986) Major cassandra-stress refactor
Date Wed, 18 Mar 2015 11:50:38 GMT
Benedict created CASSANDRA-8986:
-----------------------------------

             Summary: 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
            Assignee: Benedict


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)

Mime
View raw message