You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Benedict (JIRA)" <ji...@apache.org> on 2015/02/10 13:05:44 UTC
[jira] [Resolved] (CASSANDRA-8299) cassandra-stress unique keys
[ https://issues.apache.org/jira/browse/CASSANDRA-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benedict resolved CASSANDRA-8299.
---------------------------------
Resolution: Not a Problem
59K keys is 10x the keys specified?
There isn't, admittedly, a way to absolutely guarantee uniqueness of keys. But with n=10000 you will almost certainly get 10k unique keys. I suspect the problem is CASSANDRA-8524, i.e. that prior to 2.1.3 you need to manually specify that your population distribution is sequential with -pop seq=1..10000, as it defaults to uniform otherwise (i.e. you're uniformly sampling 10k items from a population of 10k, so you visit the same key multiple times).
> cassandra-stress unique keys
> ----------------------------
>
> Key: CASSANDRA-8299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8299
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Centos 6.5 Cassandra version 2.1.1
> Reporter: Edgardo Vega
> Assignee: T Jake Luciani
>
> In the old stress tool you could use -n 10000 and get 10000 unique keys in the keyspace.
> In the new stress tool there doesn't seem to be a way to do this. For example if I have the following definition:
> table_definition: |
> CREATE TABLE table(
> key uuid PRIMARY KEY,
> col1 text,
> col2 text,
> col3 text
> ) WITH comment='A table'
> ### Column Distribution Specifications ###
> columnspec:
> - name: key
> size: fixed(36)
> population: uniform(1..100B)
> - name: col1
> size: fixed(100)
> - name: col2
> size: fixed(100)
> - name: col3
> size: fixed(100)
> and then run
> cassandra-stress user n=10000 profile=stress.yaml ops\(insert=1\)
> If you look at the keyspace was only 59000 keys. The new tool needs to be able to generated unique ids. In our tested we want to see how the number of keys effects the cluster when doing queries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)