cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Horman <>
Subject Cold boot performance problems
Date Fri, 08 Oct 2010 17:36:41 GMT
We are experiencing very slow performance on Amazon EC2 after a cold boot.
10-20 tps. After the cache is primed things are much better, but it would be
nice if users who aren't in cache didn't experience such slow performance.

Before dumping a bunch of config I just had some general questions.

   - We are using uuid keys, 40m of them and the random partitioner. Typical
   access pattern is reading 200-300 keys in a single web request. Are uuid
   keys going to be painful b/c they are so random. Should we be using less
   random keys, maybe with a shard prefix (01-80), and make sure that our
   tokens group user data together on the cluster (via the order preserving
   - Would the order preserving partitioner be a better option in the sense
   that it would group a single users data to a single set of machines (if we
   added a prefix to the uuid)?
   - Is there any benefit to doing sharding of our own via Keyspaces. 01-80
   keyspaces to split up the data files. (we already have 80 mysql shards we
   are migrating from, so doing this wouldn't be terrible implementation wise)
   - Should a goal be to get the data/index files as small as possible. Is
   there a size at which they become problematic? (Amazon EC2/EBS fyi)
      - Via more servers
      - Via more cassandra instances on the same server
      - Via manual sharding by keyspace
      - Via manual sharding by columnfamily


-jason horman

View raw message