[
https://issues.apache.org/jira/browse/CASSANDRA-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077449#comment-14077449
]
Benedict commented on CASSANDRA-7631:
-------------------------------------
I'm fairly dubious that we can _reduce_ the complexity of the options with
airline. We have two extra layers of nesting that it does not support - we have
groups of related options (that function like commands, except that multiple
are specified per run) that specify/enforce which options are
permitted/*required* together in that group; and we have specialised individual
options that support complex grouping of information.
The tool is unintuitive initially vs regular command line tools because it
introduces new syntax to cope with the complexity. I'm all for improving the
options, or the syntax, and am open to suggestions, but I'd want to see a
mock-up of how the options would alternatively be represented with airline
before embarking on a mission to change them. Given the way airline works I
suspect we'd end up with a flat namespace and a morass of random letters like
we had previously, making it very hard to impose constraints on
permitted/required option combinations.
Suggestions/patches certainly welcome for improving the documentation either
way though.
> Allow Stress to write directly to SSTables
> ------------------------------------------
>
> Key: CASSANDRA-7631
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7631
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Russell Alexander Spitzer
> Assignee: Russell Alexander Spitzer
>
> One common difficulty with benchmarking machines is the amount of time it
> takes to initially load data. For machines with a large amount of ram this
> becomes especially onerous because a very large amount of data needs to be
> placed on the machine before page-cache can be circumvented.
> To remedy this I suggest we add a top level flag to Cassandra-Stress which
> would cause the tool to write directly to sstables rather than actually
> performing CQL inserts. Internally this would use CQLSStable writer to write
> directly to sstables while skipping any keys which are not owned by the node
> stress is running on. The same stress command run on each node in the cluster
> would then write unique sstables only containing data which that node is
> responsible for. Following this no further network IO would be required to
> distribute data as it would all already be correctly in place.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
