Cassandra TTL & Cassandra CQL adattípusok (példa)
Szerkesztőség
⚡ Okos összefoglaló
Cassandra Az adattípusok határozzák meg, hogy az egyes oszlopok mit tartalmazhatnak, a TTL pedig azt szabályozza, hogy egy érték mennyi ideig marad életben, mielőtt automatikusan lejár. Ez az oldal felsorolja az összes CQL típust, elmagyarázza a lejárati mechanizmust, és ismerteti a lejáratot követő sírkő viselkedését.
Cassandra Adattípusok
Cassandra különböző típusú adattípusokat támogat. Itt található az adattípusokat, azok állandóit és leírását tartalmazó táblázat.
| CQL típus | állandók | Leírás |
|---|---|---|
| ascii | Strings | US-Ascii karakterlánc |
| bigint | Egész számok | 64 bites aláírt hosszú |
| folt | festékfoltok | Tetszőleges bájtok hexadecimális formában |
| logikai | Logikai adattípus | Igaz vagy hamis |
| ellen | Egész számok | Elosztott számláló értékek 64 bit |
| adat | Egész számok, karakterláncok | Naptári dátum időkomponens nélkül |
| decimális | Egész számok, úszók | Változó pontosságú decimális |
| kétszeresére | Egész számok, úszók | 64 bites lebegőpont |
| időtartama | Időtartam: | Hónapok, napok és nanoszekundumok időtartama |
| úszik | Egész számok, úszók | 32 bites lebegőpont |
| fagyasztva | Sorok, gyűjtemények, felhasználó által meghatározott típusok | Több részből álló értéket egyetlen megváltoztathatatlan blobként tárol |
| inet | Strings | IP-cím IPv4 vagy IPv6 formátumban |
| int | Egész számok | 32 bites előjeles egész szám |
| lista | Elemek rendezett gyűjteménye | |
| térkép | JSON stílusú kulcs-érték párok gyűjteménye | |
| készlet | Egyedi elemek rendezetlen gyűjteménye | |
| smallint | Egész számok | 16 bites előjeles egész szám |
| szöveg | Strings | UTF-8 kódolású karakterlánc |
| idő | Egész számok, karakterláncok | Napszak nanoszekundumos pontossággal |
| időbélyeg | Egész számok, karakterláncok | Dátum plusz idő, ezredmásodpercben kódolva az epoch óta |
| időuid | UUID | 1-es típusú UUID, beágyazott idő szerint rendezhető |
| aprócska | Egész számok | 8 bites előjeles egész szám |
| kettős | Egy rögzített csoport típusos mezőkből | |
| uuid | UUID | Szabványos UUID |
| varchar | Strings | UTF-8 kódolású karakterlánc, a szöveg aliasa |
| varint | Egész számok | Tetszőleges pontosságú egész szám |
A listán szereplő három választási lehetőség okozza a legtöbb modellezési hibát, ezért érdemes ezeket explicit módon megemlíteni.
- szöveg varchar ellen. Ugyanaz a típus. Mindkét név működik, és a keverésük nem ad hozzá értéket.
- időbélyeg az időazonosítóval szemben. Használj időbélyeget az események rögzítésére. Használj timeuid-t klaszterező oszlopként, ha sok esemény osztozik egy milliszekundumon, mert az UUID garantálja az egyediséget, miközben továbbra is idő szerint rendez.
- decimális kontra dupla. A monetáris értékek decimális számrendszerben vannak. A dupla érték bináris kerekítési hibát okoz, amely az összesítések között halmozódik.
A ellen Az oszlopra egy speciális korlátozás vonatkozik: egy tábla tartalmazhat számláló oszlopokat vagy sima oszlopokat, soha nem mindkettőt, és a számláló sorok nem szúrhatók be, csak növelhetők.
Cassandra TTL (Time to Live) automatikus adatlejárat használatával
Cassandra olyan funkciókat biztosít, amelyek segítségével az adatok automatikusan lejárhatók.
Az adatbeillesztés során meg kell adni a 'ttl' értéket másodpercben. A „ttl” érték az adatok életbe lépési ideje. Az adott idő elteltével az adatok automatikusan törlődnek.
Például a beszúrás során adjon meg ttl értéket 100 másodpercben. Az adatok 100 másodperc elteltével automatikusan törlődnek. Ha az adatok lejártak, a lejárt adatot sírkő jelöli.
A sírkő türelmi időre létezik. Az adatok lejárta után az adatok automatikusan törlődnek a tömörítési folyamat után.
Szintaxis
INSERT INTO KeyspaceName.TableName (ColumnNames) VALUES (ColumnValues) USING TTL TimeInSeconds;
Példa
Itt látható az a pillanatkép, ahol az adatok beszúrásra kerülnek a tanulói táblázatba 100 másodperces ttl értékkel.
INSERT INTO University.Student (rollno, name, dept, semester) VALUES (3, 'Guru99', 'CS', 7) USING TTL 100;
Itt az a pillanatkép, ahol az adatok 100 másodperc után automatikusan lejárnak, és az adatok automatikusan törlődnek.
TTL ellenőrzése és módosítása meglévő adatokon
Miután egy érték TTL-t hordoz, további három művelet hasznos, és mindegyik viselkedése meglepi az újonnan érkezőket.
Bármely nem elsődleges kulcsú oszlop fennmaradó élettartama a TTL függvénnyel olvasható ki.
SELECT name, TTL(name) FROM University.Student WHERE rollno = 3;
A null eredmény azt jelenti, hogy az oszlophoz nincs lejárati idő beállítva. Az elsődleges kulcs oszlopai nem kérdezhetők le ilyen módon, mivel a TTL az értékekhez, nem pedig a kulcshoz kapcsolódik.
Egy meglévő értékhez új TTL rendelhető frissítéssel, ami az adott pillanattól kezdve nullázza a visszaszámlálást.
UPDATE University.Student USING TTL 600 SET name = 'Guru99' WHERE rollno = 3;
Egy táblázatszintű alapértelmezett beállítás elkerüli a feltétel ismétlését minden utasításban.
ALTER TABLE University.Student WITH default_time_to_live = 86400;
Két következmény következik ebből. Először is, a TTL oszloponként érvényes, nem soronként, így egy oszlop TTL nélküli frissítése az adott oszlopot a többi lejárta után hátrahagyja, egy részben feltöltött sort hozva létre. A TTL teljes beszúrására való beállítása ezt elkerüli. Másodszor, minden lejáratkor egy sírkövet ír, így egy olyan tábla, ahol több millió sor jár le együtt, lelassítja az olvasást, amíg a tömörítés ki nem törli őket. A TimeWindowCompactionStrategy használata ilyen táblákhoz lehetővé teszi, hogy a teljes SSTable-ok egyszerre törlődjenek, ahelyett, hogy soronként tömörítenék őket.
A lejárat egy gyűjteményen belüli elemekre is alkalmazható, amelyet a következő tárgyal. Cassandra gyűjtemény tutorial.
