4 ms·
Cassandra counters once were implemented as a blazing-fast vector-clock patch [1,2] that did not involve read-before-write on update. The biggest (IMO) downside
by astral303 13y ago
Cassandra counters once were implemented as a blazing-fast vector-clock patch [1,2] that did not involve read-before-write on update. The biggest (IMO) downside is that it did not support decrements. So Cassandra tech leadership decided [2] to implement counters as "read, increment, write." However, that came with two major downsides: 1) counter updates were now no longer replayable--so if you experience an update timeout on the Cassandra side under heavy load or due to a lengthy compaction or some network fluke, you just can't replay it. You need to hope that it has made it over. Counters run on hope. But you can decrement them now. 2) read-before-write can severely limit performance in the case of a large number of counter writes (as the workload becomes much more read-intensive, unlike regular blazing-fast Cassandra writes).
1 - https://issues.apache.org/jira/browse/CASSANDRA-580 https://issues.apache.org/jira/browse/CASSANDRA-580
2 - https://issues.apache.org/jira/browse/CASSANDRA-1072 https://issues.apache.org/jira/browse/CASSANDRA-1072
However, in many many a use case for counters, you just don't need to decrement. And if you need to decrement, you can often get away with two counters, that you subtract from each other. So that's a shame, as restricting the use case for counters to be monotonically increasing would've been just the right trade-off for many users.
- jbellis 13y agoI think you've misread the 580 patch. By definition, you need to read the existing vector clock value before you can issue an update against it. /Member of the presumedly incompetent Cassandra tech leadership
- astral303 13y agoBased on the algorithm described in the link here: http://www.slideshare.net/kakugawa/distributed-counters-in-cassandra-cassandra-summit-2010 http://www.slideshare.net/kakugawa/distributed-counters-in-c... -- the insert path does not perform any reads, unless the column is already in the memtable (so no disk read). Am I missing something?
- jbellis 13y agoThat is describing the 1072 approach aka the one in Cassandra today. Incrementing without read-before-write was one of the reasons Twitter liked it. Unfortunately, while you can increment on a single node without read-before-write, you need to merge it with the existing value before you can replicate to the others. Read-before-replicate, if you will. Theres a more recent, quite long discussion over https://issues.apache.org/jira/browse/CASSANDRA-4775 https://issues.apache.org/jira/browse/CASSANDRA-4775 that boils down to, "this is actually the best we can do."
- ddorian43 13y agoHypertable has crazy fast increments-decrements(without reads). If the column is in memory it is updated on the spot. Else multiple values are inserted and merged on read or compaction. But it is a little different from cassandra, more similar to hbase.