Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8B8431857F for ; Thu, 21 May 2015 20:02:23 +0000 (UTC) Received: (qmail 46743 invoked by uid 500); 21 May 2015 20:02:19 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 46616 invoked by uid 500); 21 May 2015 20:02:19 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 46498 invoked by uid 99); 21 May 2015 20:02:19 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 May 2015 20:02:19 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 26A3DC11B9 for ; Thu, 21 May 2015 20:02:19 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.121 X-Spam-Level: *** X-Spam-Status: No, score=3.121 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, KAM_HUGEIMGSRC=0.2, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=datastax.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id U-16XhH4VGw7 for ; Thu, 21 May 2015 20:02:04 +0000 (UTC) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 726B5204F2 for ; Thu, 21 May 2015 20:02:04 +0000 (UTC) Received: by qkgx75 with SMTP id x75so64916611qkg.1 for ; Thu, 21 May 2015 13:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datastax.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=zbfmfYAah/Xywk3/c1pw0IlOex+NIM8TzmZM9Qvy+l0=; b=RJnqGlFYiN41JPac5FcO59L3Xz3eWnaqDS/h7MrVUUd87ttxt8KqPTrjyWLziCjdiU mTq5/ia2EJZA+fCIQXEcyMcCpeOyKrpZWvWOUcV98fjE5K9avzn6B+hxbhtFyWU0XVYR I2ZdZ8NZiPij2Zfinb72E1E4/W57cJi1ETK+4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=zbfmfYAah/Xywk3/c1pw0IlOex+NIM8TzmZM9Qvy+l0=; b=iM/ts5dhGe8gnQjaeF8Ii5uyItu7D+3n8XRoU92w5bFM7NW0nufLv6CvzxySHraP3O PYfdRHChgcSDddGdFxQA84K3ud47WmcCF1X7+9pUuooiUTvo/uxkgyl/dT2ac2C9fIBp u+s0n+jZN5LaZi72m6v8m52QqogidzgaL0QatRZm7zMeQUP1LZH0sQJPNWwc0pLU7PPX je3hO2gQOxvCoz/mAzY13lVd/XS/XbYbTFSFbcyS/b+3679EZ7vMv6C+loMXQ/p7LMZv dqOvo5WzFPsD7BJhAydM1zXeivOS/b9xw5N47qcqXnE3NRaZS7uerqrPv8MVXIC1w38a fXQw== X-Gm-Message-State: ALoCoQkdh4whEbqt7pyEAiTCrnkCVbfTDHlDxy6EHNoJwS/WTYg673k0mxPbVrHKHNHyuSXwLPlM X-Received: by 10.55.52.18 with SMTP id b18mr10392776qka.85.1432238478545; Thu, 21 May 2015 13:01:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.250.134 with HTTP; Thu, 21 May 2015 13:00:58 -0700 (PDT) In-Reply-To: References: <5555B954.3070401@vhex.net> From: Sebastian Estevez Date: Thu, 21 May 2015 16:00:58 -0400 Message-ID: Subject: Re: Performance penalty of multiple UPDATEs of non-pk columns To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a11479576bf935b05169d0115 --001a11479576bf935b05169d0115 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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-implem= entation-of-counters All the best, [image: datastax_logo.png] Sebasti=C3=A1n Est=C3=A9vez Solutions Architect | 954 905 8615 | sebastian.estevez@datastax.com [image: linkedin.png] [image: facebook.png] [image: twitter.png] [image: g+.png] DataStax is the fastest, most scalable distributed database technology, delivering Apache Cassandra to the world=E2=80=99s most innovative enterpri= ses. 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 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 comi= ng > 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 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=3Dnewval WHERE f1=3Dk1 AND f2=3Dk2; >> >> How will the performance of selecting the current 'f3' value be affected= ?: >> >> SELECT f3 FROM t1 WHERE f1=3Dk2 AND f2=3Dk2; >> >> It looks like all the previous values are preserved until compaction, bu= t >> 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.rantil@tink.se > Phone: +46 708 84 18 32 > Web: www.tink.se > > Facebook Linkedin > > Twitter > --001a11479576bf935b05169d0115 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Counters differ significantly between 2.0 and 2.1 (https://issues.ap= ache.org/jira/browse/CASSANDRA-6405 among others). But in both scenario= s, you will pay more for counter reconciles and compactions vs. regular upd= ates.

The final counter performance fix will come with C= ASSANDRA-6506.


All the best,


3D"datastax_logo.png"

Sebasti=C3=A1n Est=C3=A9vez

Solutions = Architect | 954 905 8615 | sebastian.estevez@datastax.com

3D"linkedin.png" 3D"facebook.png" 3D"twitter.png" 3D"g+.png"



DataStax is the fastest, most scalable distributed databa= se technology, delivering Apache Cassandra to the world=E2=80=99s most inno= vative enterprises. Datastax is built to be agile, always-on, and predictab= ly 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 Netfli= x, Adobe, Intuit, and eBay.

On Thu, May 21, 2015 at 5:48 AM, Jens Rantil= <jens.rantil@tink.se> wrote:
Artur,

That's not entirely tr= ue. Writes to Cassandra are first written to a memtable (in-memory table) w= hich is periodically flushed to disk. If multiple writes are coming in befo= re 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 wi= ll 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 <artc@vhex.net> wrote= :
I've seen some discussions about th= e topic on the list recently, but I would like to get more clear answers.
Given the table:

CREATE TABLE t1 (
=C2=A0 =C2=A0 =C2=A0 =C2=A0 f1 text,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 f2 text,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 f3 text,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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=3Dnewval WHERE f1=3Dk1 AND f2=3Dk2;

How will the performance of selecting the current 'f3' value be aff= ected?:

SELECT f3 FROM t1 WHERE f1=3Dk2 AND f2=3Dk2;

It looks like all the previous values are preserved until compaction, but d= oes 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?



--
J= ens Rantil
Backend engineer
Tink AB

Phone: +46= 708 84 18 32
Web:=C2=A0www.tink.se

Facebook<= span style=3D"font-family:arial;font-size:small">=C2=A0Linkedin=C2=A0Twit= ter

--001a11479576bf935b05169d0115--