Cassandra Lekérdezőnyelv (CQL): Beszúrás, frissítés és törlés
⚡ Okos összefoglaló
Cassandra A lekérdezőnyelv (Query Language) az SQL-hez közeli szintaxissal, de eltérő szemantikájú alapon kezeli a beszúrás, frissítés, törlés és olvasás műveleteket. Ez az oldal bemutatja az egyes utasításokat, az insert és update műveleteket egyesítő upsert viselkedést, valamint a WHERE záradék valódi korlátait.

Adatok beillesztése
Az Cassandra insert utasítás adatokat ír be Cassandra oszlopok sor formában. Cassandra Az insert query csak a felhasználó által megadott oszlopokat tárolja. Szükségszerűen csak az elsődleges kulcs oszlopot kell megadnia.
Nem fog helyet foglalni a nem megadott értékeknek. A beillesztés után nem adunk vissza eredményeket.
Szintaxis
INSERT INTO KeyspaceName.TableName (ColumnName1, ColumnName2, ColumnName3) VALUES (Column1Value, Column2Value, Column3Value);
Példa
Íme a pillanatfelvétel a végrehajtottról Cassandra Beszúrás a táblalekérdezésbe, amelybe egy rekordot szúr be Cassandra táblázat „Diák”.
INSERT INTO University.Student (RollNo, Name, dept, Semester) VALUES (2, 'Michael', 'CS', 2);
A Beszúrás parancs sikeres végrehajtása után Cassandra, egy sor kerül beszúrásra a Cassandra táblázat Tanuló RollNo 2, Név Michael, Tanszék CS és Félév 2.
Itt látható az adatbázis aktuális állapotának pillanatképe.
Upsert Data
Cassandra felzaklatja. Az upsert azt jelenti Cassandra beszúr egy sort, ha az elsődleges kulcs még nem létezik, ellenkező esetben, ha az elsődleges kulcs már létezik, frissíti azt a sort.
Ennek van egy gyakorlati következménye, amit érdemes világosan megfogalmazni: egy INSERT soha nem jelent duplikált kulcs hibát, így egy véletlenszerű újbóli beszúrás figyelmeztetés nélkül felülírja a meglévő sort. Amikor ezt meg kell akadályozni, fűzzük hozzá az IF NOT EXISTS függeléket, hogy az utasítás könnyűsúlyú tranzakcióvá váljon.
INSERT INTO University.Student (RollNo, Name) VALUES (2, 'Michael') IF NOT EXISTS;
A könnyűsúlyú tranzakciók konszenzusos kört használnak a replikák között, így lényegesen lassabbak, mint egy normál írás, és azokat az eseteket kell figyelembe venni, amelyekben valóban szükség van az ellenőrzésre.
Adatok frissítése
Az Cassandra A frissítési lekérdezés az adatok frissítésére szolgál Cassandra táblázat. Ha az adatok frissítése után nem adnak vissza eredményeket, az azt jelenti, hogy az adatok frissítése sikeresen megtörtént, ellenkező esetben hibaüzenet jelenik meg. Az oszlopértékek a „Set” záradékban módosulnak, míg az adatok szűrése a „Where” záradékkal történik.
Szintaxis
UPDATE KeyspaceName.TableName SET ColumnName1 = NewValue1, ColumnName2 = NewValue2 WHERE ColumnName = ColumnValue;
Példa
Itt látható a képernyőkép, amely az adatbázis állapotát mutatja az adatok frissítése előtt.
Íme a pillanatfelvétel a végrehajtottról Cassandra Frissítés parancs, amely frissíti a rekordot a tanulói táblában.
UPDATE University.Student SET name = 'Hayden' WHERE rollno = 1;
A frissítési lekérdezés sikeres végrehajtása után Cassandra „Update Student”, a tanuló neve „Clark”-ról „Hayden”-re változik, amelynek rollno 1.
Itt van a képernyőkép, amely az adatbázis állapotát mutatja az adatok frissítése után.
Az upsert viselkedés miatt egy nem létező elsődleges kulcsra vonatkozó UPDATE parancs létrehozza a sort a sikertelenség helyett.
Cassandra Adatok törlése
A „Törlés” parancs egy teljes sort vagy néhány oszlopot eltávolít a táblázatból. Az adatok törlésekor nem törlődnek azonnal a táblázatból. Ehelyett a törölt adatokat sírkővel jelölik, és tömörítés után eltávolítják.
Szintaxis
DELETE FROM KeyspaceName.TableName WHERE ColumnName1 = ColumnValue;
A fenti Cassandra sor törlése szintaxis törl egy vagy több sort az adatszűréstől függően a where záradékban.
DELETE ColumnName1, ColumnName2 FROM KeyspaceName.TableName WHERE ColumnName1 = ColumnValue;
A fenti szintaxis töröl néhány oszlopot a táblázatból.
Példa
Itt látható a pillanatkép, amely az adatbázis aktuális állapotát mutatja az adatok törlése előtt.
Itt látható annak a parancsnak a pillanatképe, amely eltávolít egy sort a Diák táblázatból.
DELETE FROM University.Student WHERE rollno = 1;
A CQL Delete parancs sikeres végrehajtása után egy sor törlődik a Student táblából, ahol a rollno értéke 1.
Itt látható a pillanatkép, amely az adatbázis állapotát mutatja az adatok törlése után.
A sírkövek a gc_grace_seconds ideig, alapértelmezés szerint tíz napig maradnak életben, így a törlés során offline állapotban lévő csomópont nem tudja visszaállítani a sort, amikor visszatér. Nagy kötetek törlése esetén ezért olyan jelölők maradnak, amelyeken minden további olvasáshoz el kell haladnia.
Mit Cassandra nem támogatja
A CQL kölcsönzi az SQL szintaxist, de nem a relációs végrehajtási modellt, így számos ismerős konstrukció másképp viselkedik vagy hiányzik.
- A CQL nem támogatja a táblák közötti illesztéseket. A kapcsolódó adatokat írás közben denormalizálni kell, és egyetlen táblába kell foglalni.
- A CQL nem támogatja az OR feltételeket a WHERE záradékban. Használjon IN feltételeket egyetlen oszlopon, vagy futtasson külön lekérdezéseket.
- A CQL nem támogatja az UNION és az INTERSECT műveleteket.
- A nem elsődleges kulcsú oszlopok nem szűrhetők, amíg nem létezik index rajtuk.
- A nagyobb, mint és kisebb, mint összehasonlítások csak a fürtözési oszlopokra vonatkoznak, mivel csak ezek vannak rendezve a lemezen.
- A LIKE függvény segítségével végzett mintaillesztés SASI indexet igényel, és nem érhető el a hagyományos oszlopokon.
Egy régóta fennálló állítást kell helyesbíteni. Az aggregált függvények támogatottak: DARAB, MIN, MAX, SZUM és AVG megérkezett Cassandra 2.2, és CSOPORTOSÍT 3.10-ben érkezett meg. A kikötés inkább a hatókörre, mint az elérhetőségre vonatkozik.
SELECT dept, COUNT(*) FROM University.Student WHERE RollNo = 1 GROUP BY dept;
A fentiekhez hasonlóan egyetlen partícióra korlátozva az aggregátum hatékony. Ha az egész táblán futtatjuk, akkor fürtszintű vizsgálatot kapunk, ezért Cassandra továbbra sem alkalmas eseti elemzésekre, és miért van az, hogy a nagy mennyiségű jelentést általában erre a célra kell áthelyezni Spark vagy külső raktár.
Cassandra Ahol a záradék
In Cassandra, az adatok visszakeresése érzékeny kérdés. Az oszlopot beszűrjük Cassandra index létrehozásával a nem elsődleges kulcs oszlopokon.
Szintaxis
SELECT ColumnNames FROM KeyspaceName.TableName WHERE ColumnName1 = Column1Value AND ColumnName2 = Column2Value;
Példa
- Itt látható az a pillanatkép, amely az adatlekérést mutatja a tanulói táblából adatszűrés nélkül.
SELECT * FROM University.Student;
A rendszer két rekordot kér le a tanulói táblából.
- Itt látható a pillanatkép, amely az adatlekérést mutatja a tanulóból adatszűréssel. Egy rekordot lekérnek.
Az adatokat név oszlop szerint szűrjük. Az összes olyan rekordot lekérjük, amelynek neve egyenlő a következővel: Guru99.
SELECT * FROM University.Student WHERE name = 'Guru99';
A WHERE záradék oszlopaira vonatkozó szabályok közvetlenül az elsődleges kulcsból következnek.
- Az partíciós kulcs teljes egészében meg kell adni minden hatékony lekérdezéshez, mivel ez azonosítja az adatokat tároló csomópontot.
- Clusteroszlopok ezután korlátozhatók, de csak a bejelentésük sorrendjében.ping az egyiket elutasítják.
- A tartomány-összehasonlítások az utolsó hivatkozott fürtözési oszlopon engedélyezettek, a korábbiakon nem.
- Bármilyen másik oszlop másodlagos indexre van szüksége, amelyet a index létrehozása és törlése tutorial.
Amikor egy lekérdezést elutasítanak, Cassandra gyakran javasolja az ALLOW FILTERING hozzáfűzését. Ezt inkább figyelmeztetésnek, mint javításnak tekintse: minden partíciót átvizsgál minden csomóponton, és a séma módosítása szinte mindig a helyes válasz.










