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 <bburruss@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<chingshenchen@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
>>>
>>>
>
|