cassandra-commits mailing list archives

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

    [ https://issues.apache.org/jira/browse/CASSANDRA-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14367091#comment-14367091
] 

Benedict commented on CASSANDRA-8986:
-------------------------------------

Well, my goal is to make the tool itself only a little more complex, but to support much more
complex behaviours, which is why it needs a major overhaul (to introduce these behaviours
with the current design would be prohibitively complex). 

We do need to think about the API, though, yes. Perhaps we should actually reduce the number
of knobs: we could simply offer a distribution of total number of CQL rows in a partition,
an optional ratio for each clustering column (defining where the row fan out occurs on average),
and one of a category for how those rows are distributed: uniformly, normally and extremely
are likely sufficient (without any tweaking parameters).

Any other API pieces we should consider? I've considered if we shouldn't support Nashorn for
value generation so that users can define their own arbitrary javascript, but this could have
some performance implications. This is also orthogonal to this change.

Almost all of CASSANDRA-8957 seems subsumed by this to me. Timeseries workloads are orthogonal
to these changes, though, AFAICT, as they're basically just a matter of shifting the value
domain based on seed.

> 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