This is one of the sticking points with the key concatenation argument. You can't simply access subpartitions of data along an aggregate name using a concatenated key unless you can efficiently address a range of the keys according to a property of a subset. I'm hoping this will bear out with more of this discussion.
Another facet of this issue is performance with respect to storage layout. Presently columns within a row are inherently organized for efficient range operations. The key space is not generally optimal in this way. I'm hoping to see some discussion of this, as well. On Tue, May 11, 2010 at 6:17 AM, vd <vineetdan...@gmail.com> wrote: > Hi > > Can we make range search on ID:ID format as this would be treated as > single ID by API or can it bifurcate on ':' . If now then how do can > we ignore usage of supercolumns where we need to associate 'n' number > of rows to a single ID. > Like > CatID1-> articleID1 > CatID1-> articleID2 > CatID1-> articleID3 > CatID1-> articleID4 > How can we map such scenarios with simple column families. > > Rgds. > > On Tue, May 11, 2010 at 2:11 PM, Torsten Curdt <tcu...@vafer.org> wrote: >> Exactly. >> >> On Tue, May 11, 2010 at 10:20, David Boxenhorn <da...@lookin2.com> wrote: >>> Don't think of it as getting rid of supercolum. Think of it as adding >>> superdupercolums, supertriplecolums, etc. Or, in sparse array terminology: >>> array[dim1][dim2][dim3].....[dimN] = value >>> >>> Or, as said above: >>> >>> <Column Name="ThingThatsNowKey" Indexed="True" ClusterPartitioned="True" >>> Type="UTF8"> >>> <Column Name="ThingThatsNowColumnFamily" DiskPartitioned="True" >>> Type="UTF8"> >>> <Column Name="ThingThatsNowSuperColumnName" Type="Long"> >>> <Column Name="ThingThatsNowColumnName" Indexed="True" Type="ASCII"> >>> <Column Name="ThingThatCantCurrentlyBeRepresented"/> >>> </Column> >>> </Column> >>> </Column> >>> </Column> >> >
