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 <de...@fyrie.net> wrote: >> On Wed, Jun 13, 2012 at 9:08 PM, Greg Fausak <g...@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', >> 'al...@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', >> 'b...@example.org'); >> >> cqlsh:testing> SELECT name, value FROM mytable WHERE id = 2; >> name | value >> -----------+------------------------ >> email | b...@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=b...@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 >>
