Tnx all for clarification and your views. Queues and asynch are definitly a way to go. Anyway I'll take pull+aggregate aproach for now, it should work better for start. (if someone has the same "follows app" problem, there is a great research: http://research.yahoo.com/files/sigmod278-silberstein.pdf )
Lp, *Alan Ristić* *w*: www.microhint.com <-- obišči, tnx * f*: facebook.com/microhint <-- lajkaj, tnx* * *t*: twitter.com/microhint_com <-- follow, tnx *m*: 040 423 688 2013/1/14 Vitalii Tymchyshyn <[email protected]> > Well, for me it was better to use async operations then batches. So, you > are not bitten by latency, but can control everything per-operation. You > will need to support a kind of "window" thought. But this windows can be > quite low, like 10-20 ops. > > > 2013/1/14 Wei Zhu <[email protected]> > >> Another potential issue is when some failure happens to some of the >> mutations. Is atomic batches in 1.2 designed to resolve this? >> >> http://www.datastax.com/dev/blog/atomic-batches-in-cassandra-1-2 >> >> -Wei >> >> ----- Original Message ----- >> From: "aaron morton" <[email protected]> >> To: [email protected] >> Sent: Sunday, January 13, 2013 7:57:56 PM >> Subject: Re: How many BATCH inserts in to many? >> >> 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. >> >> >> > > > -- > Best regards, > Vitalii Tymchyshyn >
