From user-return-19475-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Wed Aug 3 12:11:42 2011 Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 36F997B0D for ; Wed, 3 Aug 2011 12:11:42 +0000 (UTC) Received: (qmail 43613 invoked by uid 500); 3 Aug 2011 12:11:39 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 43216 invoked by uid 500); 3 Aug 2011 12:11:32 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 43203 invoked by uid 99); 3 Aug 2011 12:11:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Aug 2011 12:11:31 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a78.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Aug 2011 12:11:24 +0000 Received: from homiemail-a78.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a78.g.dreamhost.com (Postfix) with ESMTP id 73B6115C065 for ; Wed, 3 Aug 2011 05:11:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; q=dns; s=thelastpickle.com; b=TCHEw9XYrl vWNTX4qZacY7MA0KePcQrxgLerqayuMkWLXCIAfN1arG730E+Ajq1VlDv2/JdiJP MDCKcBcBxIqr3NfDjl2FQmmAWFi3STdVzLpqKHXjdKQictbglb2NgImOpk2VQ8Pt DgKXpxqrH9wwv/VqkFrX6xGsvH20hWdlc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; s=thelastpickle.com; bh=+cORAa8/nGcOz4OL V7fhiO/a6g8=; b=1gwSU1lo4oIUiIE2VJqaqWWaORa7HQ/GNaf2gVTpJpakmIlT XLm84YNOU0HZvAZfuje9i4neTxBSS+hZfL3poYmZ9nNpBI9vCqBZ//uqRB9jh9FN BIYqYpI8t2pEDq/OnaGpd+3s5FhXLlOyEOScFhG/wT1+xYdzbjlLBGp1dEE= Received: from [192.168.0.101] (CPE-124-191-124-91.pmql1.win.bigpond.net.au [124.191.124.91]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a78.g.dreamhost.com (Postfix) with ESMTPSA id 8ED6E15C059 for ; Wed, 3 Aug 2011 05:11:01 -0700 (PDT) From: aaron morton Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_36EF1C3C-5964-4078-9AF7-DF4F0A3CB8BC" Subject: Re: cassandra consistency level Date: Wed, 3 Aug 2011 22:10:57 +1000 In-Reply-To: To: user@cassandra.apache.org References: Message-Id: <416E5566-0A7F-47AC-BC3D-A8D8E5B40AAF@thelastpickle.com> X-Mailer: Apple Mail (2.1244.3) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_36EF1C3C-5964-4078-9AF7-DF4F0A3CB8BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > In other words, if one of the nodes is down - the write (or read) will = fail. No. Cassandra will always try to get a write distributed to RF nodes. The = Consistency Level is how many replicas you want to be written before you = accept the request was a success. e.g. with RF 3 and QUORUM you are = saying wait until at least 2 replicas have completed. So you can have = one node down. If the write is not replicated during the request it may = eventually get there via the Read Repair, Hinted Handoff or Repair = processes.=20 If you always use QUORUM for read and write you will get consistent = behaviour, see http://wiki.apache.org/cassandra/ArchitectureOverview I = would recommend using QUORUM until you can find a good reason to use = something else (performance is not a good reason).=20 For you model, it sounds like you should handle each user action as a = separate column. This has to do with concurrency around the update, not = the consistency model. Have a look at the data modelling slides here = http://www.datastax.com/events/cassandrasf2011/presentations Hope that helps. =20 ----------------- Aaron Morton Freelance Cassandra Developer @aaronmorton http://www.thelastpickle.com On 3 Aug 2011, at 16:59, Eldad Yamin wrote: > So what you're saying is that no matter what consistency level I'm = using, the data will be written to all CF nodes right away, the = consistency level is just for making sure that all CF nodes are UP and = all data is written. > In other words, if one of the nodes is down - the write (or read) will = fail. >=20 > I'm asking that because I'm a bit worried with consistency, for = example: > Every action that my client is doing is stored in a CF.x in a specific = column by his user_id. > I'm doing that by de-serializing the data that already found in the = column, adding new data (the action), serializing and storing the data. > so I'm worrying that some of the user actions will "drop" due = low-consistency when there are lots of changes to a specific column in a = sort period of time. > I know that I can solve this situation in a different way by storing = each action in a new column etc... but this is just an example that = explain my question in a simple way. >=20 > Thanks! >=20 >=20 >=20 > On Wed, Aug 3, 2011 at 3:21 AM, aaron morton = wrote: > Not sure I understand your question exactly, but will take a shot=85 >=20 > Writes are sent to every UP node, the consistency level is how many = nodes we require to complete before we say the request completed = successfully. So we also make sure that CL nodes are UP before we start = the request. If you run CL ALL then Replication Factor nodes must be up = for each key you are writing. >=20 > With the exception of CL ONE reads are also sent to all UP replicas. >=20 > Hope that helps. >=20 > ----------------- > Aaron Morton > Freelance Cassandra Developer > @aaronmorton > http://www.thelastpickle.com >=20 > On 3 Aug 2011, at 09:32, Eldad Yamin wrote: >=20 > > Is consistency level "All" for write actually grenty that my data is = updated in all of my node? > > is it apply to read actions as-well? > > > > I've read it on the wiki, I just want to make sure. > > Thanks! >=20 >=20 --Apple-Mail=_36EF1C3C-5964-4078-9AF7-DF4F0A3CB8BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
In other words, = if one of the nodes is down - the write (or read) = will fail.
No.

Cassandra will = always try to get a write distributed to RF nodes. The Consistency Level = is how many replicas you want to be written before you accept the = request was a success. e.g. with RF 3 and QUORUM you are saying wait = until at least 2 replicas have completed. So you can have one node down. =  If the write is not replicated during the request it may = eventually get there via the Read Repair, Hinted Handoff or Repair = processes. 

If you always use QUORUM for read = and write you will get consistent behaviour, see http://wiki= .apache.org/cassandra/ArchitectureOverview I would recommend = using QUORUM until you can find a good reason to use something else = (performance is not a good reason). 

For = you model, it sounds like you should handle each user action as a = separate column. This has to do with concurrency around the update, not = the consistency model. Have a look at the data modelling slides = here http= ://www.datastax.com/events/cassandrasf2011/presentations

Hope that = helps.

 
http://www.thelastpickle.com

On 3 Aug 2011, at 16:59, Eldad Yamin wrote:

So what you're saying is that no matter = what consistency level I'm using, the data will = be written to all CF nodes right away, the consistency level = is just for making sure that all CF nodes are UP and all data = is written.
In other words, if one of the nodes is down - the write (or read) = will fail.

I'm asking = that because I'm a bit worried with consistency, for = example:
Every action that my client is doing is stored in a = CF.x in a specific column by his user_id.
I'm doing that by de-serializing the data that already found in the = column, adding new data (the action), serializing and storing the = data.
so I'm worrying that some of the user actions = will "drop" due low-consistency when there are lots of changes to = a specific column in a sort period of time.
I know that I can solve this situation in a different way = by storing each action in a new column etc... but this is just an = example that explain my question in a simple = way.

Thanks!



On = Wed, Aug 3, 2011 at 3:21 AM, aaron morton <aaron@thelastpickle.com> wrote:
Not sure I understand = your question exactly, but will take a shot=85

Writes are sent to every UP node, the consistency level is how many = nodes we require to complete before we say the request completed = successfully. So we also make sure that CL nodes are UP before we start = the request. If you run CL ALL then Replication Factor nodes must be up = for each key you are writing.

With the exception of CL ONE reads are also sent to all UP replicas.

Hope that helps.

-----------------
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com

On 3 Aug 2011, at 09:32, Eldad Yamin wrote:

> Is consistency level "All" for write actually grenty that my data = is updated in all of my node?
> is it apply to read actions as-well?
>
> I've read it on the wiki, I just want to make sure.
> Thanks!



= --Apple-Mail=_36EF1C3C-5964-4078-9AF7-DF4F0A3CB8BC--