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 <[email protected]> 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: [email protected] 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>
