2

I know that in Cassandra, there's no strong consistency unless you explicitly request it (and even then, there're no transactions).

However, I'm interested in the "order" of consistency. Take the following example:

In a database node, there are 3 nodes (A, B and C). Two insert queries are sent trough the same CQL-connection (or thrift for that matter, I don't think that's relevant to this question anyway). Both operate on different tables (this might be relevant).

INSERT INTO table_a (id) VALUES (0)
INSERT INTO table_b (id) VALUES (1)

Directly after the questions have been successfuly executed on the node that they're sent to, it goes down. The node may or may not have succeeded in propogating these two queries to B and C.

Now, I'd think that there is an order of consistency. Either both are successfully propogated and executed on B and C, or only the first query is, or both are. I'd think that, under no circumstances only the second query is propogated and executed, and not the first (because of the order of tcp packets, and the fact that obviously, all nodes share the same consistency strategy).

Am I right?

cutsoy
  • 10,127
  • 4
  • 40
  • 57

1 Answers1

4

You're right, at least on the node you connect to. What happens on the server is, for a consistency level ONE write:

  1. Receive insert to table_a
  2. Write into commitlog
  3. Acknowledge write to client
  4. Receive insert to table_b
  5. Write into commitlog
  6. Acknowledge write to client

The key is that there is a global commitlog. So you can't flush it for one table and not another. Also, because the writes are sequential, you know the write was made to the commitlog before returning.

The commitlog gets flushed periodically (by default), so could flush after 2 but before 5, in which case only the insert to table_a is kept in the event of a crash immediately after 4 or 5.

On other nodes, the ordering isn't guaranteed, because the write is done asynchronously and writes are multithreaded. But it's not possible to totally lose the first write and not the second if the original node doesn't fail permanently.

If you want stronger guarantees, you can use Cassandra's batching.

Cassandra can guarantee that neither or both of the writes succeed if you write them as a batch. For even old Cassandra versions, if updates within a batch have the same row key (partition key in CQL speak), even if they are in different column families (tables), they will get committed to the commitlog atomically.

New in 1.2 is a batchlog across multiple rows that offers the same guarantees - either all the batch gets applied or none.

Richard
  • 11,050
  • 2
  • 46
  • 33
  • Totally forgot about the fact that it's multithreaded. Are batches propogated to replicas as batches or is it again only guaranteed to be atomic on the first node (the one I connect to)? – cutsoy Aug 17 '13 at 08:50
  • 1
    A batch will contain rows for arbitrary nodes. Cassandra will guarantee that the batch is atomic by essentially pre-replicating it (http://www.datastax.com/dev/blog/atomic-batches-in-cassandra-1-2) but the order in which the writes in the batch are applied is undefined. – jbellis Aug 19 '13 at 22:58