Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 63224 invoked from network); 10 Apr 2011 01:05:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Apr 2011 01:05:03 -0000 Received: (qmail 37352 invoked by uid 500); 10 Apr 2011 01:05:02 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 37325 invoked by uid 500); 10 Apr 2011 01:05:02 -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 37317 invoked by uid 99); 10 Apr 2011 01:05:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 10 Apr 2011 01:05:01 +0000 X-ASF-Spam-Status: No, hits=2.8 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of stuhood@gmail.com designates 209.85.160.44 as permitted sender) Received: from [209.85.160.44] (HELO mail-pw0-f44.google.com) (209.85.160.44) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 10 Apr 2011 01:04:56 +0000 Received: by pwi5 with SMTP id 5so2075532pwi.31 for ; Sat, 09 Apr 2011 18:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=QnSVTKsyQt/mapLpG8314L5Jyo7sDF4YWsOmz60wygY=; b=K9qtyeWgK6fZADM6s8kzOTaGa6G5w0ZYsx9Tq6+7JUVxHYbAerwgMwk1/m0Oh4dNG9 GIoojmpmmicea3VdDkY+mXB1lTyRVxtmhJiqLf9/uZGkS+sOvINai7WwPhg1Ut/U8pBs reolXMhz3fg4B9KpZFxs4WIrlwYT+cyMn6QBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=I6i856S4oLbpqE97sHsQfTBMehHQl6LQX1H9D+uvoeOQ2UrMH0GnCaiocHMV6r91VD dTrHYNPMurpGyMNUuBlm6eBrZPsFQ+PiF8CnpW6uex93AaDZeHEZxOxxvArTRz9mWAFY w1K/mAaheYQ2HiNVc5ezFFvWe4pY2HKb5LZ1A= MIME-Version: 1.0 Received: by 10.142.247.10 with SMTP id u10mr3280353wfh.414.1302397476105; Sat, 09 Apr 2011 18:04:36 -0700 (PDT) Received: by 10.68.65.226 with HTTP; Sat, 9 Apr 2011 18:04:36 -0700 (PDT) In-Reply-To: <1302396738637-6258033.post@n2.nabble.com> References: <1302393748191-6257960.post@n2.nabble.com> <3124743461587477655@unknownmsgid> <1302396738637-6258033.post@n2.nabble.com> Date: Sat, 9 Apr 2011 18:04:36 -0700 Message-ID: Subject: Re: Columns values(integer) need frequent updates/ increments From: Stu Hood To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=00504502cc56eb6e6504a0860a5f --00504502cc56eb6e6504a0860a5f Content-Type: text/plain; charset=ISO-8859-1 If an SSTable contains an update for a row (row, not just column), we need to read from it. See #1608 for some of the ideas that have been floated on how to improve this situation: the core ones are 1. partitioning local data so that the the number of files involved in a read is smaller, 2. adding support for "superceding" data in older files so that they can be skipped. #2316 will provide the beginning of a solution to this problem for wide rows. On Sat, Apr 9, 2011 at 5:52 PM, mcasandra wrote: > That I understand but my basic quesiton was how does it know that there are > multiple updates that have occurred on the same column? and how does it > efficiently knows which sstable have these updates? > > -- > View this message in context: > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Columns-values-integer-need-frequent-updates-increments-tp6251464p6258033.html > Sent from the cassandra-user@incubator.apache.org mailing list archive at > Nabble.com. > --00504502cc56eb6e6504a0860a5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If an SSTable contains an update for a row (row, not just column), we need = to read from it. See #1608 for some of the ideas that have been floated on = how to improve this situation: the core ones are 1. partitioning local data= so that the the number of files involved in a read is smaller, 2. adding s= upport for "superceding" data in older files so that they can be = skipped. #2316 will provide the beginning of a solution to this problem for= wide rows.


On Sat, Apr 9, 2011 at 5:52 PM, mcasandr= a <mohitanch= lia@gmail.com> wrote:
That I understand but my basic quesiton was how does it know that there are=
multiple updates that have occurred on the same column? and how does it
efficiently knows which sstable have these updates?

--
View this message in context: http://cassandra-user= -incubator-apache-org.3065146.n2.nabble.com/Columns-values-integer-need-fre= quent-updates-increments-tp6251464p6258033.html
Sent from the cassandra-user@incubator.apache.org = mailing list archive at Nabble.com.

--00504502cc56eb6e6504a0860a5f--