Cassandra Query Language (CQL) Seminar: NoSQL Wintersemester 2013/2014 Cassandra Zwischenpräsentation 1
Gliederung Basic facts Datentypen DDL/DML ähnlich zu SQL Besonderheiten
Basic facts CQL kurz für Cassandra Query Language Ähnliche Aussprache zu SQL (Missverständnisse möglich) Aktuell CQL 3 Ersetzt Apache Thrift API Almost SQL : SQL-konform, wo es möglich ist Denormalized SQL : Denormalisierung hat Auswirkung auf die Art der Anfragen Seite 1 / 16
Datentypen ascii, bigint, blob, boolean, counter, double, map,set,list uuid Universally Unique Identifier (Identifier Standard) [Version Time Raw bytes] practically unique Werte in verteilten Systemen Beispielwert: 550e8400-e29b-41d4-a716-446655440000 timeuuid (Type-1 uuid) Uuid Type-1 [Time Raw bytes], nützlich für zeitliche Sortierungen Falls mehrere Timestamps gleich sein können, nützliche Funktionen: dateof() Seite 2 / 16
Collection types (Datentypen) Set: Sammlung von unique values in ihrer natürlichen Sortierreihenfolge CREATE TABLE users ( emails set<text> ); INSERT INTO users (, emails) VALUES (, { user1@gmx.de, user2@gmx.de }); UPDATE users SET emails = emails + ( user1@gmx.de ) WHERE UPDATE users SET emails = emails - ( user1@gmx.de ) WHERE Seite 3 / 16
Collection types (Datentypen) List: Mehrfachwerte, Sortierreihenfolge nach Listenindex CREATE TABLE users ( places list<text> ); UPDATE users SET places = places + [ city3 ] WHERE INSERT INTO users (, places) VALUES (, [ city1, city2 ]); UPDATE users SET places = [ city3 ] + places WHERE UPDATE users SET places[2] = [ city3 ] WHERE Seite 4 / 16
Collection types (Datentypen) Map: Key-Value Pairs, intern als Columns gespeichert CREATE TABLE users ( todo map<timestamp, text> ); INSERT INTO users (, todo) VALUES (, { 2010-08-09 10:00 : activity1, 2011-09-01 11:00 : activity2 }); UPDATE users SET todo[ 2012-01-01 01:00 ] = activity3 WHERE Seite 5 / 16
Keyspace (DDL) CQL Pendant zu database Auf Clustern werden Mengen von Keyspaces verwaltet Ein Cluster hat einen Keyspace / Anwendung Keyspaces werden mit einer Replikationsstrategie angelegt SimpleStrategy = ausreichend für 1 Cluster NetworkTopologyStrategy = für mehr als 1 Cluster (production use) CREATE KEYSPACE demodb WITH REPLICATION = { class : SimpleStrategy, replication_factor : 3 }); DROP KEYSPACE demodb; Seite 6 / 16
Tables (DDL) Wie in SQL: CREATE TABLE employee ( empid int, deptid int, firstname varchar, lastname varchar, PRIMARY KEY(empId, deptid) ); DROP TABLE employee; Seite 7 / 16
Alter Table (DDL) Column hinzufügen: ALTER TABLE employee ADD attr17 varchar; Datentyp einer column ändern: ALTER TABLE employee ALTER attr17 TYPE int; Column löschen (auf Rowbasis): DELETE attr17 FROM employee WHERE empid = 104; Seite 8 / 16
SELECT Wie in SQL: SELECT * FROM employee WHERE empid IN (130, 104) ORDER BY deptid DESC; Vorsicht bei * -> Wide Columns Seite 9 / 16
Insert into (DML) Wie in SQL: INSERT INTO employee (empid, deptid, firstname, lastname) VALUES (104, 15, Peter, Parker ); DELETE FROM employee WHERE empid = 104; Seite 10 / 16
Upsert INSERT INTO / UPDATE sind semantisch identisch, zunächst nur Update Beide Operationen erzeugen, wenn nicht vorhanden und ändern, wenn vorhanden Keine Fehlermeldung (Erzeugen existiert schon) bzw. (Ändern existiert nicht) Wahrscheinlich gefährlichstes Missverständnis SQL / CQL Vor einem write wird kein read gemacht (Verteilung) Empfehlung: Nutzung wie in SQL um die Intention auszudrücken INSERT INTO employee.. IF NOT EXISTS Seite 11 / 16
Denormalisierung Relationale Datenmodellierung: Nicht redundante, konsistente Daten Beliebig komplizierte, flexible queries um bestimmte Sichten zu erzeugen Indizes entsprechend anpassbar Datenmodellierung in Cassandra: Datenmodellierung den Sichten angepasst Hauptziel: Schnelle queries, d.h. 1 query to 1 node Keine joins, aggregations, eingeschränktes ORDER BY, usw.. Datenmodellierung muss all dies berücksichtigen! Seite 12 / 16
Columns Columns werden intern mit Timestamp gespeichert Sortierung der Columns ist typisch Columns enthalten oft values im columnkey, sogar valueless columns möglich! Composite columns erlauben mehrere Werte im columnkey z.b: nach dem Muster <Timeuuid Eventtype Event> SELECT FIRST 3 REVERSED timestamp200 timestamp100 FROM adventures; Seite 13 / 16
PRIMARY KEY () Statement: CREATE TABLE employee ( empid int, deptid int, PRIMARY KEY(empId, deptid)); identifiziert einen Datensatz eindeutig anhand der Kombination (empid, deptid) ABER: empid wird gleichzeitig zum PARTITION KEY -> Speicherung auf Node xy deptid und folgende columns werden zu CLUSTERING COLUMNS absteigender Prio Bedeutung des Statements: Alle rows werden auf Node für Keyspace empid geordnet nach der deptid gespeichert -> Auswahl des PRIMARY KEYS passend zu Anwendungsfall / typischen queries -> Auch ein SELECT-Statement mit attr1, attr3 ohne attr3 wird nicht funktionieren! Seite 14 / 16
Indizes Das funktioniert nicht: SELECT * FROM employee WHERE fullname= parker ; es sei denn fullname wurde explizit indiziert Standardfall: Queries nur über den Rowkey Wenn query über non-rowkey sein muss: CREATE INDEX ON employee(fullname); Erstellt einen secondary index, keinen zweiten rowkey oder ähnliches Seite 15 / 16
Time To Live Columns können eine TTL bekommen INSERT INTO employee (empid, deptid, firstname, lastname) VALUES (104, 15, Peter, Parker ) USING TTL 60; Nach 30 Sekunden die verbleibende Zeit überprüfen: SELECT TTL(empId) FROM employee WHERE ttl(empid) ------------ 30 Seite 16 / 16
Time To Live Columns können eine TTL bekommen That s it INSERT INTO employee (empid, deptid, firstname, lastname) VALUES (104, 15, Peter, Parker ) USING TTL 60; Nach 30 Sekunden die verbleibende Zeit überprüfen: SELECT TTL(empId) FROM employee WHERE ttl(empid) ------------ 30 Seite 16 / 16