Each block of data that we manage in Cassandra is 100% an equivalent to an SQL table.
This is very good since that way we do not increase the search time very much. The table now includes all the information we need.
This is fine at first... imagine now that you add 100 plug-ins and that each one of them add a few fields that extend the page. That means at some point you end-up with 101 tables all referencing the page_identifier with a one to one scheme. In other words, these 100 plug-ins could all have been defining extra fields in the main page table and increased the speed in reading the data by a good 10 folds.
When we added support for branches and languages, the data had to have multiple entries for each page. In order to handle that without having to change the field names each time, we instead decided to change the row name.
Content Table -- all the pages, includes the necessary references to know which branch and revision are current, which are the last, and which to edit.
Branch Table -- all the branch information for each page (data tha applies to all the revision of a branch such as links between pages).
Revision Table -- the content of the pages, the title, body, teaser, etc.; in case of an editor form, any number of fields may appear in a revision.