cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Dennis <>
Subject Re: get keys based on values??
Date Wed, 06 Oct 2010 20:00:35 GMT
As jbellis mentioned, the secondary indexes with > will work for this but in
the mean time you can still index this manually in .6 (which will continue
to work in .7 if need be).

There are several ways to attack this now.  If you don't have too many users
you can have a row with "age" as the row key and then each column name will
be the age of the user and the column value would be the row key for the
user.  C* will order the columns in that row by the column name so you could
slice on them to get all the ids for the users in question.  Keep in mind
that this will create one row with an entry for every user so if you have
lots of users that could be a big row with all the associated problems.

If you have too much data for the above, you can create rows with the age as
the row key and column names as the row id with that age.  Then when you
want to query for all the users with ages > 33 you would start at 34 then
issue slice calls to each of those rows with a count of say 1000 to get the
user ids, then multiget with those ids to get the users.

If you have two much data for that and/or want better distribution of your
indexes across the cluster, you can add a second level of indexes.  You have
one row with a row key of 33 that contains UUID column names representing
the row keys of other rows that all contain user ids that have age 33.  Then
when you want to look up users with age 33, you query that top level row,
get all the UUIDs for the other rows, query those to give you the ids of
users with that age and then retrieve them.  When you add a new user, query
that first row to get all the row keys for the rows containing the users age
and pick one randomly to write to.  This has the obvious problem of reading
before writing so keep that in mind.

An alternative to having a second level of indexing but still splitting up
your index to multiple rows you could have multiple hash functions (as many
hash functions as rows you want to split up).  Then when given 33, you pass
it through all your different hash functions to return the rows that contain
ids for users with age 33.

On Wed, Oct 6, 2010 at 1:49 PM, Brayton Thompson <>wrote:

> Ok, let me tweak the scenario a tiny bit. What if I wanted something
> extremely arbitrary, for instance... simple comparisons like a WHERE clause
> in SQL....
> get Users.someuser['uuid'] where Users.someuser['age']  >  33
> From what i've read this functionality defeats the point of Cassandra
> because instead of indexing directly to a value C* would have to got to a
> value and run a check for every entry.  Am I correct here?
> So would my best bet be to simply get ALL of my users uuids and ages, then
> throw away all of those that do not meet the required test?
> Thank you.
> On Oct 6, 2010, at 2:09 PM, Matthew Dennis wrote:
> As Norman said, secondary indexes are only in .7 but you can create
> standard indexes in both .6 and .7
> Basically have a email_domain_idx CF where the row key is the domain and
> the column names have the row id of the user (the column value is unused in
> this scenario).  This sounds basically like what you described in your
> original post.  That's a very common way to do it in Cassandra (C*).  This
> is not all that different to what MySQL, PGSQl, etc do for you
> automatically, just in C* you have to do it manually and remember to write
> to that index column family whenever you write to the users CF.
> On Wed, Oct 6, 2010 at 12:56 PM, Brayton Thompson <>wrote:
>> Are secondary index's available in .6.5? or are they only in .7?
>> On Oct 6, 2010, at 1:15 PM, Tyler Hobbs wrote:
>> If you're interested in only checking part of a column's value, you can
>> generally
>> just store that part of the value in a different column.  So, have an
>> "email_addr" column
>> and a "email_domain" column, which stores "", for example.
>> Then you can just use a secondary index on the "email_domain" column.
>> - Tyler
>> On Wed, Oct 6, 2010 at 10:33 AM, Brayton Thompson <>wrote:
>>> Hash: SHA1
>>> Ok, I am VERY new to Cassandra and trying to get my head around its core
>>> ideas.
>>> So lets say I have a CF of Users that contains all the info I would ever
>>> want to know about them. One day I decide(for some reason) that I want to
>>> send a mass email to only the users with AOL email addresses. Is there a
>>> mechanism for getting only keys whose email attribute contains the string @
>>> ? Or is this frowned upon? I could also envision separate CF's
>>> for each email type; that stored values to use as keys into my Users CF. Say
>>> the AOL CF contains the usernames of everyone that has an aol account. So I
>>> would pull all of the keys from that CF and then use them to index into the
>>> Users CF to pull their email addresses.  It seems to me that this is
>>> redundant. So I would like your thoughts on my example.
>>> Thank you,
>>> Brayton Thompson
>>> Global Research Network Operation Center
>>> Indiana University
>>> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
>>> iQIcBAEBAgAGBQJMrJa1AAoJENisXTckM+p9ffcP/1UmNDyWxDnOu41ZRcVwmJiE
>>> +47QxqNc57WmdXX86FUvcauhPFFNZfbrbGwA61sof1sktSOL83osOXQuOfGr5GvT
>>> tulU3+rQ1B+ea0x+aBESbKZwXHxckLGdst2Hro1eCVXEna+VvqkxNJ2rvYzE3hNM
>>> FTNBWDIv3JbOChTYBnycBqg1iG5yMDkc2xEHlaiw9S/VsOPU18pPYrf42eoSqgnk
>>> /rZDCxxiThznuaLI70QnU3O7ZTiyXpavN8BUW6KoeDZNAypgg1AayhEL2d67zZWu
>>> qtnGEpoIeieinjccWMpkUrv2f14CZQ5gbJSLwPdoNLItYLnFvGHg0Ca/hXhrkIDr
>>> BqnA0R5w2YHB+5p84gvj1NTRE0O2kXcUHkLDDBvnlLKUOUkoDyqr5tGAIwHhIwA7
>>> hpko76CyGN84bS8Kma+1D6e8wg9zqfiS9mvvErJCUOwyU5e+XeoiCdyhwgDHJKlW
>>> T5UjMXdAHwyZly48J5l6jEJastHsL1wKAHeV/NlQ1gEx2CmnnJ0lBPDPqlT5Lxdb
>>> uQFzS/YhFzxWL2gApHKF8EdCz4jFbPUggYYPsVgfYkNNBISgcIiQaEIIPkri96vb
>>> V/xhnxLrFCO20NnGQ5PCTzCnZptyc3V+9WI542fnRGcS8SbF+N5BdLzoJBjtidrI
>>> a/Nps/KUhJ5kVzJ0o8H3
>>> =oBhH
>>> -----END PGP SIGNATURE-----
> --
> Riptano
> Software and Support for Apache Cassandra
> m: 512.587.0900 f: 866.583.2068

Software and Support for Apache Cassandra
m: 512.587.0900 f: 866.583.2068

View raw message