cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <aa...@thelastpickle.com>
Subject Re: Supercolumn behavior on writes
Date Mon, 18 Jun 2012 01:32:20 GMT
Writing to a super column family does not involve deserialisation, other than writing to the
commit log it is an in memory operation.

Cheers

-----------------
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com

On 15/06/2012, at 3:36 AM, Greg Fausak wrote:

> Derek,
> 
> Thanks for that!
> 
> Yes, I am aware of that technique.  I am currently using something
> very similar on an sql database.  I think one of the great benefits with
> Cassandra is that you can invent these on the fly.  I also think there
> is great benefit to keep all of the columns in the same row.
> 
> Anyway, I didn't mean to hijack Oleg's thread.  I am interested
> in the original question about the serialization/deserialization on write.
> Does anybody know?
> 
> -g
> 
> 
> On Wed, Jun 13, 2012 at 11:45 PM, Derek Williams <derek@fyrie.net> wrote:
>> On Wed, Jun 13, 2012 at 9:08 PM, Greg Fausak <greg@named.com> wrote:
>>> 
>>> Interesting.
>>> 
>>> How do you do it?
>>> 
>>> I have a version 2 CF, that works fine.
>>> A version 3 table won't let me invent columns that
>>> don't exist yet. (for composite tables).  What's the trick?
>> 
>> 
>> You are able to get the same behaviour as non cql by doing something like
>> this:
>> 
>> CREATE TABLE mytable (
>>   id bigint,
>>   name text,
>>   value text,
>>   PRIMARY KEY (id, name)
>> ) WITH COMPACT STORAGE;
>> 
>> This table will work exactly like a standard column family with no defined
>> columns. For example:
>> 
>> cqlsh:testing> INSERT INTO mytable (id, name, value) VALUES (1, 'firstname',
>> 'Alice');
>> cqlsh:testing> INSERT INTO mytable (id, name, value) VALUES (1, 'email',
>> 'alice@example.org');
>> cqlsh:testing> INSERT INTO mytable (id, name, value) VALUES (2, 'firstname',
>> 'Bob');
>> cqlsh:testing> INSERT INTO mytable (id, name, value) VALUES (2, 'webpage',
>> 'http://bob.example.org');
>> cqlsh:testing> INSERT INTO mytable (id, name, value) VALUES (2, 'email',
>> 'bob@example.org');
>> 
>> cqlsh:testing> SELECT name, value FROM mytable WHERE id = 2;
>>  name      | value
>> -----------+------------------------
>>      email |        bob@example.org
>>  firstname |                    Bob
>>    webpage | http://bob.example.org
>> 
>> Not very exciting, but when you take a look with cassandra-cli:
>> 
>> [default@testing] get mytable[2];
>> => (column=email, value=bob@example.org, timestamp=1339648270284000)
>> => (column=firstname, value=Bob, timestamp=1339648270275000)
>> => (column=webpage, value=http://bob.example.org,
>> timestamp=1339648270280000)
>> Returned 3 results.
>> Elapsed time: 11 msec(s).
>> 
>> which is exactly what you would expect from a normal cassandra column
>> family.
>> 
>> So the trick is to separate your static columns and your dynamic columns
>> into separate column families. Column names and types can of course be
>> something different then my example, and inserts can be done within a
>> 'BATCH' to avoid multiple round trips.
>> 
>> Also, I'm not trying to advocate this as being a better solution then just
>> using the old thrift interface, I'm just showing an example of how to do it.
>> I personally do prefer this way as it is more predictable, but of course
>> others will have a different opinion.
>> 
>> --
>> Derek Williams
>> 


Mime
View raw message