With regard to a large number of records in a batch mutation there are some potential issues.
Each row becomes a task in the write thread pool on each replica. If a single client sends 1,000 rows in a mutation it will take time for the (default) 32 threads in the write pool to work through the mutations. While they are doing this other clients / requests will appear to be starved / stalled. There are also issues with the max message size in thrift and cql over thrift. IMHO as a rule of thumb dont go over a few hundred if you have a high number of concurrent writers. Cheers ----------------- Aaron Morton Freelance Cassandra Developer New Zealand @aaronmorton http://www.thelastpickle.com On 14/01/2013, at 12:56 AM, Radim Kolar <[email protected]> wrote: > do not use cassandra for implementing queueing system with high throughput. > It does not scale because of tombstone management. Use hornetQ, its amazingly > fast broker but it has quite slow persistence if you want to create queues > significantly larger then your memory and use selectors for searching for > specific messages in them. > > My point is for implementing queue message broker is what you want.
