Primary key的基本使用方法
Primary key的基本使用方法同關系型數(shù)據(jù)庫中的primary key基本相同拖叙，既用來作為某一行數(shù)據(jù)的主鍵物喷。我們用一個最基本的Cassandra表來作為例子胁孙。這種最基本的表可以被稱為“靜態(tài)表”鞋仍。示例如下：
CREATE TABLE users (
user_id uuid,
name varchar,
description varchar,
registered_data timestamp,
PRIMARY KEY (user_id)
);
這個例子中的PRIMARY KEY定義是最簡單的一種形式——僅指定某一列作為primary key，起到唯一地確定某一行數(shù)據(jù)記錄的作用对省。在上面的例子中焙糟，也就是唯一地確定某一個user口渔。PRIMARY KEY()聲明中的第一個參數(shù)一般被稱作partition key。在Cassandra中穿撮，partition key除去唯一地確定某一行數(shù)據(jù)的作用之外缺脉，還起到排序數(shù)據(jù)及在分布式系統(tǒng)中確定數(shù)據(jù)的位置的作用（這一點在分布式系統(tǒng)中極其重要）痪欲。
當數(shù)據(jù)被插入一個Cassandra集群中時，第一個步驟是根據(jù)所采用的一致性哈希（consistent hash）算法得出數(shù)據(jù)partition key所對應的哈希值攻礼。這個哈希值被用來確定數(shù)據(jù)應當被放在集群中的哪一個結點以及數(shù)據(jù)的冗余備份應當被放在哪幾個結點业踢。Cassandra默認采用的哈希算法是Murmur3。一致性哈希算法的特點是可以接受任何輸入礁扮，但總會輸出位于固定范圍內的（當前集群的結點有對應的）值知举。簡而言之，某一特定的partition key總會對應集群中的某一特定的結點太伊，而這個partition key對應的數(shù)據(jù)也總是應當在這個結點上被找到雇锡。
對于分布式系統(tǒng)而言，這一點極其重要僚焦。其原因是如果對某一特定數(shù)據(jù)锰提，我們無法確定其所對應的結點位置的話，我們就總是需要遍歷集群中的每一個結點才能找到需要的數(shù)據(jù)芳悲。對于小規(guī)模的集群立肘，這樣的操作可能還可以接受。但對于大規(guī)模的分布式數(shù)據(jù)庫而言名扛，這將會嚴重影響整個系統(tǒng)的效率谅年。
Primary key的進階使用方法
如果Cassandra的表的Primary KEY包含某一數(shù)據(jù)的多個列，我們稱之為“動態(tài)表”罢洲。如下面的例子所示：
CREATE TABLE user_articles (
user_id uuid,
uploaded_date timestamp,
article_id uuid,
title test,
abstract text,
PRIMARY KEY (user_id, uploaded_date, article_id)
);
利用這個表我們可以滿足對某一用戶所發(fā)表的文章的查詢踢故。在這一例子中PRIMARY KEY()聲明包含數(shù)據(jù)的多個列文黎。與前文所述相同惹苗，聲明中包含的第一列仍然是數(shù)據(jù)的partition key。其后所跟的所有的列都稱為clustering column耸峭。這一點與關系型數(shù)據(jù)庫非常不同桩蓉。clustering column用來確定數(shù)據(jù)在partition內部的排列順序，對上面的例子而言劳闹，也就是對于同一個user_id而言院究，其所對應的所有行的排列順序。對于這個paimary key本涕，我們的應當這樣理解：
- 第一個元素確定了partition key
- 第二個元素確定了第一個clustering column业汰，在這個例子中，也就是
uploaded_date菩颖。uploaded_date是一個時間戳样漆，也就是說，對于同一個partition key而言晦闰，數(shù)據(jù)將會根據(jù)時間升序排列放祟。 - 第三個元素確定了第二個clustering column鳍怨，在這個例子中，也就是
article_id跪妥。article_id是一個uuid鞋喇，能夠唯一地確定某一篇文章。
在插入相應的數(shù)據(jù)之后眉撵，如果我們使用SELECT去查詢侦香，那么返回的數(shù)據(jù)應當是按照uploaded_date升序排列。對于時間相同的纽疟，會按照article_id升序排列鄙皇。如下面的圖片所示：
調整clustering column排序的順序
既然clustering column能夠確定某一個partition內數(shù)據(jù)排列的順序，調整這個排列的順序在某些情況下可能會非常有用仰挣。調整這個排列的順序有兩種方法：
- 在SELECT執(zhí)行的時候指定順序
我們可以在使用SELECT進行查詢的時候使用ORDER BY指定返回的結果的排列順序伴逸。如下面的例子所示：
SELECT *
FROM user_articles
WHERE user_id = 12345
ORDER BY uploaded_date DESC;
這個例子指定返回的對應于user_id = 12345的文章根據(jù)發(fā)表的時間降序排序，也就是說新文章考前膘壶，就文章靠后错蝴。
- 指定當前表在存儲時候的默認排序順序
如果我們總是進行某一特定排列順序的數(shù)據(jù)查詢，我們可以在使用CREATE創(chuàng)建表的schema的時候就為其指定clustering column排列的默認順序颓芭，從而提高將來查詢的效率顷锰。這一操作可以通過CLUSTERING ORDER BY實現(xiàn)。如下面的例子所示：
CREATE TABLE user_articles (
user_id uuid,
uploaded_date timestamp,
article_id uuid,
title test,
abstract test,
PRIMARY KEY (user_id, uploaded_date, article_id)
) WITH CLUSTERING ORDER BY (uploaded_date DESC, article_id ASC);
插入數(shù)據(jù)后表格如下面的圖片所示：
在這種情況下亡问，根據(jù)uploaded_date進行降序排序的操作將會在數(shù)據(jù)插入時候就默認執(zhí)行官紫。我們可以看到這種提前根據(jù)將來使用需要進行提前優(yōu)化的操作有可能起到非常好的效果，尤其是對于時序數(shù)據(jù)來說州藕。比如如果我們想要查詢用戶最近發(fā)表的五篇文章束世，使用如下的語句就會非常高效地得到所需要的數(shù)據(jù)：
SELECT *
FROM user_articles
WHERE user_id = 12345
LIMIT 10;
總結
綜上所述，我們可以發(fā)現(xiàn)在Cassandra中primary key是非常重要的床玻。primary key不僅可以用來進行數(shù)據(jù)查詢毁涉，而且被用來確定數(shù)據(jù)存儲的結構。這一點在未來設計Cassandra的數(shù)據(jù)模型時候應當特別注意锈死，從而可以針對未來可能的使用情況提前進行一些優(yōu)化設計贫堰。
