Over the previous ten chapters, we've thoroughly explored Cassandra's capabilities from the perspective of application developers. All of our interaction with Cassandra has been through CQL, and we've explored a robust set of features available to us via the CQL interface. We've found that one of the big appeals of Cassandra is the rich set of data structures available to us for domain modeling; structures such as compound primary keys, collection columns, and secondary indexes are part of what sets Cassandra apart from other distributed databases.
As it turns out, CQL is an abstraction on top of a much less sophisticated data structure that underlies all the data stored in Cassandra. Commonly referred to as the Thrift interface, named after the protocol used to interact with Cassandra at this level, this layer represents all data using an ad hoc key-value structure called a column family. As developers, we will never need to interact with Cassandra at this level of abstraction, but it's illuminating to explore how the familiar CQL data structures are represented at the column family level.
Note
In some contexts, you might hear the terms table and column family used interchangeably. In fact, CQL provides CREATE COLUMNFAMILY as an alias for the familiar CREATE TABLE command. This is a legacy of the gradual divergence of the CQL table structure from the underlying column family structure. In earlier versions of CQL, tables were mapped more or less transparently onto the underlying column family structure.
We will use the terminology preferred by the Cassandra developers, using table to talk about the CQL data structure and column family for the lower level structure available via the Thrift interface.
When we have completed exploring the Thrift interface, you'll have discovered:
How to directly access Cassandra's low-level column family structures
Column family representation of simple and compound primary keys
The structure of collection columns at the column family level