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 <jsh...@gmail.com> 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 http://riptano.com
