cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Schuller <peter.schul...@infidyne.com>
Subject Re: Conditional get
Date Sat, 05 Jun 2010 21:06:04 GMT
> Eric wrote a good explanation with sample code at
> http://www.rackspacecloud.com/blog/2010/05/12/cassandra-by-example/

Regarding the schema description and analogy problem mentioned in the
article; I found that reading the BigTable paper helped a lot for me.
It seemed very useful to me to think of a ColumnFamily in Cassandra as
a sorted (on keys) on-disk table of entries with efficiency guarantees
with respect to range queries and locality on disk.

Please correct me if I am wrong, but the data model as I now
understand it essentially boils down to a sorted table of the form
(readers who don't know the answer, please don't assume I'm right
unless someone in the know confirms it; I don't want to add to the
confusion):

  rowkeyN+0,columnM+0 data
  rowkeyN+0,columnM+1 data
  ...
  rowkeyN+1 data
  rowkeyN+2 data
  ...

Where each piece of "data" is is the column (I am ignoring super
columns for now).

The table, other than being sorted, is indexed on row key and column name.

Is this correct?

In my head I think of it as there being some N amount of "keys" (not
the cassandra term) that are interesting to the application, which end
up mapping to the actual "key" (not the cassandra term) in the table.
So, in a column family "users", we might have a "john doe" whose age
is "47". This means we have a "key" (not the cassandra term) which is
"users,john doe,age" and whose value is "47" (ignoring time stamps and
ignoring keys that contain commas, and ignoring column names being
semantically part of the data).

So, given:

       users,john doe,age

We have, in cassandra terms:

  column family: users
  key: john doe
  column name: age

The fact that different column families are in different files, to me,
seems mostly to be an implementation details since performance
characteristics (sorting, locality on disk) should be the same as it
had been if it was just one huge table (ignoring compactation
concerns, etc).

The API exposed by cassandra is not one of a generalized multi-level
key, but rather one with specific concepts of ColumnFamily, Column and
SuperColumn. These essentially provides a two-level key (in the case
of a CF with C:s) and a three-level key (in the case of a CF with SC:s
with C:s), with the caveat that three-level keys are still only
indexed on their first two components (even though they are still
sorted on disk).

Does this make sense at all? Provided that I have not misunderstood
the model completely and am completely wrong, I find this a much more
natural way to think of the underlying storage semantics.

-- 
/ Peter Schuller

Mime
View raw message