最基础的primary key(The basic primary key)
我们从最基础table开始,他们可以被称为“静态表”或“实体表”，用于存储单个数据记录。下面这个例子来源KillrVideo的一个例子程序。
`CREATE TABLE videos (
videoid uuid,
userid uuid,
name varchar,
description varchar,
location text,
location_typeint,
preview_thumbnails map<text,text>,
tags set<varchar>,
added_date timestamp,
PRIMARY KEY (videoid)
);
`
上面的PRIMARY KEY是最简单的组成行式。区分出上传到我们系统每个不同的video就是通过这个单一的参数作为唯一标识。前面的PRIMARY KEY的第一个元素我们称之为分区键。分区键在Apache Cassandra中有一个特殊作用，除了显示数据库中记录的唯一性。另一个作用是，确定在分布式系统中数据的存放位置。
当数据写入到集群中的时候，第一步就是用hash函数计算partition key的值。
这个计算后的hash值将决定这条数据存放在哪个数据节点（或者replicas）上面。Apache Cassandra使用的算法是Murmur3，它将采取任意输入并返回固定范围内的（当前集群的结点有对应的）值。
注：分区键属于一个节点。 Cassandra被组织成一个节点簇，每个节点具有相等的分区密钥散列。想象一下，我们有一个四节点Cassandra集群。在下面的示例集群中，节点1负责分区密钥哈希值在0-24范围;节点2负责分区密钥哈希值25-49范围等，如下图：
简而言之，分区键始终会对应集群中一个节点，并且该分区键上对应的数据将始终可以在该节点上找到。
为什么这么重要呢？如果我们不能直接定位到分区键上对应的数据，那么为了查询到你的数据，我们必须检索集群中的每个节点。在一个很小集群中，他可能很快的完成检索，但是在一个非常大的集群环境中，要完成这个检索就会很费时。下面的图表能更好的展示我们想表达的东西：
复合主键(Complex primary key)
Apache Cassandra中的另一种表格就是我们所说的“动态表格”。让我们先来看看KillrVideo的另一个例子：
CREATE TABLE user_videos (
userid uuid,
added_date timestamp,
videoid uuid,
name text,
preview_image_location text,
PRIMARY KEY (userid, added_date, videoid)
);
在这张表中，我们能查询到‘显示与特定用户相关的所有视频’。正如你看到的那样，这个PRIMARY KEY有多个分区键，我们现在添加了多个成分（elements）。
在分区键之后列出的所有列称为聚簇列(clustering columns)。这是我们和关系型数据库中有着很大不同的地方。分区键决定数据存放在哪个节点上，而聚簇列(clustering columns)决定了数据在该节点分区内排列的顺序。对于这个PRIMARYkey,我们读这个的方法是从左到右讲解：
[if !supportLists]l[endif]第一个元素是分区键
[if !supportLists]l[endif]第二元素是聚簇列(clustering columns)，added_date字段是一个时间戳，因此排序顺序按时间顺序升序排列。
[if !supportLists]l[endif]第三元素是第二个聚簇列(clustering columns)，由于videoid是一个UUID，所以我们将它包括在内以便简单地表明它是唯一记录的一部分。
在插入数据之后，您期望您的查询结果按照在单个分区内按added_date字段的升序来返回数据。
控制聚簇列的顺序(Controlling order of the clustering columns)
由于聚簇列决定单个分区中的顺序，因此对控制排序的方向性会有很大的帮助。我们可以通过向我们的SELECT中添加一个ORDER BY子句来完成这个时间排序查询，如下所示：
SELECT *
FROM user_videos
WHERE userid = 522b1fe2-2e36-4cef-a667-cd4237d08b89
ORDER BY added_date DESC;
假如我们想将一些字段的排序顺序给定一个默认值呢？我们可以在创建表的时候使用CLUSTERING ORDER BY子句来指定：
CREATE TABLE user_videos (
userid uuid,
added_date timestamp,
videoid uuid,
name text,
preview_image_location text,
PRIMARY KEY (userid, added_date, videoid)
) WITH CLUSTERING ORDER BY (added_date DESC, videoid ASC);
现在，当我们将数据插入到user_videos表时，数据已经预先按added_date字段作降序排列了。
这可能看起来像是一个预优化，但是这种使用的用例非常引人注目。当在时间序列数据模型中使用ORDER BY时，我们现在可以快速访问插入的最后N条数据。举个例子：
SELECT *
FROM user_videos
WHERE userid = 522b1fe2-2e36-4cef-a667-cd4237d08b89
LIMIT 10;
当我们查询‘用户上传的最后10个视频’时，通过简单添加CLUSTERING ORDER BY子句，就可以实现非常快速，有用且高效的查询。这在用户交互或欺诈用例的情况下使用非常有用。
总结(Conclusion)
在这个关于PRIMARY KEY的快速概述中，我希望你看到主键KEY不但对你的查询很重要，而且对于你如何存储你的数据也是如此。对组件的一些基本理解可以帮助您在设计下一个数据模型中做出明智的选择。例如，现在您已经了解了分区键控制数据的位置后，所以最好不要只使用一个分区了！一个极端的例子就是，你可以轻松的做出一个基于Cassandra的程序而且你不须要知道其背后的原理。现在您已经知道Cassandra数据建模中最重要的知识了，那么您将如何处理它？
网友评论