eventual consistency and what that means in real world terms

[snacktime <sn...@gmail.com>]

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

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

[snacktime <sn...@gmail.com>]

On Fri, Jul 3, 2009 at 7:14 PM, Evan Weaver <ew...@gmail.com> 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.

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

[Evan Weaver <ew...@gmail.com>]

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<sn...@gmail.com> 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