参考文档：http://www.datastax.com/documentation/cql/3.0/webhelp/index.html#cql/ddl/ddl_anatomy_table_c.html#concept_ds_qqw_1dy_zj
在一个层次上来说，Cassandra中的表、行和列可以认为和关系型数据库是相同的。在SQL和CQL中你可以定义表（包含已经定义好的行和与之相关的数据类型），你可以创建索引去增加查询效率。
然而，一个重要的不同是因为Cassandra是被设计来分组成为一个分布式的系统，它强调使用逆规范化代替规范化和连接，它提供了了工具（如集合）去支持。
一、例子——音乐服务
这是一个关于音乐服务的例子，需要一张音乐表songs，包含标题、唱片集、艺术家列以及外加的名为数据（包含真实音频文件的）的列。这张表使用一个UUID座位主键。
CREATE TABLE songs (
id uuid PRIMARY KEY,
title text,
album text,
artist text,
data blob
);
在关系型数据库中，你应当创立一个播放列表playlists通过一个外键和音乐表相关联。但是在Cassandra中，你反规范化数据。为了表示播放列表的数据，你可以创建一张如下的表：
CREATE TABLE playlists (
id uuid,
song_order int,
song_id uuid,
title text,
album text,
artist text,
PRIMARY KEY (id, song_order )
);
在playlists表中，id和song_order的组合可以唯一标识一行。你可以超过一行的数据包含相同的id只要song_order不同即可。
提示: UUID可以方便在多个机器中排序或者自动增加。简单地说，int类型的song_order就是一个例子。
当插入样本数据到播放列表后，选择所有数据的输出会像一下：
SELECT * FROM playlists;
The next example illustrates how you can create a query that uses the artist as a filter. First, add a little more data to the playlist table to make things interesting for the collections examples later:
INSERT INTO playlists (id, song_order, song_id, title, artist, album)
VALUES (62c36092-82a1-3a00-93d1-46196ee77204, 4,
7db1a490-5878-11e2-bcfd-0800200c9a66,
‘Ojo Rojo‘, ‘Fu Manchu‘, ‘No One Rides for Free‘);
With the schema as given so far, a query that includes the artist filter would require a sequential scan across the entire playlists dataset. Cassandra will reject such a query. If you first create an index on artist, Cassandra can efficiently pull out the records in question.
CREATE INDEX ON playlists(artist );
Now, you can query the playlists for songs by Fu Manchu, for example:
SELECT * FROM playlists WHERE artist = ‘Fu Manchu‘;
The output looks something like this:
Compound keys and clustering
A compound primary key includes the partition key, which determines on which node data is stored, and one or more additional columns that determine clustering. Cassandra uses the first column name in the primary key definition as the partition key. For example, in the playlists table, id is the partition key. The remaining column, or columns that are not partition keys in the primary key definition are the clustering columns. In the case of the playlists table, the song_order is the clustering column. The data for each partition is clustered by the remaining column or columns of the primary key definition. On a physical node, when rows for a partition key are stored in order based on the clustering columns, retrieval of rows is very efficient. For example, because the id in the playlists table is the partition key, all the songs for a playlist are clustered in the order of the remaining song_order column.
Insertion, update, and deletion operations on rows sharing the same partition key for a table are performed atomically and in isolation. See About transactions and concurrency control.
You can query a single sequential set of data on disk to get the songs for a playlist.
SELECT * FROM playlists WHERE id = 62c36092-82a1-3a00-93d1-46196ee77204
ORDER BY song_order DESC LIMIT 50;
The output looks something like this:
Cassandra stores data on a node by partition key. If you have too much data in a partition and want to spread the data over multiple nodes, use a composite partition key.