CQL - Practical Cassandra - page 34

CQL 2
CQL 2 is often referred to as “a language for wide rows.” CQL 2 filled in the gaps
that CQL 1 had. This meant that one could create a wide-row ColumnFamily and
access it using CQL. Arguably the most used and most important feature of Cas-
sandra is the ability to get a slice of columns from a row. This enables a user to
create very wide rows where the column name may not be known ahead of time.
In many ways, CQL 2 was just an SQL-like syntax of the Thrift API repres-
entation of data. This meant the user still had to be aware of the underlying data
structures and concepts that come along with storing data in Cassandra. This made
CQL 2 easy to implement for current Cassandra users as it mapped directly to the
storage engine. There were, however, many problems with this.
Because the number of columns returned was indefinite, there had to be two
LIMIT clauses, one for the row limit and another for the column limit. This cre-
ated several issues when there could be different column counts in rows. Functions
like COUNT would not work either, for the same reason. As a result, COUNT was
never implemented. You also could not specify indexes on wide rows because of
the underlying limitation that indexes could only be on predefined columns. Since
the columns are not defined ahead of time, there is no way to specify an index
for them. Also, if you were using CompositeType columns in your wide rows, the
column names needed to be unpacked manually. This led to the clients' or the ap-
plications' needing to know the composite packing structure for CQL.
CQL 3
CQL 3 compensates for the shortcomings of the previous versions by actually
transposing the wide rows and unpacking them into named columns. This means
that many rows can be visualized via CQL 3 from a single physical row in the data
structure. CQL 3 can accomplish this by attaching metadata to the ColumnFamily
and to each row.
Since CQL 3 has special metadata attached, this presents a problem for back-
ward compatibility with legacy tables. All of your current tables already exist
in the CQL 3 space as COMPACT STORAGE or legacy tables. In CQL 3, the
PRIMARY KEY determines whether a ColumnFamily is static or dynamic. A stat-
ic ColumnFamily will have a single PRIMARY KEY , while a dynamic Colum-
nFamily will have a compound PRIMARY KEY . When creating a dynamic
ColumnFamily, the first part of the compound PRIMARY KEY is known as the
partition key. In the Thrift API, this maps directly to the row key. Each subsequent