3 ms·

Would be great to know the exact data set size (not size in the database). I can't get an order of magnitude sense of what I am looking at without that. I know

Would be great to know the exact data set size (not size in the database). I can't get an order of magnitude sense of what I am looking at without that. I know I can divine it from the parameters to stress, but I have no idea if the row keys generated by different clients overlap and I don't know the default number of columns nor their size. I think it's also important in this kind of benchmark to describe the distribution of access especially for a read intensive benchmark. Without that you really don't know what your are looking at. I am a fan of scrambled Zipfian.

jdf 12y ago
It seems like this info should be front in center in the test. 1M/s 100kb writes is much more impressive than 1M/s 16 byte writes. That said, there's a previous benchmark linked to at the top of the post: http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html http://techblog.netflix.com/2011/11/benchmarking-cassandra-s... The client is writing 10 columns per row key, row key randomly chosen from 27 million ids, each column has a key and 10 bytes of data. The total on disk size for each write including all overhead is about 400 bytes. There are 3 replicas, so figure that in as well.