私は以下のkey
型の違いを理解するためにネット上の記事を読んでいます。しかし、私が把握するのは難しいようです。例は間違いなく理解を深めるのに役立ちます。
primary key,
partition key,
composite key
clustering key
受け入れられたものとしてredux答えを追加することはかなり長いです。 「行」と「列」という用語は、Cassandraが実際にどのように実装されているかではなく、CQLの文脈で使用されています。
例:
PRIMARY KEY (a)
:パーティションキーはa
です。PRIMARY KEY (a, b)
:パーティションキーはa
、クラスタリングキーはb
です。PRIMARY KEY ((a, b))
:複合パーティションキーは(a, b)
です。PRIMARY KEY (a, b, c)
:パーティションキーはa
、複合クラスタリングキーは(b, c)
です。PRIMARY KEY ((a, b), c)
:コンポジットパーティションキーは(a, b)
、クラスタリングキーはc
です。PRIMARY KEY ((a, b), c, d)
:複合パーティションキーは(a, b)
、複合クラスタリングキーは(c, d)
です。Cassandraでは、主キー、パーティションキー、コンポジットキー、クラスタリングキーの違いが常に混乱を招きます。したがって、以下で説明し、相互に関連します。 CassandraデータベースへのアクセスにはCQL(Cassandra Query Language)を使用します。注: - 答えはCassandraの最新版によるものです。 主キー: -
CREATE TABLE Cass (
id int PRIMARY KEY,
name text
);
Create Table Cass (
id int,
name text,
PRIMARY KEY(id)
);
CQLでは、PRIMARY KEYに対して列が定義される順序が重要です。キーの最初の列は、パーティションキーと呼ばれ、同じパーティションキーを共有するすべての行が(実際にはテーブル全体であっても)同じ物理ノードに格納されるというプロパティを持ちます。また、特定の表に対して同じパーティションキーを共有する行の挿入/更新/削除は、アトミックに、そして個別に実行されます。どの列がパーティションキーを形成するかを定義するために追加の括弧のセットを使用して、複合パーティションキー、すなわち複数の列から形成されるパーティションキーを有することが可能であることに留意されたい。
分割とクラスタ化 PRIMARY KEYの定義は、分割キーとクラスタ化列の2つの部分で構成されています。最初の部分はストレージエンジンの行キーにマッピングされ、2番目の部分は行内の列をグループ化するために使用されます。
CREATE TABLE device_check (
device_id int,
checked_at timestamp,
is_power boolean,
is_locked boolean,
PRIMARY KEY (device_id, checked_at)
);
ここで、device_idはパーティションキー、checked_atはcluster_keyです。
宣言に依存するパーティションキーだけでなく、複数のクラスタキーを持つこともできます。
主キー :パーティションキー(およびオプションのクラスタリングキー(または列))で構成されます。
Partition Key :パーティションキーのハッシュ値は、データを格納するクラスタ内の特定のノードを決定するために使用されます。
クラスタリングキー :各パーティション(または責任ノードとそのレプリカ)内のデータをソートするために使用されます。
複合主キー :前述のように、クラスタリングキーは主キーではオプションです。言及されていない場合は、単純な主キーです。クラスタリングキーが言及されている場合、それは複合主キーです。
コンポジットパーティションキー :パーティションキーとして1列だけを使用すると、 行全体に問題が生じる可能性があります (ユースケース/データモデリングによって異なります)。したがって、パーティションキーは複数の列の組み合わせとして指定されることがあります。
どれが必須であるかの混乱について 、クエリでスキップできるものなど、 Cassandraを巨大なHashMap として想像してみると役立ちます。そのため、HashMapでは、Keyなしで値を取得することはできません。
ここで、 パーティションキー はそのキーの役割を果たします。そのため、各クエリにはそれらを指定する必要があります。どのCassandraがないと検索するノードがわかりません。
[ - 。] クラスタリングキー (カラム、オプション)は、Cassandraがその特定の パーティションキー を担当する特定のノード(およびそのレプリカ)を見つけた後、クエリ検索をさらに絞り込むのに役立ちます。
簡単に言うと:
パーティションキー は行に対して - 識別 /その識別はほとんどの場合単一列( 主キー と呼ばれる)時には複数の列の組み合わせ( 複合パーティションキーと呼ばれる) )。
クラスタキー は単なる 索引付け & 並べ替え です。クラスタキーはいくつかのことに依存します。
主キー列を除くwhere句で使用する列.
あなたが非常に大きな記録を持っているならば、どんな懸念に関して私は管理を容易にするために日付を分けることができます。例として、100万人/郡の人口記録のデータがあります。そのため、管理を容易にするために、状態に基づいて、そしてPINコードに基づいてデータをクラスタ化します。
注目に値するのは、リレーショナルの世界(複合キー)での同様の概念よりもこれらの多くを使用することでしょう。
例-最近ユーザーグループXに参加した最後のN人のユーザーを見つける必要があるとします。この場合、読み取りが優勢であるため、これを効率的に行うにはどうすればよいでしょうか。そのように(公式 Cassandraガイド から):
CREATE TABLE group_join_dates (
groupname text,
joined timeuuid,
join_date text,
username text,
email text,
age int,
PRIMARY KEY ((groupname, join_date), joined)
) WITH CLUSTERING ORDER BY (joined DESC)
ここで、パーティショニングキーは複合自体であり、クラスタリングキーは結合されています日付。 クラスタリングキーが結合日である理由は、結果がすでにソートされているためです(および保存され、検索が高速になります)。しかし、パーティションキーに複合キーを使用するのはなぜですか? できる限り少ないパーティションを常に読み取りたいためです。そこにjoin_dateを入れるとどのように役立ちますか?これで、同じグループの同じ日付のユーザーが単一のパーティションに常駐するようになります!これは、可能な限り少ないパーティションを読み込むことを意味します(最初から最新のパーティションにジャンプしてから、古いパーティションに移動するのではなく、古いパーティションに移動するなど)。
実際、極端な場合には、join_dateだけでなくjoin_dateのハッシュも使用する必要があります。過去3日間のクエリを実行すると、多くの場合、同じハッシュを共有するため、同じパーティションから使用できます。
Cassandraの主キーは通常、パーティションキーとクラスタリング列の2つの部分で構成されています。
primary_key((partition_key)、clustering_col)
パーティションキー - 主キーの最初の部分。パーティションキーの主な目的は、特定の行を格納するノードを識別することです。
CREATE TABLE phone_book(phone_num int、名前テキスト、age int、都市テキスト、PRIMARY KEY((phone_num、name)、age);
ここで、(phone_num、name)はパーティションキーです。データの挿入中にパーティションキーのハッシュ値が生成され、この値によって行をどのノードに入れるべきかが決定されます。
4ノードのクラスタを考えます。各ノードには、格納できるハッシュ値の範囲があります。 (書き込み)phone_book VALUES(7826573732、「Joey」、25、「New York」)に挿入します。
さて、パーティションキーのハッシュ値はCassandraパーティショナによって計算されます。たとえば、ハッシュ値(7826573732、「Joey」)→12、この行はノードCに挿入されます。
(読む)SELECT * FROM phone_book WHERE phone_num = 7826573732およびname =「Joey」。
ここでもパーティションキーのハッシュ値(7826573732、 'Joey')が計算されます。これは、この例では12で、そこから読み取りが行われます。
解決しているクエリによっては、主キーに複数のパーティションキーとクラスタ化列がある場合があります。
primary_key((pk1、pk2)、col 1、col 2)