Ho letto articoli in rete per capire le differenze tra i seguenti key
tipi. Ma mi sembra difficile da capire. Gli esempi aiuteranno sicuramente a migliorare la comprensione.
primary key,
partition key,
composite key
clustering key
Ho letto articoli in rete per capire le differenze tra i seguenti key
tipi. Ma mi sembra difficile da capire. Gli esempi aiuteranno sicuramente a migliorare la comprensione.
primary key,
partition key,
composite key
clustering key
Risposte:
C'è molta confusione in questo, cercherò di renderlo il più semplice possibile.
La chiave primaria è un concetto generale per indicare una o più colonne utilizzate per recuperare i dati da una tabella.
La chiave primaria può essere SEMPLICE e persino dichiarata in linea:
create table stackoverflow_simple (
key text PRIMARY KEY,
data text
);
Ciò significa che è composto da una singola colonna.
Ma la chiave primaria può anche essere COMPOSITO (aka COMPOUND ), generato da più colonne.
create table stackoverflow_composite (
key_part_one text,
key_part_two int,
data text,
PRIMARY KEY(key_part_one, key_part_two)
);
In una situazione di chiave primaria COMPOSITA , la "prima parte" della chiave si chiama PARTITION KEY (in questo esempio key_part_one è la chiave di partizione) e la seconda parte della chiave è la CLUSTERING KEY (in questo esempio key_part_two )
Si noti che sia la chiave di partizione che quella di clustering possono essere create da più colonne , ecco come:
create table stackoverflow_multiple (
k_part_one text,
k_part_two int,
k_clust_one text,
k_clust_two int,
k_clust_three uuid,
data text,
PRIMARY KEY((k_part_one, k_part_two), k_clust_one, k_clust_two, k_clust_three)
);
Dietro questi nomi ...
Ulteriori informazioni sull'uso: DOCUMENTAZIONE DATASTAX
insert into stackoverflow_simple (key, data) VALUES ('han', 'solo');
select * from stackoverflow_simple where key='han';
contenuto della tabella
key | data
----+------
han | solo
COMPOSITE / COMPOUND KEY è in grado di recuperare "righe larghe" (ovvero è possibile eseguire una query solo con la chiave di partizione, anche se sono state definite chiavi di clustering)
insert into stackoverflow_composite (key_part_one, key_part_two, data) VALUES ('ronaldo', 9, 'football player');
insert into stackoverflow_composite (key_part_one, key_part_two, data) VALUES ('ronaldo', 10, 'ex-football player');
select * from stackoverflow_composite where key_part_one = 'ronaldo';
contenuto della tabella
key_part_one | key_part_two | data
--------------+--------------+--------------------
ronaldo | 9 | football player
ronaldo | 10 | ex-football player
Ma puoi eseguire query con tutte le chiavi (sia partizioni che clustering) ...
select * from stackoverflow_composite
where key_part_one = 'ronaldo' and key_part_two = 10;
output della query
key_part_one | key_part_two | data
--------------+--------------+--------------------
ronaldo | 10 | ex-football player
Nota importante: la chiave di partizione è l'identificatore minimo necessario per eseguire una query utilizzando a where clause
. Se si dispone di una chiave di partizione composita, come il seguente
per esempio: PRIMARY KEY((col1, col2), col10, col4))
È possibile eseguire la query solo passando almeno col1 e col2, queste sono le 2 colonne che definiscono la chiave di partizione. La regola "generale" per eseguire una query è che devi passare almeno tutte le colonne della chiave di partizione, quindi puoi aggiungere facoltativamente ogni chiave di cluster nell'ordine in cui sono impostate.
quindi le query valide sono ( esclusi gli indici secondari )
Non valido:
Spero che sia di aiuto.
L'aggiunta di una risposta di riepilogo come quella accettata è piuttosto lunga. I termini "riga" e "colonna" sono utilizzati nel contesto di CQL, non in che modo Cassandra è effettivamente implementato.
Esempi:
PRIMARY KEY (a)
: La chiave di partizione è a
.PRIMARY KEY (a, b)
: La chiave di partizione è a
, la chiave di clustering è b
.PRIMARY KEY ((a, b))
: La chiave di partizione composita è (a, b)
.PRIMARY KEY (a, b, c)
: La chiave di partizione è a
, la chiave di clustering composito è (b, c)
.PRIMARY KEY ((a, b), c)
: La chiave di partizione composita è (a, b)
, la chiave di clustering è c
.PRIMARY KEY ((a, b), c, d)
: La chiave di partizione composita è (a, b)
, la chiave di clustering composita è (c, d)
.In cassandra, la differenza tra chiave primaria, chiave di partizione, chiave composita, chiave di clustering crea sempre un po 'di confusione. Quindi spiegherò di seguito e mi relazionerò l'una con l'altra. Utilizziamo CQL (Cassandra Query Language) per l'accesso al database Cassandra. Nota: - La risposta è come per la versione aggiornata di Cassandra. Chiave primaria :-
CREATE TABLE Cass (
id int PRIMARY KEY,
name text
);
Create Table Cass (
id int,
name text,
PRIMARY KEY(id)
);
In CQL, l'ordine in cui sono definite le colonne per PRIMARY KEY è importante. La prima colonna della chiave è chiamata chiave di partizione con proprietà che tutte le righe che condividono la stessa chiave di partizione (anche attraverso la tabella) sono memorizzate sullo stesso nodo fisico. Inoltre, l'inserimento / aggiornamento / eliminazione su righe che condividono la stessa chiave di partizione per una determinata tabella vengono eseguiti in modo atomico e isolato. Si noti che è possibile avere una chiave di partizione composita, ovvero una chiave di partizione formata da più colonne, utilizzando un set aggiuntivo di parentesi per definire quali colonne formano la chiave di partizione.
Partizionamento e cluster La definizione di PRIMARY KEY è composta da due parti: la chiave di partizione e le colonne di cluster. La prima parte è mappata alla chiave di riga del motore di archiviazione, mentre la seconda viene utilizzata per raggruppare le colonne in una riga.
CREATE TABLE device_check (
device_id int,
checked_at timestamp,
is_power boolean,
is_locked boolean,
PRIMARY KEY (device_id, checked_at)
);
Qui device_id è la chiave di partizione e checked_at è cluster_key.
Possiamo avere anche più chiavi cluster e anche chiavi di partizione che dipendono dalla dichiarazione.
Chiave primaria : è composta da chiavi di partizione [e chiavi di cluster (o colonne) opzionali]
Chiave di partizione : il valore hash della chiave di partizione viene utilizzato per determinare il nodo specifico in un cluster per memorizzare i dati
Chiave di cluster : viene utilizzata per ordina i dati in ciascuna delle partizioni (o nodo responsabile e relative repliche)
Chiave primaria composta : come detto sopra, le chiavi di clustering sono opzionali in una chiave primaria. Se non sono menzionati, è una chiave primaria semplice. Se vengono menzionate le chiavi di clustering, si tratta di una chiave primaria composta.
Chiave di partizione composita : l'utilizzo di una sola colonna come chiave di partizione può causare problemi di riga ampia (dipende dalla modellazione di casi / dati di utilizzo). Quindi la chiave di partizione viene talvolta specificata come una combinazione di più di una colonna.
Per quanto riguarda la confusione di quale sia obbligatorio , quale può essere saltato ecc. In una query, provare a immaginare Cassandra come una gigantesca HashMap aiuta. Quindi in una HashMap, non è possibile recuperare i valori senza la chiave.
Qui, i tasti di partizione svolgono il ruolo di quel tasto. Quindi ogni query deve averli specificati. Senza quale Cassandra non saprà quale nodo cercare.
Le chiavi di clustering (colonne, che sono facoltative) aiutano a restringere ulteriormente la ricerca della query dopo che Cassandra ha scoperto il nodo specifico (e le sue repliche) responsabile di quella specifica chiave di partizione .
In breve senso:
La chiave di partizione non è altro che l' identificazione per una riga, che l'identificazione il più delle volte è la singola colonna (chiamata chiave primaria ) a volte una combinazione di più colonne (chiamata chiave di partizione composita ).
La chiave cluster non è altro che indicizzazione e ordinamento . Le chiavi del cluster dipendono da alcune cose:
Quali colonne utilizzate nella clausola where, tranne le colonne chiave primaria.
Se hai record molto grandi, per quanto riguarda la preoccupazione posso dividere la data per una facile gestione. Esempio, ho dati di 1 milione di record di popolazione di una contea. Quindi per una facile gestione, raggruppo i dati in base allo stato e dopo il codice PIN e così via.
Vale la pena notare che probabilmente userete questi lotti più che in concetti simili nel mondo relazionale (chiavi composte).
Esempio: supponiamo che tu debba trovare gli ultimi N utenti che si sono uniti recentemente al gruppo di utenti X. Come faresti in questo modo, dato che le letture in modo efficiente sono predominanti in questo caso? Così (dalla guida ufficiale di 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)
Qui, la chiave di partizionamento è composta da sé e la chiave di clustering è una data unita. Il motivo per cui una chiave di clustering è una data di iscrizione è che i risultati sono già ordinati (e archiviati, il che rende veloci le ricerche). Ma perché utilizziamo una chiave composta per la chiave di partizionamento ? Perché vogliamo sempre leggere il minor numero possibile di partizioni . Come può essere utile inserire join_date ? Ora gli utenti dello stesso gruppo e della stessa data di iscrizione risiederanno in un'unica partizione! Ciò significa che leggeremo sempre il minor numero possibile di partizioni (prima inizia con il più recente, quindi passa a quello più vecchio e così via, anziché saltare tra di loro).
In effetti, in casi estremi dovresti anche usare l'hash di un join_date piuttosto che un join_date da solo - in modo che se esegui una query per gli ultimi 3 giorni spesso condividano lo stesso hash e quindi siano disponibili dalla stessa partizione!
La chiave primaria in Cassandra di solito è composta da due parti: chiave di partizione e colonne di raggruppamento.
primary_key ((partition_key), clustering_col)
Chiave di partizione: la prima parte della chiave primaria. Lo scopo principale di una chiave di partizione è identificare il nodo che memorizza la riga specifica.
CREATE TABLE phone_book (phone_num int, nome testo, età int, testo città, PRIMARY KEY ((phone_num, nome), età);
Qui, (phone_num, name) è la chiave di partizione. Durante l'inserimento dei dati, viene generato il valore hash della chiave di partizione e questo valore decide in quale nodo deve andare la riga.
Considerare un cluster a 4 nodi, ogni nodo ha un intervallo di valori hash che può memorizzare. (Scrivi) INSERT INTO phone_book VALUES (7826573732, 'Joey', 25, 'New York');
Ora, il valore hash della chiave di partizione viene calcolato dal partizionatore Cassandra. diciamo, valore hash (7826573732, 'Joey') → 12, ora questa riga verrà inserita nel nodo C.
(Leggi) SELEZIONA * DA phone_book DOVE phone_num = 7826573732 e name = 'Joey';
Ora, di nuovo viene calcolato il valore hash della chiave di partizione (7826573732, 'Joey'), che nel nostro caso è 12 che risiede nel nodo C, da cui viene eseguita la lettura.
In una chiave primaria possono essere presenti più chiavi di partizione e colonne di clustering in base alla query che si sta risolvendo.
primary_key ((pk1, pk2), col 1, col2)
Nella progettazione del database, una chiave composta è un insieme di superkey che non è minimo.
Una chiave composita è un set che contiene una chiave composta e almeno un attributo che non è una superkey
Data tabella: DIPENDENTI {employee_id, nome, cognome}
Le possibili superkey sono:
{employee_id}
{employee_id, firstname}
{employee_id, firstname, surname}
{employee_id} è l'unico superkey minimo, che lo rende anche l'unica chiave candidata, dato che {firstname} e {surname} non garantiscono l'univocità. Poiché una chiave primaria è definita come chiave candidata scelta e in questo esempio esiste solo una chiave candidata, {employee_id} è la superkey minima, l'unica chiave candidata e l'unica chiave primaria possibile.
L'elenco completo delle chiavi composte è:
{employee_id, firstname}
{employee_id, surname}
{employee_id, firstname, surname}
L'unica chiave composita è {employee_id, nome, cognome} poiché quella chiave contiene una chiave composta ({employee_id, nome}) e un attributo che non è un superkey ({cognome}).