RE: Question about CL.ZERO
the goal i am reaching for with ZERO is to return control to the "user" ASAP, with super fast response times. the load isn't high at all, but persisting does take time even under light load. we are not actually using ZERO at the moment but were considering it for "fire and forget" type of events. maybe the risk of overloading a server is not worth it. From: Benjamin Black [...@b3k.us] Sent: Monday, July 12, 2010 3:50 PM To: user@cassandra.apache.org Subject: Re: Question about CL.ZERO CL.ONE represents the fastest you can sustain. CL.ZERO represents writing to memory on the coordinator, regardless of what the nodes can sustain for durable writes. That is a bad situation, regardless of your durability goals. So, there is no good reason. What you are describing is a non-existent CL in which the writes are dispatched to the replicas and success immediately returned to the client. Wouldn't be hard to add. On Mon, Jul 12, 2010 at 10:51 AM, B. Todd Burruss wrote: > why is there no good reason? if i would like to record informational > events, possibly for debugging or something, i don't care if they actually > get saved and i want the client's request to be as fast as possibly. this > sounds like a good reason. > > are you saying that CL.ONE is equally performant? or possibly better by > your comment that ZERO can be a serious resource hog? > > thx > > On 07/11/2010 11:09 AM, Benjamin Black wrote: >> >> And, to be clear, there is no good reason to use CL.ZERO and it can be >> a serious resource hog on the coordinator. >> >> On Sun, Jul 11, 2010 at 9:21 AM, ChingShen >> wrote: >> >>> >>> Hi all, >>> >>> Does it mean that the coordinator node always return success to the >>> client >>> at CL.ZERO? But if the coordinator node sends a request to a given node >>> B(RF=1), then B is down, what happened? The coordinator node will write >>> the >>> hint locally? >>> >>> Thanks. >>> >>> Shen >>> >>> >
Re: Question about CL.ZERO
CL.ONE represents the fastest you can sustain. CL.ZERO represents writing to memory on the coordinator, regardless of what the nodes can sustain for durable writes. That is a bad situation, regardless of your durability goals. So, there is no good reason. What you are describing is a non-existent CL in which the writes are dispatched to the replicas and success immediately returned to the client. Wouldn't be hard to add. On Mon, Jul 12, 2010 at 10:51 AM, B. Todd Burruss wrote: > why is there no good reason? if i would like to record informational > events, possibly for debugging or something, i don't care if they actually > get saved and i want the client's request to be as fast as possibly. this > sounds like a good reason. > > are you saying that CL.ONE is equally performant? or possibly better by > your comment that ZERO can be a serious resource hog? > > thx > > On 07/11/2010 11:09 AM, Benjamin Black wrote: >> >> And, to be clear, there is no good reason to use CL.ZERO and it can be >> a serious resource hog on the coordinator. >> >> On Sun, Jul 11, 2010 at 9:21 AM, ChingShen >> wrote: >> >>> >>> Hi all, >>> >>> Does it mean that the coordinator node always return success to the >>> client >>> at CL.ZERO? But if the coordinator node sends a request to a given node >>> B(RF=1), then B is down, what happened? The coordinator node will write >>> the >>> hint locally? >>> >>> Thanks. >>> >>> Shen >>> >>> >
Re: Question about CL.ZERO
My understanding is that the coordinator will acknowledge the writes faster then they can actually be written. Eventually it will run out of buffer space. see http://wiki.apache.org/cassandra/FAQ#slows_down_after_lotso_insertsUsing CL.ONE makes it harder for the clients to flood the cluster with more writes than it can perform. As usual add more nodes to add more write throughput. AaronOn 13 Jul, 2010,at 05:51 AM, "B. Todd Burruss" wrote:why is there no good reason? if i would like to record informational events, possibly for debugging or something, i don't care if they actually get saved and i want the client's request to be as fast as possibly. this sounds like a good reason. are you saying that CL.ONE is equally performant? or possibly better by your comment that ZERO can be a serious resource hog? thx On 07/11/2010 11:09 AM, Benjamin Black wrote: > And, to be clear, there is no good reason to use CL.ZERO and it can be > a serious resource hog on the coordinator. > > On Sun, Jul 11, 2010 at 9:21 AM, ChingShen wrote: > >> Hi all, >> >>Does it mean that the coordinator node always return success to the client >> at CL.ZERO? But if the coordinator node sends a request to a given node >> B(RF=1), then B is down, what happened? The coordinator node will write the >> hint locally? >> >> Thanks. >> >> Shen >> >>
Re: Question about CL.ZERO
why is there no good reason? if i would like to record informational events, possibly for debugging or something, i don't care if they actually get saved and i want the client's request to be as fast as possibly. this sounds like a good reason. are you saying that CL.ONE is equally performant? or possibly better by your comment that ZERO can be a serious resource hog? thx On 07/11/2010 11:09 AM, Benjamin Black wrote: And, to be clear, there is no good reason to use CL.ZERO and it can be a serious resource hog on the coordinator. On Sun, Jul 11, 2010 at 9:21 AM, ChingShen wrote: Hi all, Does it mean that the coordinator node always return success to the client at CL.ZERO? But if the coordinator node sends a request to a given node B(RF=1), then B is down, what happened? The coordinator node will write the hint locally? Thanks. Shen
Re: Question about CL.ZERO
And, to be clear, there is no good reason to use CL.ZERO and it can be a serious resource hog on the coordinator. On Sun, Jul 11, 2010 at 9:21 AM, ChingShen wrote: > Hi all, > > Does it mean that the coordinator node always return success to the client > at CL.ZERO? But if the coordinator node sends a request to a given node > B(RF=1), then B is down, what happened? The coordinator node will write the > hint locally? > > Thanks. > > Shen >
Re: Question about CL.ZERO
On Sun, Jul 11, 2010 at 11:21 AM, ChingShen wrote: > Hi all, > > Does it mean that the coordinator node always return success to the client > at CL.ZERO? Yes. > But if the coordinator node sends a request to a given node > B(RF=1), then B is down, what happened? The coordinator node will write the > hint locally? Sort of: if the coordinator knows when it begins processing the request that B is down, it will write a hint. But if it has not yet detected that B is down, then it will attempt a write. If the write times out then no further attempts are made. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Question about CL.ZERO
Hi all, Does it mean that the coordinator node always return success to the client at CL.ZERO? But if the coordinator node sends a request to a given node B(RF=1), then B is down, what happened? The coordinator node will write the hint locally? Thanks. Shen
