Cassandra Query Language (CQL): Sett inn, oppdater og slett

Sett inn data

Ocuco Cassandra insert statement skriver data inn Cassandra kolonner i radform. Cassandra insert query vil lagre bare de kolonnene som er gitt av brukeren. Du må nødvendigvis spesifisere bare primærnøkkelkolonnen.

Det vil ikke ta plass for ikke gitte verdier. Ingen resultater returneres etter innsetting.

syntax

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

Eksempel

Her er øyeblikksbildet av de henrettede Cassandra Sett inn i tabellspørring som vil sette inn én post Cassandra tabellen 'Student'.

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

Etter vellykket utførelse av kommandoen Sett inn i Cassandra, vil én rad settes inn i Cassandra tabell Student med RollNo 2, Navn Michael, avd CS og Semester 2.

Her er øyeblikksbildet av gjeldende databasetilstand.

Upsert Data

Cassandra opprører. Upsert betyr det Cassandra vil sette inn en rad hvis en primærnøkkel ikke allerede eksisterer, ellers hvis primærnøkkelen allerede eksisterer, vil den oppdatere den raden.

Dette har en praktisk konsekvens som er verdt å si tydelig: en INSERT rapporterer aldri en duplikatnøkkelfeil, så en utilsiktet ny innsetting overskriver den eksisterende raden uten forvarsel. Når dette må forhindres, legg til IF NOT EXISTS for å gjøre setningen til en lettvektstransaksjon.

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

Lette transaksjoner bruker en konsensusrunde på tvers av replikaer, så de er betydelig tregere enn en vanlig skriving og bør reserveres for tilfeller som virkelig trenger sjekken.

Oppdater data

Ocuco Cassandra Oppdateringsspørring brukes til å oppdatere dataene i Cassandra bord. Hvis ingen resultater returneres etter oppdatering av data, betyr det at data er vellykket oppdatert, ellers vil en feil returneres. Kolonneverdier endres i 'Set'-leddet mens data filtreres med 'Where'-leddet.

syntax

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

Eksempel

Her er skjermbildet som viser databasetilstanden før du oppdaterer data.

Her er øyeblikksbildet av de henrettede Cassandra Oppdateringskommando som oppdaterer posten i elevtabellen.

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

Etter vellykket utførelse av oppdateringsspørringen i Cassandra 'Oppdater student', studentnavn vil bli endret fra 'Clark' til 'Hayden' som har rollno 1.

Her er skjermbildet som viser databasetilstanden etter oppdatering av data.

På grunn av upsert-oppførsel oppretter en UPDATE mot en primærnøkkel som ikke finnes raden i stedet for å mislykkes.

Cassandra Slett data

Kommandoen 'Slett' fjerner en hel rad eller noen kolonner fra tabellen Student. Når data slettes, slettes de ikke umiddelbart fra tabellen. I stedet merkes slettede data med en gravstein og fjernes etter komprimering.

syntax

DELETE FROM KeyspaceName.TableName
WHERE ColumnName1 = ColumnValue;

Ovennevnte Cassandra slette radsyntaks vil slette én eller flere rader avhengig av datafiltrering i where-klausulen.

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

Syntaksen ovenfor vil slette noen kolonner fra tabellen.

Eksempel

Her er øyeblikksbildet som viser gjeldende databasestatus før du sletter data.

Her er øyeblikksbildet av kommandoen som vil fjerne én rad fra tabellen Student.

DELETE FROM University.Student WHERE rollno = 1;

Etter vellykket utførelse av CQL Delete-kommandoen, vil én rad bli slettet fra tabellen Student der rollno-verdien er 1.

Her er øyeblikksbildet som viser databasetilstanden etter sletting av data.

Gravsteiner overlever i gc_grace_seconds, ti dager som standard, slik at en node som er offline under slettingen ikke kan gjenopplive raden når den returnerer. Sletting av store volumer etterlater derfor markører som hver påfølgende lesning må skanne forbi.

Hva Cassandra støtter ikke

CQL låner SQL-syntaks, men ikke den relasjonelle utførelsesmodellen, så flere kjente konstruksjoner oppfører seg annerledes eller er fraværende.

1. CQL støtter ikke koblinger mellom tabeller. Relaterte data må denormaliseres til én tabell ved skriving.
2. CQL støtter ikke OR-betingelser i en WHERE-klausul. Bruk IN på én kolonne, eller kjør separate spørringer.
3. CQL støtter ikke UNION eller INTERSECT.
4. Kolonner som ikke er primærnøkkelkolonner kan ikke filtreres før det finnes en indeks på dem.
5. Sammenligninger av større enn og mindre enn gjelder bare for klyngekolonner, fordi bare de sorteres på disken.
6. Mønstersamsvar med LIKE krever en SASI-indeks og er ikke tilgjengelig på vanlige kolonner.

Én langvarig påstand må korrigeres. Aggregerte funksjoner støttes: ANTALL, MIN, MAKS, SUM og AVG ankom i Cassandra 2.2, og GRUPPE AV kom i 3.10. Forbeholdet er omfang snarere enn tilgjengelighet.

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

Begrenset til en enkelt partisjon som ovenfor, er et aggregat effektivt. Kjøres det over hele tabellen, blir det en klyngeomfattende skanning, og det er derfor Cassandra fortsatt uegnet for ad hoc-analyse, og hvorfor tung rapportering vanligvis presses til Spark eller et eksternt lager.

Cassandra Hvor klausul

In Cassandra, er datainnhenting et sensitivt problem. Kolonnen filtreres inn Cassandra ved å lage en indeks på ikke-primære nøkkelkolonner.

syntax

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

Eksempel

• Her er øyeblikksbildet som viser datahentingen fra Studenttabellen uten datafiltrering.

SELECT * FROM University.Student;

To poster hentes fra Studenttabell.

• Her er øyeblikksbildet som viser datahentingen fra Student med datafiltrering. Én post hentes.

Data filtreres etter navnekolonne. Alle poster som har navn lik Guru99.

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

Reglene som styrer hvilke kolonner en WHERE-klausul kan referere til, følger direkte fra primærnøkkelen.

• Ocuco partisjonsnøkkel må oppgis i sin helhet for enhver effektiv spørring, fordi den identifiserer noden som inneholder dataene.
• Clusterkolonner kan da begrenses, men bare i den rekkefølgen de ble erklært. Hopp overping én blir avvist.
• Rekkeviddesammenligninger er tillatt på den siste klyngekolonnen det refereres til, ikke på tidligere.
• Noen annen kolonne trenger en sekundærindeks, dekket i opprette og slette indeks opplæringen.

Når en forespørsel blir avvist, Cassandra foreslår ofte å legge til ALLOW FILTERING. Betrakt det som en advarsel snarere enn en løsning: den skanner hver partisjon på hver node, og en skjemaendring er nesten alltid den riktige responsen.

Spørsmål og svar