I think what you're describing might give me what I'm after, but I don't see how I can pass different column slices in a multiget call. I may be missing something, but it looks like you pass multiple keys but only a singular SlicePredicate. Please let me know if that's not what you meant.
I'm aware of CQL3 collections, but I don't think they quite suite my needs in this case. Thanks for the suggestions! Adam On Fri, Sep 14, 2012 at 1:56 AM, aaron morton <aa...@thelastpickle.com>wrote: > You _could_ use one wide row and do a multiget against the same row for > different column slices. Would be less efficient than a single get against > the row. But you could still do big contiguous column slices. > > You may get some benefit from the collections in CQL 3 > http://www.datastax.com/dev/blog/cql3_collections > > Hope that helps. > > > ----------------- > Aaron Morton > Freelance Developer > @aaronmorton > http://www.thelastpickle.com > > On 14/09/2012, at 8:31 AM, Adam Holmberg <adam.holmberg.l...@gmail.com> > wrote: > > I'm modeling a new application and considering the use of SuperColumn vs. > Composite Column paradigms. I understand that SuperColumns are discouraged > in new development, but I'm pondering a query where it seems like > SuperColumns might be better suited. > > Consider a CF with SuperColumn layout as follows > > t = { > k1: { > s1: { c1:v1, c2:v2 }, > s2: { c1:v3, c2:v4 }, > s3: { c1:v5, c2:v6} > ... > } > ... > } > > Which might be modeled in CQL3: > > CREATE TABLE t ( > k text, > s text, > c1 text, > c2 text, > PRIMARY KEY (k, s) > ); > > I know that it is possible to do range slices with either approach. > However, with SuperColumns I can do sparse slice queries with a set (list) > of column names as the SlicePredicate. I understand that the composites API > only returns contiguous slices, but I keep finding myself wanting to do a > query as follows: > > SELECT * FROM t WHERE k = 'foo' AND s IN (1,3); > > The question: Is there a recommended technique for emulating sparse column > slices in composites? > > One suggestion I've read is to get the entire range and filter client > side. This is pretty punishing if the range is large and the second keys > being queried are sparse. Additionally, there are enough keys being queried > that calling once per key is undesirable. > > I also realize that I could manually composite k:s as the row key and use > multiget, but this gives away the benefit of having these records proximate > when range queries *are* used. > > Any input on modeling/query techniques would be appreciated. > > Regards, > Adam Holmberg > > > P.S./Sidebar: > -------------------- > What this seems like to me is a desire for 'multiget' at the second key > level analogous to multiget at the row key level. Is this something that > could be implemented in the server using SlicePredicate.column_names? Is > this just an implementation gap, or is there something technical I'm > overlooking? > > >
