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
>>
|