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?
