Counters differ significantly between 2.0 and 2.1 ( https://issues.apache.org/jira/browse/CASSANDRA-6405 among others). But in both scenarios, you will pay more for counter reconciles and compactions vs. regular updates.
The final counter performance fix will come with CASSANDRA-6506. For details read Aleksey's post - http://www.datastax.com/dev/blog/whats-new-in-cassandra-2-1-a-better-implementation-of-counters All the best, [image: datastax_logo.png] <http://www.datastax.com/> Sebastián Estévez Solutions Architect | 954 905 8615 | sebastian.este...@datastax.com [image: linkedin.png] <https://www.linkedin.com/company/datastax> [image: facebook.png] <https://www.facebook.com/datastax> [image: twitter.png] <https://twitter.com/datastax> [image: g+.png] <https://plus.google.com/+Datastax/about> <http://feeds.feedburner.com/datastax> <http://cassandrasummit-datastax.com/> DataStax is the fastest, most scalable distributed database technology, delivering Apache Cassandra to the world’s most innovative enterprises. Datastax is built to be agile, always-on, and predictably scalable to any size. With more than 500 customers in 45 countries, DataStax is the database technology and transactional backbone of choice for the worlds most innovative companies such as Netflix, Adobe, Intuit, and eBay. On Thu, May 21, 2015 at 5:48 AM, Jens Rantil <jens.ran...@tink.se> wrote: > Artur, > > That's not entirely true. Writes to Cassandra are first written to a > memtable (in-memory table) which is periodically flushed to disk. If > multiple writes are coming in before the flush, then only a single record > will be written to the disk/sstable. If your have writes that aren't coming > within the same flush, they will get removed when you are compacting just > like you say. > > Unfortunately I can't answer this regarding Counters as I haven't worked > with them. > > Hope this helped at least. > > Cheers, > Jens > > On Fri, May 15, 2015 at 11:16 AM, Artur Siekielski <a...@vhex.net> wrote: > >> I've seen some discussions about the topic on the list recently, but I >> would like to get more clear answers. >> >> Given the table: >> >> CREATE TABLE t1 ( >> f1 text, >> f2 text, >> f3 text, >> PRIMARY KEY(f1, f2) >> ); >> >> and assuming I will execute UPDATE of f3 multiple times (say, 1000) for >> the same key values k1, k2 and different values of 'newval': >> >> UPDATE t1 SET f3=newval WHERE f1=k1 AND f2=k2; >> >> How will the performance of selecting the current 'f3' value be affected?: >> >> SELECT f3 FROM t1 WHERE f1=k2 AND f2=k2; >> >> It looks like all the previous values are preserved until compaction, but >> does executing the SELECT reads all the values (O(n), n - number of >> updates) or only the current one (O(1)) ? >> >> >> How the situation looks for Counter types? >> > > > > -- > Jens Rantil > Backend engineer > Tink AB > > Email: jens.ran...@tink.se > Phone: +46 708 84 18 32 > Web: www.tink.se > > Facebook <https://www.facebook.com/#!/tink.se> Linkedin > <http://www.linkedin.com/company/2735919?trk=vsrp_companies_res_photo&trkInfo=VSRPsearchId%3A1057023381369207406670%2CVSRPtargetId%3A2735919%2CVSRPcmpt%3Aprimary> > Twitter <https://twitter.com/tink> >
