incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Primary/secondary index question / best practices?
Date Tue, 11 Dec 2012 22:45:22 GMT
Dean, thank you for your response.  To the second half of the query, I'm a little concerned
about the secondary index approach since the indexes that I want to create are columns with
high entropy.

For example, I would like to query by User name and IP address, values which are decidedly
NOT like the pattern recommended in the Secondary Index field.   The 8-10 columns I need to
search by are all high a similar scatter rate.  Since the documentation seems to suggest that
this is a bad idea, what would the correct pattern look like?

In an RDBMS I would just slap an alternate key index on the table and let it roll.   It seems
like maybe that is not the right approach for Cassandra?

Thanks again,


-----Original Message-----
From: Hiller, Dean []
Sent: Tuesday, December 11, 2012 4:57 PM
Subject: Re: Primary/secondary index question / best practices?

Hard to help out on a design without specifics but here is some advice based on the limited

Primary key : yes, must be cluster unique.  TimeUUID or UUID....PlayOrm has very unique TimeUUID
like keys as in this one 7AL2S8Y.b1 (b1 is the hostname and the prefix is a "unique" timestamp
but generated to a shorter string(ah, nice readable primary keys).

There are some patterns you can look into here that may help

If you can partition your data virtually, it may help a lot so you can query into the partitions.



From: "<><>"

Reply-To: "<><>"

Date: Tuesday, December 11, 2012 2:49 PM

To: "<><>"

Subject: Primary/secondary index question / best practices?

m my reading, it seems like I need a UUID column that will be my primary index, and then I
should set up secondary indexes on the 8-10 primary search columns.  Am I understanding this
correctly?  Any advice you can offer on this would be tremendously helpful.  I'm quite limited
in how specific I can be about the data, of course.

View raw message