Cassandra Forespørgselssprog (CQL): Indsæt, opdater og slet

Indsæt data

Cassandra insert statement skriver data ind Cassandra kolonner i rækkeform. Cassandra indsæt forespørgsel gemmer kun de kolonner, som er givet af brugeren. Du skal nødvendigvis kun angive den primære nøglekolonne.

Det vil ikke tage plads til ikke-givne værdier. Ingen resultater returneres efter indsættelse.

Syntaks

INSERT INTO KeyspaceName.TableName (ColumnName1, ColumnName2, ColumnName3)
VALUES (Column1Value, Column2Value, Column3Value);

Eksempel

Her er et øjebliksbillede af de henrettede Cassandra Indsæt i tabelforespørgsel, der vil indsætte én post i Cassandra tabel 'Student'.

INSERT INTO University.Student (RollNo, Name, dept, Semester)
VALUES (2, 'Michael', 'CS', 2);

Efter vellykket udførelse af kommandoen Indsæt i Cassandra, vil der blive indsat en række i Cassandra tabel Elev med RollNo 2, Navn Michael, afd. CS og Semester 2.

Her er et øjebliksbillede af den aktuelle databasetilstand.

Upsert Data

Cassandra gør oprør. Upsert betyder det Cassandra vil indsætte en række, hvis en primærnøgle ikke allerede eksisterer, ellers hvis primærnøgle allerede findes, vil den opdatere denne række.

Dette har en praktisk konsekvens, der er værd at sige klart: en INSERT rapporterer aldrig en fejl i duplikatnøgler, så en utilsigtet genindsættelse overskriver den eksisterende række uden varsel. Når dette skal forhindres, tilføjes IF NOT EXISTS for at gøre sætningen til en letvægtstransaktion.

INSERT INTO University.Student (RollNo, Name)
VALUES (2, 'Michael') IF NOT EXISTS;

Letvægtstransaktioner bruger en konsensusrunde på tværs af replikaer, så de er betydeligt langsommere end en normal skrivning og bør reserveres til sager, der virkelig har brug for kontrollen.

Opdater data

Cassandra Opdateringsforespørgsel bruges til at opdatere dataene i Cassandra bord. Hvis der ikke returneres resultater efter opdatering af data, betyder det, at data er opdateret med succes, ellers vil der blive returneret en fejl. Kolonneværdier ændres i 'Set'-klausulen, mens data filtreres med 'Where'-klausulen.

Syntaks

UPDATE KeyspaceName.TableName
SET ColumnName1 = NewValue1,
    ColumnName2 = NewValue2
WHERE ColumnName = ColumnValue;

Eksempel

Her er skærmbilledet, der viser databasetilstanden før opdatering af data.

Her er et øjebliksbillede af de henrettede Cassandra Opdater kommando, der opdaterer posten i elevtabellen.

UPDATE University.Student
SET name = 'Hayden'
WHERE rollno = 1;

Efter vellykket udførelse af opdateringsforespørgslen i Cassandra 'Opdater elev', elevens navn vil blive ændret fra 'Clark' til 'Hayden', der har rollno 1.

Her er skærmbilledet, der viser databasetilstanden efter opdatering af data.

På grund af upsert-adfærd opretter en UPDATE mod en primærnøgle, der ikke findes, rækken i stedet for at fejle.

Cassandra Slet data

Kommandoen 'Slet' fjerner en hel række eller nogle kolonner fra tabellen Elev. Når data slettes, slettes de ikke fra tabellen med det samme. I stedet markeres slettede data med en gravsten og fjernes efter komprimering.

Syntaks

DELETE FROM KeyspaceName.TableName
WHERE ColumnName1 = ColumnValue;

Ovenstående Cassandra slet rækkesyntaks vil slette en eller flere rækker afhængig af datafiltrering i where-klausulen.

DELETE ColumnName1, ColumnName2 FROM KeyspaceName.TableName
WHERE ColumnName1 = ColumnValue;

Ovenstående syntaks vil slette nogle kolonner fra tabellen.

Eksempel

Her er det øjebliksbillede, der viser den aktuelle databasetilstand før sletning af data.

Her er et øjebliksbillede af kommandoen, der fjerner en række fra tabellen Student.

DELETE FROM University.Student WHERE rollno = 1;

Efter vellykket udførelse af CQL Delete-kommandoen slettes én række fra tabellen Student, hvor rollno-værdien er 1.

Her er det øjebliksbillede, der viser databasetilstanden efter sletning af data.

Gravstenene overlever i gc_grace_seconds, som standard er ti dage, så en node, der er offline under sletningen, ikke kan genoplive rækken, når den vender tilbage. Sletning af store mængder efterlader derfor markører, som hver efterfølgende læsning skal scanne forbi.

Hvad Cassandra understøtter ikke

CQL låner SQL-syntaks, men ikke den relationelle udførelsesmodel, så flere velkendte konstruktioner opfører sig anderledes eller er fraværende.

1. CQL understøtter ikke joins mellem tabeller. Relaterede data skal denormaliseres til én tabel på skrivetidspunktet.
2. CQL understøtter ikke OR-betingelser i en WHERE-klausul. Brug IN på en enkelt kolonne, eller kør separate forespørgsler.
3. CQL understøtter ikke UNION eller INTERSECT.
4. Ikke-primærnøglekolonner kan ikke filtreres, før der findes et indeks på dem.
5. Sammenligninger af større end og mindre end gælder kun for klyngekolonner, fordi kun disse sorteres på disken.
6. Mønstermatchning med LIKE kræver et SASI-indeks og er ikke tilgængelig på almindelige kolonner.

En langvarig påstand skal rettes. Aggregeringsfunktioner understøttes: ANTAL, MIN, MAKS, SUM og AVG ankom til Cassandra 2.2 og GROUP BY ankom i 3.10. Forbeholdet er omfang snarere end tilgængelighed.

SELECT dept, COUNT(*) FROM University.Student
WHERE RollNo = 1 GROUP BY dept;

Begrænset til en enkelt partition som ovenfor, er et aggregat effektivt. Hvis det køres på tværs af hele tabellen, bliver det en klyngeomfattende scanning, hvilket er grunden til Cassandra forbliver uegnet til ad hoc-analyser, og hvorfor tung rapportering normalt presses til Spark eller et eksternt lager.

Cassandra Hvor Klausul

In Cassandra, er datahentning et følsomt emne. Kolonnen filtreres ind Cassandra ved at oprette et indeks på ikke-primære nøglekolonner.

Syntaks

SELECT ColumnNames FROM KeyspaceName.TableName
WHERE ColumnName1 = Column1Value
  AND ColumnName2 = Column2Value;

Eksempel

• Her er et øjebliksbillede, der viser datahentningen fra Student-tabellen uden datafiltrering.

SELECT * FROM University.Student;

To poster hentes fra Elev-tabellen.

• Her er det øjebliksbillede, der viser datahentningen fra Student med datafiltrering. Én post hentes.

Data filtreres efter navnekolonne. Alle poster hentes, der har et navn lig med Guru99.

SELECT * FROM University.Student WHERE name = 'Guru99';

Reglerne for, hvilke kolonner en WHERE-klausul må referere til, følger direkte af primærnøglen.

• partitionsnøgle skal angives fuldt ud for enhver effektiv forespørgsel, fordi den identificerer den node, der indeholder dataene.
• Clusterkolonner kan derefter begrænses, men kun i den rækkefølge, de blev deklareret. Spring overping én bliver afvist.
• Områdesammenligninger er tilladt på den sidst refererede klyngekolonne, ikke på tidligere.
• Enhver anden kolonne har brug for et sekundært indeks, dækket af opret og fjern indeks tutorial.

Når en forespørgsel afvises, Cassandra foreslår ofte at tilføje ALLOW FILTERING. Betragt det som en advarsel snarere end en løsning: den scanner alle partitioner på alle noder, og en skemaændring er næsten altid den korrekte reaktion.

Ofte Stillede Spørgsmål