You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by ChingShen <ch...@gmail.com> on 2010/07/11 18:21:36 UTC
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
RE: Question about CL.ZERO
Posted by Todd Burruss <bb...@real.com>.
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 [b@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 <bb...@real.com> 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<ch...@gmail.com>
>> 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
Posted by Benjamin Black <b...@b3k.us>.
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 <bb...@real.com> 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<ch...@gmail.com>
>> 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
Posted by Aaron Morton <aa...@thelastpickle.com>.
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_inserts
Using 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.
Aaron
On 13 Jul, 2010,at 05:51 AM, "B. Todd Burruss" <bb...@real.com> 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<ch...@gmail.com> 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
Posted by "B. Todd Burruss" <bb...@real.com>.
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<ch...@gmail.com> 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
Posted by Benjamin Black <b...@b3k.us>.
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 <ch...@gmail.com> 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
Posted by Jonathan Ellis <jb...@gmail.com>.
On Sun, Jul 11, 2010 at 11:21 AM, ChingShen <ch...@gmail.com> 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