On Thu, Aug 12, 2010 at 8:54 PM, Jonathan Ellis <jbel...@gmail.com> wrote: > 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.) >
This is simply not an acceptable alternative and just can't be called handling it "well". It is equivalent to "make the users do it", which is the case for almost anything. The reasons #1072 is so valuable: 1) Does not require _any_ user action. 2) Does not change the EC-centric model of Cassandra. 3) Meets the requirements of many, major users who would otherwise have to use another storage system. > 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. > Then let's find ways to make it as elegant as it can be. Ultimately, this functionality needs to be in Cassandra or users will simply migrate someplace else for this extremely common use case. b
