eventual consistency and what that means in real world terms

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

eventual consistency and what that means in real world terms

snacktime
I'm evaluating a number of options to an rdbms for some of our facebook games.  A small, yet important number of queries require transactions.  For example we have auctions, and buying/purchasing of items with limited quantities.  

Are there knobs you can tweak to enforce consistency on a per query basis?  For example, I want to do a write that should not be visible until it's been written to all nodes in the cluster, is that possible?  What kind of general time frames are we talking about to write data to 3 nodes?

So basically what we want is high availability for 99.99% of queries, but high consistency for the remainder, across the same data.  Is this currently possible?

Chris
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: eventual consistency and what that means in real world terms

Evan Weaver
You can (once the API is fixed) make a client request the data from
every replica on read.  Which ever replica has the most recent value
will be the value that's returned. That makes sure that reads and
writes are consistently serialized from the server's perspective, at
some performance cost.

Weak reads request from one node. Strong reads let you tune the number
of nodes to check from 1 up to the replica count.

Cassandra, though, is not transactional. You need some kind of lock
server to guarantee that there aren't read/modify/write races from the
client's perspective. Zookeeper would probably work.

Evan

On Fri, Jul 3, 2009 at 6:31 PM, snacktime<[hidden email]> wrote:

> I'm evaluating a number of options to an rdbms for some of our facebook
> games.  A small, yet important number of queries require transactions.  For
> example we have auctions, and buying/purchasing of items with limited
> quantities.
> Are there knobs you can tweak to enforce consistency on a per query basis?
>  For example, I want to do a write that should not be visible until it's
> been written to all nodes in the cluster, is that possible?
>  What kind of general time frames are we talking about to write data to 3 nodes?
> So basically what we want is high availability for 99.99% of queries, but
> high consistency for the remainder, across the same data.  Is this currently
> possible?
> Chris



--
Evan Weaver
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: eventual consistency and what that means in real world terms

snacktime


On Fri, Jul 3, 2009 at 7:14 PM, Evan Weaver <[hidden email]> wrote:
You can (once the API is fixed) make a client request the data from
every replica on read.  Which ever replica has the most recent value
will be the value that's returned. That makes sure that reads and
writes are consistently serialized from the server's perspective, at
some performance cost.

Weak reads request from one node. Strong reads let you tune the number
of nodes to check from 1 up to the replica count.

Cassandra, though, is not transactional. You need some kind of lock
server to guarantee that there aren't read/modify/write races from the
client's perspective. Zookeeper would probably work.

Thanks Evan, that makes sense. 


 
Loading...