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 510C787EF for ; Sat, 20 Aug 2011 02:39:41 +0000 (UTC) Received: (qmail 5784 invoked by uid 500); 20 Aug 2011 02:39:38 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 5493 invoked by uid 500); 20 Aug 2011 02:39:34 -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 5482 invoked by uid 99); 20 Aug 2011 02:39:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 20 Aug 2011 02:39:33 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jbellis@gmail.com designates 209.85.215.170 as permitted sender) Received: from [209.85.215.170] (HELO mail-ey0-f170.google.com) (209.85.215.170) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 20 Aug 2011 02:39:29 +0000 Received: by eyd10 with SMTP id 10so2147527eyd.1 for ; Fri, 19 Aug 2011 19:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=gbcasHj7lDlXLXAT2JVMHRLVgg4DtfMOwpTAFBo5GXc=; b=tXJ60VjSGfpsiNZ9HJ9xvIWs13MwMqkek8gvsHhPjAL3IXWQPS3HOZp/XcfcLXYD6t 29LBa+mzWk8cERY1RVbSIufVBNGtbQVQCElyGjtV1FlTjxdSuq0rF/G9JOgOH/RPHFUV cx110KaqWrDGSmCFbrM277yKM4D81X+yfetKE= Received: by 10.213.106.2 with SMTP id v2mr26968ebo.33.1313807947261; Fri, 19 Aug 2011 19:39:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.10.143 with HTTP; Fri, 19 Aug 2011 19:38:47 -0700 (PDT) In-Reply-To: References: From: Jonathan Ellis Date: Fri, 19 Aug 2011 21:38:47 -0500 Message-ID: Subject: Re: memory overhead of vector clocks vs timestamps and running *without* either to save memory? To: user@cassandra.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The problem with naive last write wins is that writes don't always arrive at each replica in the same order. So no, that's a non-starter. Vector clocks are a series of (client id, clock) entries, and usually a timestamp so you can prune old entries. Obviously implementations can vary, but to pick a specific example, Voldemort [1] uses 2 bytes per client id, a variable number (at least one) of bytes for the clock, and 8 bytes for the timestamp. [1] https://github.com/voldemort/voldemort/blob/master/src/java/voldemort/v= ersioning/VectorClock.java On Fri, Aug 19, 2011 at 7:41 PM, Kevin Burton wrote: > I have a few questions which I can't seem to find answers to... > I know that the memory overhead of timestamps is 8 bytes per row/column. > =A0=A0What is the memory overhead of vector clocks? > Is it possible (at least in theory) to run without timestamps on your > values? =A0I'm fine with last writer wins semantics and the memory overhe= ad > here seems very high. > I understand that the timestamps might also be for repartitioning which a= dds > complexity. > Thanks! > > -- > > Founder/CEO=A0Spinn3r.com > > Location:=A0San Francisco, CA > Skype:=A0burtonator > > Skype-in:=A0(415) 871-0687 > --=20 Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com