cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1072) Increment counters
Date Fri, 20 Aug 2010 10:15:25 GMT


Jonathan Ellis commented on CASSANDRA-1072:

I actually think the main problem with the 1072 appraoch is on the write side, not the read.
 Writes are fragile.  Here is what I mean by that:

Because 1072 "shards" the increments across multiple machines, it can tolerate _temporary_
failures.  This is good.  But because the shards are no longer replicas in the normal Cassandra
sense -- each is responsible for a different set of increments, rather than all maintaining
the same data -- there is no way to create a write CL greater than ONE, and thus, no defense
against _permanent_ failures of single machines.  You can try to band-aid the problem with
Sylvain's repair-on-write, but only reduces the failure window, it does not eliminate it.

Another source of fragility is that operations here are not idempotent from the client's perspective.
 If a client issues an increment and it comes back TimedOut (or a socket exception to the
coordinator), it has no safe way to retry; if the operation did succeed, and the client issues
another delete, we have added new data erroneously; if the operation did not succeed, and
we do not retry, we have lost data.  So here is a case where even temporary node failures
can cause data corruption.  (I say corruption, because I mean to distinguish it from the sort
of inconsistency that RR and AES can repair.  Once introduced into the system, this corruption
is not distinguishable from real increments and thus un-repairable.)

> Increment counters
> ------------------
>                 Key: CASSANDRA-1072
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Johan Oskarsson
>            Assignee: Kelvin Kakugawa
>         Attachments: CASSANDRA-1072-2.patch, CASSANDRA-1072-2.patch, CASSANDRA-1072.patch,
> Break out the increment counters out of CASSANDRA-580. Classes are shared between the
two features but without the plain version vector code the changeset becomes smaller and more

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message