You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Michal Augustýn <au...@gmail.com> on 2011/02/12 10:12:55 UTC
per-connection "read-after-my-write" consistency
Hi,
I'm running 2 nodes with RF=2 (not optimal, I know), Cassandra 0.7.1.
During one connection, I write (CL.ONE) a row and subsequently read (CL.ONE)
the same row (via Thrift).
I supposed that if I write row to one node then I can immediately read this
row from this node.
It seems to be true for most cases, but circa 1 of 1000 attempts doesn't
work as expected - I get no row :(
Where is the problem please? Should I use another CL for read and/or write?
I would like just to achieve "per connection read-after-my-write
consistency".
Thank you very much!
Augi
RE: per-connection "read-after-my-write" consistency
Posted by Dan Hendry <da...@gmail.com>.
> So the suggestion is to use at least 3 nodes with RF=3 and CL.QUORUM for
both write and reads where high consistency is required, right?
Yes, this is the typical way to use Cassandra when both consistency and
availability are required.
Dan
From: Michal Augustýn [mailto:augustyn.michal@gmail.com]
Sent: February-12-11 17:37
To: user@cassandra.apache.org
Subject: Re: per-connection "read-after-my-write" consistency
Hi,
I'm using .NET and I wrote my own client library (over Thrift) so I'm
absolutely sure that both operations are performed using the same
connection.
I can handle the current issue in application but I'm sure that I will not
be able to handle some future situation in application.
So the suggestion is to use at least 3 nodes with RF=3 and CL.QUORUM for
both write and reads where high consistency is required, right?
Thanks!
2011/2/12 Dan Hendry <da...@gmail.com>
Are you using a higher level client (hector/pelops/pycassa/etc) or the
actual thrift API? Higher level clients often pool connections and two
subsequent operations (read then write) may be performed with connections to
different nodes.
If you are sure you are using the same connection (the actual thrift api),
there is a possible race condition. To the best of my understanding, here is
how a write happens at cl ONE in your case :
- You make a request to node A which initiates a write to node A
and B
- The server reports successful when the write to node A OR B is
complete (can somebody else confirm?)
Typically the write to A will complete quicker since that is the node you
are connected to and there is additional network overhead initiating the
write on node B. I suppose a 1:1000 chance of B completing first is
possible, particularly if all nodes and the client are on the same network
(or same machine) with very low latencies.
Cassandra allows you to explicitly specify the trade-off between consistency
and availability. When you read and write at ONE with RF=2, consistency is
not guaranteed but high availability is (you can lose a node and continue to
operate). If you require strong consistency you will either have to read or
write at consistency level ALL. My suggestion is to either design your
application to tolerate inconsistency (if possible) or move to RF=3 and
quorum read and quorum writes.
Dan
From: Michal Augustýn [mailto:augustyn.michal@gmail.com]
Sent: February-12-11 4:13
To: user@cassandra.apache.org
Subject: per-connection "read-after-my-write" consistency
Hi,
I'm running 2 nodes with RF=2 (not optimal, I know), Cassandra 0.7.1.
During one connection, I write (CL.ONE) a row and subsequently read (CL.ONE)
the same row (via Thrift).
I supposed that if I write row to one node then I can immediately read this
row from this node.
It seems to be true for most cases, but circa 1 of 1000 attempts doesn't
work as expected - I get no row :(
Where is the problem please? Should I use another CL for read and/or write?
I would like just to achieve "per connection read-after-my-write
consistency".
Thank you very much!
Augi
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.872 / Virus Database: 271.1.1/3439 - Release Date: 02/12/11
02:34:00
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.872 / Virus Database: 271.1.1/3439 - Release Date: 02/12/11
02:34:00
Re: per-connection "read-after-my-write" consistency
Posted by Michal Augustýn <au...@gmail.com>.
Hi,
I'm using .NET and I wrote my own client library (over Thrift) so I'm
absolutely sure that both operations are performed using the same
connection.
I can handle the current issue in application but I'm sure that I will not
be able to handle some future situation in application.
So the suggestion is to use at least 3 nodes with RF=3 and CL.QUORUM for
both write and reads where high consistency is required, right?
Thanks!
2011/2/12 Dan Hendry <da...@gmail.com>
> Are you using a higher level client (hector/pelops/pycassa/etc) or the
> actual thrift API? Higher level clients often pool connections and two
> subsequent operations (read then write) may be performed with connections to
> different nodes.
>
>
>
> If you are sure you are using the same connection (the actual thrift api),
> there is a possible race condition. To the best of my understanding, here is
> how a write happens at cl ONE in your case :
>
> - You make a request to node A which initiates a write to node A
> and B
>
> - The server reports successful when the write to node A OR B is
> complete (can somebody else confirm?)
>
>
>
> Typically the write to A will complete quicker since that is the node you
> are connected to and there is additional network overhead initiating the
> write on node B. I suppose a 1:1000 chance of B completing first is
> possible, particularly if all nodes and the client are on the same network
> (or same machine) with very low latencies.
>
>
>
> Cassandra allows you to explicitly specify the trade-off between
> consistency and availability. When you read and write at ONE with RF=2,
> consistency is not guaranteed but high availability is (you can lose a node
> and continue to operate). If you require strong consistency you will either
> have to read or write at consistency level ALL. My suggestion is to either
> design your application to tolerate inconsistency (if possible) or move to
> RF=3 and quorum read and quorum writes.
>
>
>
> Dan
>
>
>
> *From:* Michal Augustýn [mailto:augustyn.michal@gmail.com]
> *Sent:* February-12-11 4:13
> *To:* user@cassandra.apache.org
> *Subject:* per-connection "read-after-my-write" consistency
>
>
>
> Hi,
>
>
>
> I'm running 2 nodes with RF=2 (not optimal, I know), Cassandra 0.7.1.
>
>
>
> During one connection, I write (CL.ONE) a row and subsequently read
> (CL.ONE) the same row (via Thrift).
>
> I supposed that if I write row to one node then I can immediately read this
> row from this node.
>
> It seems to be true for most cases, but circa 1 of 1000 attempts doesn't
> work as expected - I get no row :(
>
>
>
> Where is the problem please? Should I use another CL for read and/or write?
> I would like just to achieve "per connection read-after-my-write
> consistency".
>
>
>
> Thank you very much!
>
>
>
> Augi
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.872 / Virus Database: 271.1.1/3439 - Release Date: 02/12/11
> 02:34:00
>
RE: per-connection "read-after-my-write" consistency
Posted by Dan Hendry <da...@gmail.com>.
Are you using a higher level client (hector/pelops/pycassa/etc) or the
actual thrift API? Higher level clients often pool connections and two
subsequent operations (read then write) may be performed with connections to
different nodes.
If you are sure you are using the same connection (the actual thrift api),
there is a possible race condition. To the best of my understanding, here is
how a write happens at cl ONE in your case :
- You make a request to node A which initiates a write to node A
and B
- The server reports successful when the write to node A OR B is
complete (can somebody else confirm?)
Typically the write to A will complete quicker since that is the node you
are connected to and there is additional network overhead initiating the
write on node B. I suppose a 1:1000 chance of B completing first is
possible, particularly if all nodes and the client are on the same network
(or same machine) with very low latencies.
Cassandra allows you to explicitly specify the trade-off between consistency
and availability. When you read and write at ONE with RF=2, consistency is
not guaranteed but high availability is (you can lose a node and continue to
operate). If you require strong consistency you will either have to read or
write at consistency level ALL. My suggestion is to either design your
application to tolerate inconsistency (if possible) or move to RF=3 and
quorum read and quorum writes.
Dan
From: Michal Augustýn [mailto:augustyn.michal@gmail.com]
Sent: February-12-11 4:13
To: user@cassandra.apache.org
Subject: per-connection "read-after-my-write" consistency
Hi,
I'm running 2 nodes with RF=2 (not optimal, I know), Cassandra 0.7.1.
During one connection, I write (CL.ONE) a row and subsequently read (CL.ONE)
the same row (via Thrift).
I supposed that if I write row to one node then I can immediately read this
row from this node.
It seems to be true for most cases, but circa 1 of 1000 attempts doesn't
work as expected - I get no row :(
Where is the problem please? Should I use another CL for read and/or write?
I would like just to achieve "per connection read-after-my-write
consistency".
Thank you very much!
Augi
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.872 / Virus Database: 271.1.1/3439 - Release Date: 02/12/11
02:34:00