Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of clohfink@blackbirdit.com
 designates 209.85.213.182 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: How to maintain the N-most-recent versions of a value?
From: Chris Lohfink <clohfink@blackbirdit.com>
In-Reply-To: 
 <CACz-ikvWipd+6EZv=7ovNOoaTXnRShccn97GaBXLSv+UaRPh8g@mail.gmail.com>
Date: Thu, 17 Jul 2014 20:39:56 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A9E0F83-4335-43F6-9E30-6FA36C98A375@blackbirdit.com>
References: 
 <CACz-ikvWipd+6EZv=7ovNOoaTXnRShccn97GaBXLSv+UaRPh8g@mail.gmail.com>
To: user@cassandra.apache.org

I would say that would work, but since already familiar with storage =
model from hbase and trying to emulate it may want to  look into thrift =
interfaces.  They little more similar to hbase interface (not as =
friendly to use and you cant use the very useful new client libraries =
from datastax) and accesses storage more directly, which is similar to =
hbases. You have your column family foo, then just use a composite =
column to store family, qualifier, and version in column name with value =
of column being "value".  row key is your row key.

---
Chris Lohfink


On Jul 17, 2014, at 6:32 PM, Clint Kelly <clint.kelly@gmail.com> wrote:

> Hi everyone,
>=20
> I am trying to design a schema that will keep the N-most-recent
> versions of a value.  Currently my table looks like the following:
>=20
> CREATE TABLE foo (
>    rowkey text,
>    family text,
>    qualifier text,
>    version long,
>    value blob,
>    PRIMARY KEY (rowkey, family, qualifier, version))
> WITH CLUSTER ORDER BY (rowkey ASC, family ASC, qualifier ASC, version =
DESC));
>=20
> Is there any standard design pattern for updating such a layout such
> that I keep the N-most-recent (version, value) pairs for every unique
> (rowkey, family, qualifier)?  I can't think of any way to do this
> without doing a read-modify-write.  The best thing I can think of is
> to use TTL to approximate the desired behavior (which will work if I
> know how often we are writing new data to the table).  I could also
> use "LIMIT N" in my queries to limit myself to only N items, but that
> does not address any of the storage-size issues.
>=20
> In case anyone is curious, this question is related to some work that
> I am doing translating a system built on HBase (which provides this
> "keep the N-most-recent-version-of-a-cell" behavior) to Cassandra
> while providing the user with as-similar-as-possible an interface.
>=20
> Best regards,
> Clint