There are two concerns that give me pause. The first is that 1072 is tackling a use case that Cassandra already handles well: high volume of writes to a counter, with low volume reads. (This can be done by inserting uuids into a counter row, and aggregating them either in the background or at read time or with some combination of these. The counter rows can be sharded if necessary.)
The second is that the approach in 1072 resembles an entirely separate system that happens to use part of Cassandra infrastructure -- the thrift API, the MessagingService, the sstable format -- but isn't really part of it. ConsistencyLevel is not respected, and special cases abound to weld things in that don't fit, e.g. the AES/Streaming business. On Thu, Aug 12, 2010 at 1:28 AM, Robin Bowes <robin-li...@robinbowes.com> wrote: > Hi Jonathan, > > I'm contacting you in your capacity as project lead for the cassandra > project. I am wondering how close ticket #1072 is to implementation [1] > > We are about to do a proof of concept with cassandra to replace around > 20 MySQL partitions (1 partition = 4 machines: master/slave in DC A, > master/slave in DC B). > > We're essentially just counting web hits - around 10k/second at peak > times - so increment counters is pretty much essential functionality for us. > > How close is the patch in #1072 to being acceptable? What is blocking it? > > Thanks, > > R. > > [1] https://issues.apache.org/jira/browse/CASSANDRA-1072 > > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
