cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Savage <>
Subject Re: CQL Select Map using an IN relationship
Date Fri, 14 Mar 2014 14:41:24 GMT
Hi Michael,

Thanks for the feedback, all makes sense.

If anyone wants me to raise a jira ticket for docs on (key1, key2) vs
((key1,key2)) and their implications, or fixing that if block in
SelectStatement, let me know - though for the if block possibly best if
that jira is raised by a C* expert so it uses the right terminology to
describe the problem ;)

Kind regards,


On Fri, Mar 14, 2014 at 12:49 AM, Laing, Michael

> These are my personal opinions, reflecting both my long experience w
> database systems, and my newness to Cassandra...
> [tl;dr]
> The Cassandra contributors, having made its history, tend to describe it
> in terms of implementation rather than action. And its implementation has a
> history, all relatively recent, that many know, but which to newcomers like
> me is obscure and, frankly, not particularly relevant.
> Note: we are all trying to understand Crimea now, and to really
> understand, you have to ingest several hundred years of history. Luckily,
> Cassandra has not been around quite so long!
> But Cassandra's history creeps into the nomenclature of CQL3. So what
> might logically be called a 'hash key' is called a 'partition key', what is
> called a 'clustering key' might be better termed a 'range key' IMHO.
> The 'official' terms in the nomenclature are important to know, they are
> just not descriptive of the actions one takes as a user of them. However,
> they have meaning to those who have 'lived' the history of Cassandra, and
> form an important bridge to the past.
> As a new user I found them non-intuitive. Amazon has done a much better
> job with DynamoDB - muddled, however, by bad syntax choices.
> But you adjust and mentally map... I am still bumfuzzled when people talk
> of slices and other C* cruft but just let it slide by like lectures from my
> mother. That and thrift can just fade into history with gopher and lynx as
> far as I am concerned - CQL3 is where it's at.
> But another thing to remember is that performance is king - and to get
> performance you fly 'close to the metal': Cassandra does that and you
> should know the code paths, the physical structures, and the
> characteristics of your 'metal' to understand how to build high-performing
> apps.
> ***
> The answer to both asterisks is Yes. You should use the term 'clustering
> column' because that is what is in the docs - but you should think 'range
> key' for how you use it. Similarly 'partition key' : 'hash key'.
> Good luck,
> ml

View raw message