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.

  • Beszúrás viselkedése: Csak az elsődleges kulcs megadása kötelező, a kihagyott oszlopok nem foglalnak tárhelyet.
  • 🔄 Upsert szemantika: A beszúrás és a frissítés ugyanaz a művelet, így egy meglévő kulcs írása csendben felülírja azt.
  • 🗑️ Törlési költség: Az eltávolított sorok sírkövekké válnak, és csak a tömörítési futtatások után tűnnek el.
  • 🔍 Ahol a záradék korlátozza: A szűrés az elsődleges kulcs oszlopain, vagy más oszlopokon működik, ha egy index létezik.
  • 📊 Összesített támogatás: DARAB, MIN, MAX, SZUM, AVG és a GROUP BY támogatottak, bár csak egyetlen partíción belül hatékonyan.
  • ???? Még mindig nem támogatott: Az illesztések, a VAGY feltételek és a partíciók közötti elemzések tervezésükből adódóan a CQL-en kívül maradnak.

Cassandra CQL Beszúrás Frissítés Törlés

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”.

Adatok beillesztése

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.

Adatok beillesztése

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.

Adatok frissítése

Íme a pillanatfelvétel a végrehajtottról Cassandra Frissítés parancs, amely frissíti a rekordot a tanulói táblában.

Adatok frissítése

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.

Adatok frissítése

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.

Cassandra Adatok törlése

Itt látható annak a parancsnak a pillanatképe, amely eltávolít egy sort a Diák táblázatból.

Cassandra Adatok törlése

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.

Cassandra Adatok törlése

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.

  1. 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.
  2. 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.
  3. A CQL nem támogatja az UNION és az INTERSECT műveleteket.
  4. A nem elsődleges kulcsú oszlopok nem szűrhetők, amíg nem létezik index rajtuk.
  5. A nagyobb, mint és kisebb, mint összehasonlítások csak a fürtözési oszlopokra vonatkoznak, mivel csak ezek vannak rendezve a lemezen.
  6. 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.

Cassandra Ahol a záradék

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.

Cassandra Ahol a záradék

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.

GYIK

A batch utasításokat csoportosítja, így azok együttesen sikeresek vagy sikertelenek. A duplikált táblák lépésenkénti tárolására használjuk, ne tömeges betöltésre, ahol a sok partíción átívelő batch jelentősen lelassítja a koordinátort.

Az illesztőprogramok automatikusan lapoznak egy lapozó állapot token használatával. A cqlsh-ban a PAGING állítja be a méretet. Kerülje az OFFSET emulálását számlálóval, mert Cassandra nincs hatékony sorkihagyásaping mechanizmus.

Ha egy replika a gc_grace_seconds időtartamnál tovább nem működött, és a sírkövet már tömörítették, a replika továbbra is megtartja a régi sort, és visszahúzza azt. A rendszeres javítás ezt megakadályozza.

Az egyszerű, egytáblás kiválasztások jól konvertálnak. Bármi, ami illesztéssel, OR-ral vagy alkéréssel rendelkezik, nem rendelkezik közvetlen CQL-egyenértékkel, és a mesterséges intelligencia gyakran elfedi a rést az ALLOW FILTERING paranccsal, ami nem megoldás.

Igen. Beillesztés TRACAz ING ON kimenet általában tiszta leolvasást ad a sírkő-szkennelésekről, a széles partíciókról vagy a csomópontok közötti ugrásokról. Az alkalmazás előtt ellenőrizze a javasolt sémamódosítást egy másolaton.

Foglald össze ezt a bejegyzést a következőképpen: