- workloads with tens of millions of keys.
-------------------------------------------------
PERF TEST [10485760 keys, 3072 block size]
SEQUENTIAL WRITE
num_keys: 10485760
time: 8445.95s
payload: 30 GB
bandwidth: 3.81393 MBps
SEQUENTIAL READ KEY/VALUES
key count: 10485760
time: 1038.41s
payload: 30GB
bandwidth: 31.0206 MBps
TRUNCATE TABLE
time: 7.40911s
payload: 30GB
bandwidth: 4347 MBps
build-opt/util/cassandra_store_stress --db_size=32212254720 --batch_size=30720
-------------------------------------------------
PERF TEST [1048576 keys, 30720 block size]
SEQUENTIAL WRITE
num_keys: 1048576
time: 993.252s
payload: 30 GB
bandwidth: 32.4311 MBps
SEQUENTIAL READ KEY/VALUES ----------> (Ignore this batch read key/values: one of the pages of the bulk read timedout)
key count: 12000
time: 30.4189s
payload: 0.343323GB
bandwidth: 12.1188 MBps
SEQUENTIAL DELETES
num_keys: 1048576
time: 722.952s
speed: 1450.41 Keys/s
build-opt/util/cassandra_store_stress --db_size=32212254720 --batch_size=30720
-------------------------------------------------
PERF TEST [1048576 keys, 30720 block size]
SEQUENTIAL WRITE
num_keys: 1048576
time: 979.542s
payload: 30 GB
bandwidth: 32.885 MBps
SEQUENTIAL READ KEY/VALUES ----------> (Ignore this batch read key/values: one of the pages of the bulk read timedout)
key count: 1000
time: 9.57564s
payload: 0.0286102GB
bandwidth: 3.20814 MBps
TRUNCATE TABLE
time: 11.9367s
payload: 30GB
bandwidth: 2698 MBps
-------------------------------------------------
PERF TEST [1048576 keys, 1024 block size]
SEQUENTIAL WRITE
num_keys: 1048576
time: 515.004s
payload: 1 GB
bandwidth: 2.08492 MBps
SEQUENTIAL READ KEY/VALUES
key count: 1048576
time: 16.4557s
payload: 1GB
bandwidth: 65.2504 MBps
TRUNCATE TABLE
time: 8.06971s
payload: 1GB
bandwidth: 133 MBps
was not expected. num_rows per page fetch was
-------------------------------------------------
PERF TEST [16384 keys, 65536 block size]
SEQUENTIAL WRITE
num_keys: 16384
time: 17.576s
payload: 1 GB
bandwidth: 61.0914 MBps
SEQUENTIAL READ KEY/VALUES
key count: 16384
time: 8.47041s
payload: 1GB
bandwidth: 126.764 MBps
TRUNCATE TABLE
time: 6.04113s
payload: 1GB
bandwidth: 177 MBps
build-opt/util/cassandra_store_stress --db_size=4294967296
-------------------------------------------------
PERF TEST [65536 keys, 65536 block size]
SEQUENTIAL WRITE
num_keys: 65536
time: 85.7753s
payload: 4 GB
bandwidth: 50.0723 MBps
SEQUENTIAL READ KEY/VALUES
key count: 65536
time: 97.595s
payload: 4GB
bandwidth: 44.0081 MBps
TRUNCATE TABLE
time: 5.90673s
payload: 4GB
bandwidth: 727 MBps
build-opt/util/cassandra_store_stress --db_size=4294967296 --batch_size=32768
-------------------------------------------------
PERF TEST [131072 keys, 32768 block size]
SEQUENTIAL WRITE
num_keys: 131072
time: 117.035s
payload: 4 GB
bandwidth: 36.6982 MBps
SEQUENTIAL READ KEY/VALUES
key count: 131072
time: 280.868s
payload: 4GB
bandwidth: 15.2918 MBps
TRUNCATE TABLE
time: 5.6176s
payload: 4GB
bandwidth: 764 MBps
build-opt/util/cassandra_store_stress --db_size=10737418240
-------------------------------------------------
PERF TEST [163840 keys, 65536 block size]
SEQUENTIAL WRITE
num_keys: 163840
time: 231.645s
payload: 10 GB
bandwidth: 46.3529 MBps
SEQUENTIAL READ KEY/VALUES
key count: 163840
time: 432.403s
payload: 10GB
bandwidth: 24.832 MBps
TRUNCATE TABLE
time: 3.26219s
payload: 10GB
bandwidth: 3291 MBps
- These tests were done on a local dev workstation with one node cassandra cluster.
- Bulk read seems to perform worse than even sequestial write when batch size is large. That was not expected? num_rows per page fetch was 500.
- Truncate is independent of size of table. So indeed truncate is metadata change only.