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.ke...@gmail.com> wrote: > Hi everyone, > > 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: > > 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)); > > 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. > > 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. > > Best regards, > Clint
