It all depends on what you're trying to do. What you're proposing doing, by
defintion, is creating a secondary index. The primary index is your row
key. Depending on the partitioner, it might or might not be a conveniently
iterable index or sorted index. If you need your keys sorted in a different
order than the partitioner does, if you need your keys organized into groups
that can be quickly retrieved or membership in tested against, or some other
reason why the primary index doesn't suffice, then you need a secondary
index. It all depends on whether you need to retrieve rows based on a
different criteria than what the primary index provides. If so, then yes,
you'll probably end up doing something that involves creating rows that are
full of row keys. But, if you're not storing a subset of your full key set
or you don't have specific needs for ordering and iterating, then it would
be redundant.
On Thu, Feb 24, 2011 at 11:18 AM, mcasandra <mohitanch...@gmail.com> wrote:
>
> Thanks! I am thinking more in terms where you have millions of keys (rows).
> For eg: UUID as a row key. or there could millions of users.
>
> So are we saying that we should NOT create column families with these many
> keys? What are the other options in such cases?
>
> UserProfile = { // this is a ColumnFamily
> > 1 { // this is the key to this Row inside the CF
> > // now we have an infinite # of columns in this row
> > username: "phatduckk",
> > email: "[hidden email]",
> > phone: "(900) 976-6666"
> > }, // end row
> > 2 { // this is the key to another row in the CF
> > // now we have another infinite # of columns in this row
> > username: "ieure",
> > email: "[hidden email]",
> > phone: "(888) 555-1212"
> > age: "66",
> > gender: "undecided"
> > },
> > }
>
> --
> View this message in context:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Understanding-Indexes-tp6058238p6061574.html
> Sent from the cassandra-u...@incubator.apache.org mailing list archive at
> Nabble.com.
>
