incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: cassandra increment counters, Jira #1072
Date Fri, 13 Aug 2010 03:54:35 GMT
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-lists@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

Mime
View raw message