incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <>
Subject Re: Storage Layout Questions
Date Wed, 28 Apr 2010 14:40:36 GMT
I don't think you are missing anything.  You'll have to pick your poison.

FWIW, if each BAR has relatively few fields then supercolumns aren't
bad.  It's when a BAR has dynamically growing numbers of fields
(subcolumns) that you get in trouble with that model.

On Tue, Apr 27, 2010 at 4:24 PM, Jonathan Shook <> wrote:
> I'm trying to model a one-to-many set of data in which both sides of the
> relation may grow arbitrarily large.
> There are arbitrarily many FOOs. For each FOO, there are arbitrarily many
> BARs.
> Both types are modeled as an object, containing multiple fields (columns) in
> the application.
> Given a key-addressable FOO element, I'd like to be able to do range access
> operations on the associated BARs according to their temporal names.
> I wish to avoid:
> 1) using a super column to nest the temporal ids (or column names) within a
> row of the primary key,
>      due to the memory-based limitations of super column deserialization.
> (and implicit compute costs that go with it)
> 2) keeping a separate map between the FOO type and the BAR type.
> 3) serializing all BAR types into the value field of each FOO-keyed,
> BAR-named column.
> Were the super column addressing more scalable, I'd see it as a natural fit.
> Does anybody have an elegant solution to this which I am overlooking? In the
> absence of ideas, I'd like some feedback on the trade-offs of the above
> "avoids".
> Jonathan

Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support

View raw message