Ah, now I understand. Supercolumns it is. On Wed, Apr 28, 2010 at 9:40 AM, Jonathan Ellis <jbel...@gmail.com> wrote:
> 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 >
