[
https://issues.apache.org/jira/browse/CASSANDRA-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14050760#comment-14050760
]
Benedict commented on CASSANDRA-6146:
-------------------------------------
Ok, I've pushed another update to the repository. This makes a few minor change
as well as a major one:
# Default is now to use -mode cql3 native prepared
# Thrift support is fixed for the new schema mode
# Partitions are now generated _completely procedurally_, i.e. if there are C
clustering components each with N items _each time they occur_ (i.e. at each
depth, or with clustering: fixed(N)), then we require O(CN) memory to generate
a partition, not O(N^C)
# We can choose to generate a random ratio of the total rows of a partition for
a single update, and we can choose to batch these in different ways as well
(e.g. we can choose to generate only 2% of a potentially huge partition, and
then choose to submit that in batches of between 10% and 50% of the generated
subset (i.e. between 0.2% and 1% of the total possible partition)). We should
probably expand this to support a hard maximum for batches as well, to ensure
the client can maintain predictable memory utilisation with extreme
distributions, but this is probably not super important right now.
At some point it would be really nice to make the particular row selection for
a given pass predictable, so we can know the exact state of the row on the
server, so we can procedurally generate inserts/deletes and still always
perform queries/deletes on data that we know exists. But I think that's a hard
problem with maintaining minimal client state.
> CQL-native stress
> -----------------
>
> Key: CASSANDRA-6146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6146
> Project: Cassandra
> Issue Type: New Feature
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: T Jake Luciani
> Fix For: 2.1.1
>
> Attachments: 6146-v2.txt, 6146.txt, 6164-v3.txt
>
>
> The existing CQL "support" in stress is not worth discussing. We need to
> start over, and we might as well kill two birds with one stone and move to
> the native protocol while we're at it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
