incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evan Weaver <>
Subject Re: eventual consistency and what that means in real world terms
Date Sat, 04 Jul 2009 02:14:26 GMT
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.


On Fri, Jul 3, 2009 at 6:31 PM, snacktime<> 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

View raw message