Apache Cassandra - FH AACHEN University of Applied Sciences Lecture Notes PDF

Summary

These lecture notes cover Apache Cassandra, a NoSQL, distributed database system. The document details its features and architecture, highlighting its scalability, fault tolerance, and column-based data storage. The notes discuss various aspects of Apache Cassandra to students of database systems.

Full Transcript

Apache Cassandra © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 511 Warum ein weiteres NoSQL Column-based-System? HBase besitzt leider sehr viele Server-Prozesse. So benötigen wir den zookeeper, das HDFS mit seinem...

Apache Cassandra © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 511 Warum ein weiteres NoSQL Column-based-System? HBase besitzt leider sehr viele Server-Prozesse. So benötigen wir den zookeeper, das HDFS mit seinem Namenode und den Data Nodes, die Region-Server von HBase… Zusätzlich besitzt der Master-Slave-Ansatz das Problem, dass es einen Single-Point-of Failure gibt. Daher bewegen wir uns hier auch im CP-Bereich des CAP-Theorems. Viele wollen aber lieber AP! Cassandra bietet einen Java-basierte out-of-the-box Ansatz, mit einer relativ klaren Server-Struktur. Wir gehen auf die AP-Seite und nutzen hierzu die DynamoDB- Idee des CHORD-Ringes © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 512 Warum ein weiteres NoSQL Column-based-System? HBase ist CP ("Consistency + tolerance to network partitions"). Die Verfügbarkeit versucht man durch Secondary- Server und durch den Zookeeper in den Griff zu kriegen. Cassandra's folgt jedoch der AP-Idee ("Availability + tolerance to network Partitions"). Hierbei kann die erreichbare Konsistenz durch einen “QUORUM”-basierten Ansatz eingestellt werden. Das Einstellpotential wird aber wie bei DynamoDB faktisch durch das Hinted-Handoff eingeschränkt, CAP gilt ja weiterhin. © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 513 Warum ein weiteres NoSQL Column-based-System? Cassandra kann auch mit kleinen Clustern (1,3,5 Knoten) betrieben werden. HBase macht eigentlich mit weniger als 7 Knoten keinen Sinn. © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 514 Warum ein weiteres NoSQL Column-based-System? Cassandra ermöglicht es im Vergleich zu DynamoDB den CHORD-Ring über 2 unterschiedliche Partitioner zu nutzen. So gibt es einen Random Partitioner, der die Daten wie gehabt mittels Consistent Hashing auf den Ring verteilt. Bei diesem Verfahren gibt es jedoch Einschränkungen, die man nicht immer haben möchte. Daher gibt es zusätzlich einen Order Preserving Partitioner, der die Ordnung der Schlüssel berücksichtigt. Cassandra wählt den Knoten über den Row Key aus und verwendet hierfür den Partitioner. Mit dem Random Partitioner wird die Last in Cassandra gleichmäßig verteilt. Der Order Preserving Partitioner ist für Bereichsanfragen förderlich, kann aber die Lastverteilung unterlaufen. © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 515 Cassandra ist eine elastisch skalierbare, verteilte, fehlertolerante spaltenorientierte Datenbank mit einstellbarer Konsistenz © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 516 1. Elastisch skalierbare Die Nutzung des Chord-Ringes ermöglicht die Hinzunahme weiterer Rechner in den Cassandra-Ring, so dass die Leistungsfähigkeit nahezu linear skaliert werden kann © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 517 2. Verteilt Durch die P2P-CHORD-Technologie haben wir es mit einem verteilten System, ohne fixen Einstiegspunt (Master) zu tun. © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 518 3. Fehlertolerant Da wir keinen Master haben, gibt es auch keinen Single-Point of Failure. Durch Replikation erhalten wir eine verbesserte Ausfallsicherheit © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 519 4. Spalten-basiert Zeilen werden über den Row-Key adressiert. Die Inhalte sind in Column- Families gruppiert, die sortiert sind und von daher schnell durchlaufen werden können. Wir folgen also der Idee von BigTable und Hbase, sparen uns aber das erneut verteilte Backend von HDFS © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 520 4. Einstellbare Konsistenz Cassandra folgt dem CAP C ist innerhalb bestimmter Rahmenbedingungen einstellbar © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 521 Apache Cassandra: Die Mischung macht es © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 522 Übernommene Konzepte des Dynamo Papers Consistent hashing Vektoruhren Gossip protocol Sowie Weiteres (hinted handoff, …) © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 523 Aus Bigtable/Hadoop Column Family 1 Column Family 2 Name1 Name2 Name Row Key Value Value Value Column1 Column2 Column © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 524 Das Datenmodell Entspricht einer 3-dimensionalen “Hash Table” Ein Keyspace beinhaltet einen Satz an Column Families und regelt einheitlich deren Replikationsart (wählbare Strategie) Jede Zeile besitzt einen Schlüssel und besteht aus Spalten, deren Namen vorher nicht festgelegt sein müssen Jede Spalte hat einen Namen und einen value Wert, sowie einen Zeitstempel Optional gibt es ein TTL © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 525 Das Datenmodell © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 526 Cassandra Row Eine Zeile besteht aus einer Sequenz an key- value-Paaren Diese key-value Paare bilden die columns key = column name Jede Row muss mindestens eine Column beinhalten © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 527 Columns © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 528 Columns bieten 2 Speichermöglichkeiten Der Spaltenname ist frei wählbar, hier wird z.B. die tweet ID genommen Damit machen auch „leere“ Spalten ggf. Sinn, denn der Spaltenname alleine liefert auch Information “-” (empty byte array) © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 529 Wieso 3-dimensional? Bisher sind wir orientiert an HBase eher hiervon ausgegangen: SortedMap Eine Map liefert den effizienten Zugriff über den Key, die SortedMap ist gut für Bereichsabfragen © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 530 Wieso 3-dimensional? Nun haben wir bei Cassandra ja auf dem CHORD-Ring verteilte Daten. Bereichsabfragen sind im Ring aufgrund des Hash- Verfahrens eigentlich nicht möglich. Cassandra aber bietet einen Order Preserving Partitioner an, der die Daten demnach sortiert auf den Ring abbildet. Die Standardeinstellung ist jedoch eine andere (Random Partitioner), daher sollten wir von einer unsortierten Map ausgehen Map Bereichsabfragen über Zeilen-Keys sind in diesem Fall nicht effektiv. Diese Information kann jedoch vielleicht woanders gespeichert werden. © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 531 Wieso 3-dimensional? Map © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 532 Partitionieren und Replizieren Der Partitioner transformiert die Schlüssel und verteilt so die Daten “foo1” und “foo2” liegen dann ggf. auf verschiedenen Knoten Standardmäßig wird der Random Partitioner eingesetzt #1 'foo1' #5 #2 'foo2' #4 #3 © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 533 Partitionieren und Replizieren Cassandra erlaubt auch das Verwenden einer Replica Placement Strategy Wir kennen von DynamoDB die Simple Strategy, bei der die Replikas im Uhrzeigersinn gewählt werden 'foo1' #1 #5 'foo1' #2 #4 #3 'foo1' © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 534 Partitionieren und Replizieren Es gibt aber auch eine Network Topology Strategy, bei der sichergestellt wird, dass die Replikation auf einem anderen Rack oder gar Data Center getätigt wird Rack1:1,3 Rack2:2 #1 'foo1' #1 #5 #5 'foo1' #2 #2 #4 #4 #3 #3 'foo1' © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 535 Die einstellbare Konsistenz bei der Replikation Bei Cassandra kann man den Consistency Level an verschiedenen Stellen (Datenbank, Column Family, Operation) einstellen CL = ONE #1 'foo1' Client # 5 'foo1' #2 # 4 #3 'foo1' © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 536 Die einstellbare Konsistenz CL = QUORUM #1 'foo1' Client # 5 'foo1' #2 # 4 #3 'foo1' © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 537 Consistency Levels für das Schreiben ANY A write must be written to at least one node. If all replica nodes for the given row key are down, the write can still succeed once a hinted handoff has been written. Note that if all replica nodes are down at write time, an ANY write will not be readable until the replica nodes for that row key have recovered. ONE A write must be written to the commit log and memory table of at least one replica node. TWO A write must be written to the commit log and memory table of at least two replica nodes. THREE A write must be written to the commit log and memory table of at least three replica nodes. © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 538 Write Consistency (ONE) 0 R1 Node 6 Node 1 R2 Node 5 Node 2 replication_factor = 3 Client Node 4 Node 3 R3 INSERT INTO table (column1, …) VALUES (value1, …) USING CONSISTENCY ONE © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 539 Die einstellbare Konsistenz: Schreiben Level Description ZERO Good luck with that ANY 1 replica (hints count) ONE 1 replica. read repair in background QUORUM (N /2) + 1 ALL N = replication factor © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 540 Die einstellbare Konsistenz: Lesen ZERO Unsupported. You cannot specify CL.ZERO for read operations because it doesn’t make sense. This would amount to saying “give me the data from no nodes.” ANY Unsupported. Use CL.ONE instead. ONE Immediately return the record held by the first node that responds to the query. A background thread is created to check that record against the same record on other replicas. If any are out of date, a read repair is then performed to sync them all to the most recent value. QUORUM Query all nodes. Once a majority of replicas ((replication factor / 2) + 1) respond, return to the client the value with the most recent timestamp. Then, if necessary, perform a read repair in the background on all remaining replicas. ALL Query all nodes. Wait for all nodes to respond, and return to the client the record with the most recent timestamp. Then, if necessary, perform a read repair in the background. If any nodes fail to respond, fail the read operation. © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 541 Consistency Levels für das Lesen ONE Returns a response from the closest replica (as determined by the snitch). By default, a read repair runs in the background to make the other replicas consistent. TWO Returns the most recent data from two of the closest replicas. THREE Returns the most recent data from three of the closest replicas. QUORUM Returns the record with the most recent timestamp after a quorum of replicas has responded. © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 542 Die einstellbare Konsistenz: Lesen Level Description ZERO Ummm… ANY Try ONE instead ONE 1 replica QUORUM Return most recent TS after (N /2) + 1 report ALL N = replication factor © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 543 Hinted Handoff Kommen wir zurück zum Beispiel CL = QUORUM 'Key-foo' #1 'foo1' Client # 5 'foo1' #2 # 4 #3 'foo1' © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 544... Was ist, wenn node #3 down ist? © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 545 Hint (z.B. auf sich selber) #1 'foo1' Client # 5 'foo1' #2 # 4 #3 © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 546 Wenn ein Knoten Down ist wird der Knoten, der die Anfrage entgegen nimmt (der Client spricht irgendeinen bei ihm konfigurierten Knoten an) einen hint machen und einen anderen Knoten für diese Aufgabe auswählen (ggf. auch sich selber) Dieser nimmt jetzt (ohne dessen Daten zu haben) die Rolle des Replicas ein Kommt der ursprüngliche Replika zurück, so übernimmt dieser die Rolle Hinted Handoff © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 547... Node #5 gibt den hint zurück wenn node #3 zurück kommt hint 'foo1' #1 Client # 5 'foo1' #2 #4 #3 'foo1' © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 548... Und wenn node #5 kurz vor Übergabe des Hints an node #3 abstürzt? hint #1 'foo1' Client # 5 #2 'foo1' #4 #3 © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 549... Wenn der Client gut konfiguriert ist, wird er sich einen annderen Knoten auswählen, z.B. 4 Wenn wir als Consistency Level Quorum verwenden, so wird der node #4 die Anfrage nach 'foo' an alle replicas verteilen, leider auch an den mit falschen Daten hint #1 'foo1' Client # 5 #2 'foo1' #4 #3 '' © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 550... Wir haben durch das Quorum eine byzantische Situation (die man z.B. auch bei der Hamming- Distanz bei der Kodierungstheorie verwendet) hint #1 'foo1' Client #5 #2 'foo1' #4 #3 '' © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 551... Die Inkonsistenz wird erkannt und node #3 erhält den korrekten Wert Read Repair hint #1 'foo1' Client # 5 'foo1' #2 #4 'foo' != '' #3 'foo' © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 552 Hinted Handoff 0 R1 replication_factor = 3 Node 6 Node 1 und hinted_handoff_enabled = R2 true Node 5 Node 2 Client Node 4 Node 3 R3 Write locally: system.hints INSERT INTO table (column1, …) VALUES (value1, …) USING CONSISTENCY ANY © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 553 Read Repair Beim Lesen werden eine gemäß dem Konsistenzlevel bestimmten Anzahl der Replikate gefragt. Faktisch wartet blockierend auf R Antworten, im Hintergrund jedoch noch auf die anderen N-R Antworten auf R Antworten. Der neueste Wert wird dann aber den Replikaten mit alten Werten mitgeteilt 0 R1 Node 6 Node 1 R2 replication_factor = 3 Node 5 Node 2 Client Node 4 Node 3 R3 SELECT * FROM table USING CONSISTENCY ONE © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 554 Scale-Out “e” “z” “j” “t” “o” © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 555 Scale-Out “e” “?” “z” “j” “t” “o” © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 556 Scale-Out “e” “z” “g” “j” “t” “o” © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 557 Wir wollen den Durchsatz verdoppeln? Fügen wir einfach die gleiche Anzahl an Knoten hinzu Und zwar im laufenden Betrieb Allerdings sollte man dann auf ein Rebalancieren achten, was mit dem nodetool-Kommando geht (cleanup und repair) Auch muss die Konfiguration korrekt sein (auto_bootstrap=true) © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 558 Wir wollen den Durchsatz verdoppeln? “e” “z” “j” “t” “o” © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 559 Wir wollen den Durchsatz verdoppeln? “b” “e” “z” “g” “v” “j” “t” “l” “q” “o” © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 560 Multi-Geography/Zone Aware Cassandra ermöglicht das Verteilen der Daten über Data-Centre-Grenzen hinweg, wobei sogar auch Cloud-Centre möglich sind © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 561 Datenredundanz Cassandra erlaubt das Einstellen der Replikation unter Berücksichtigung einer Konfigurationszuordnung in Racks und Data Centers © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 562 Cassandra Query Language - CQL SQL-ähnliche Abfragesprache Basis sind die „Datenbanken“, die als Keyspace bezeichnet werden Anlegen eines keyspaces liefert einen Namespace für die „Tabellen“ CREATE KEYSPACE demo WITH replication = {‘class’: ’SimpleStrategy’, replication_factor’: 3}; – Wir haben 2 Replikationsstrategien: SimpleStrategy und NetworkTopologyStrategy. – SimpleStrategy nutzt die Uhrzeiger-Strategie – NetworkTopologyStrategy macht bei komplexen Installationen Sinn Um hiermit zu arbeiten aktiviert man den ”Namespace“: USE demo; © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 563 Cassandra Query Language - CQL Es ist wichtig zu verstehen, wie die Keys verwendet werden.... ○ Es gibt 4 Arten von Primärschlüsseln: § SIMPLE primary key consists of a single column § COMPOSITE (aka COMPOUND) primary keys need to be declared in a separate PRIMARY KEY clause § PARTITION KEY is the first key of a composed primary key. § CLUSTERING KEY is the second of the composed primary key § both partition and clustering key can be made by more columns. Use Brackets § The Partition Key is responsible for data distribution across your nodes. The Clustering Key is responsible for data sorting within the partition. The Primary Key is equivalent to the Partition Key in a single-field-key table. ○ http://stackoverflow.com/questions/24949676/difference-between- partition-key-composite-key-and-clustering-key-in-cassandra © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 564 Cassandra Query Language - CQL Anlegen von Tabellen: CREATE TABLE users( CREATE TABLE tweets( email varchar PRIMARY KEY, email varchar, bio varchar, time_posted timestamp, birthday timestamp, tweet varchar, active boolean); PRIMARY KEY (email, time_posted)); Wichtig: Wir sehen hier, dass time_posted offensichtlich die Sortierreihenfolge der tweets-Tabelle bestimmt (clustering Key). Diesen Spalten sind dann die anderen Werte (tweet) faktisch zugeordnet © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 565 Ein einfaches Zeitreihenbeispiel Anlegen von Tabellen: CREATE TABLE temperature ( weatherstation_id text, event_time timestamp, temperature text, PRIMARY KEY (weatherstation_id,event_time) ); INSERT INTO temperature(weatherstation_id,event_time,temperature) VALUES ('1234ABCD','2013-04-03 07:01:00','72F'); INSERT INTO temperature(weatherstation_id,event_time,temperature) VALUES ('1234ABCD','2013-04-03 07:02:00','73F'); https://docs.datastax.com/en/tutorials/Time_Series.pdf © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 566 Ein einfaches Zeitreihenbeispiel Tageweise abspeichern CREATE TABLE temperature_by_day ( weatherstation_id text, date text, event_time timestamp, temperature text, PRIMARY KEY ((weatherstation_id,date),event_time) ); INSERT INTO temperature_by_day(weatherstation_id,date,event_time,temperature) VALUES ('1234ABCD','2013-04-03','2013-04-03 07:01:00','72F'); INSERT INTO temperature_by_day(weatherstation_id,date,event_time,temperature) VALUES ('1234ABCD','2013-04-03','2013-04-03 07:02:00','73F'); https://docs.datastax.com/en/tutorials/Time_Series.pdf © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 567 Ein einfaches Zeitreihenbeispiel Nur die letzten 20 Sekunden vorhalten CREATE TABLE latest_temperatures ( weatherstation_id text, event_time timestamp, temperature text, PRIMARY KEY (weatherstation_id,event_time), ) WITH CLUSTERING ORDER BY (event_time DESC); INSERT INTO latest_temperatures(weatherstation_id,event_time,temperature) VALUES ('1234ABCD','2013-04-03 07:03:00','72F') USING TTL 20; INSERT INTO latest_temperatures(weatherstation_id,event_time,temperature) VALUES ('1234ABCD','2013-04-03 07:02:00','73F') USING TTL 20; https://docs.datastax.com/en/tutorials/Time_Series.pdf © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 568 Cassandra Query Language - CQL Anlegen von Indexen: CREATE TABLE users ( userID uuid, firstname text, lastname text, email text, address text, zip int, state text, PRIMARY KEY (userID) ); CREATE INDEX user_state ON users (state); CREATE INDEX ON users (zip); © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 569 Cassandra Query Language - CQL Einfügen von Daten INSERT INTO users (email, bio, birthday, active) VALUES (‘[email protected]’, ‘BT360 Teammate’, 516513600000, true) USING CONSISTENCY LOCAL_QUORUM AND TTL 86400; ○ ** timestamp fields werden in milliseconds since epoch angegeben ○ TTL in seconds © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 570 Cassandra Query Language - CQL Tabelleninhalte abfragen Eine SELECT-Anweisung liest ein oder mehrere Zeilen von einer Column-Family und liefert einen result-set von Zeilen Anders als bei der Projektion eines SQL SELECT gibt es keine Garantie, dass alle angegebenen Spalten auch im Result-Set sind. Es gibt ja kein Schema. Von daher gibt es bei der Angabe einer nicht-existenten Spalte auch keinen Fehler SELECT * FROM users LIMIT 5000; SELECT email FROM users WHERE active = true; SELECT * from People USING CONSISTENCY QUORUM; SELECT * FROM emp where empid IN (103, 100) ORDER BY deptid ASC; © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 571 Cassandra Query Language - CQL Es gibt in Cassandra weder Join noch Group BY! Sollen entsprechende Operation genutzt werden, so bietet Cassandra auch einen „Storage“-Treiber zur Verwendung von Pig oder Hive an © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 572 Write Operations – Wir folgen der Idee aus BigTable: © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 573 Der Log-Structured-Merge-Tree Eine hierarchische Struktur aus Memtable und SSTable © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 574 Das interne Datenmodell Vieles kennen wir von Google-Bigtable/HBase © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 575 Das interne Datenmodell https://www.instaclustr.com/blog/cassandra-data-partitioning/ © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 576 Die Storage Engine Verfahren beim Schreiben 1. Protokolliere die Schreiboperation im Commit-Log (Append). Der Write-Ahead-Log wird standardmäßig alle 10 Sekunden mit flush gesichert 2. Memtables (Write-back Cache) werden im Hauptspeicher aktualisiert (keine Änderung auf Platte, keine Sperren!) 3. Irgendwann (asynchron, konfigurierbar) findet ein Flush auf Festplatte in SSTable und SSTableIndex statt (z.B. bei einer bestimmten Größe oder Anzahl von Änderungen). Hierbei werden die Daten beim Flush sortiert in einem durch geschrieben (keine Seek-Time) 4. Allerdings bedeutet dies, dass die Daten jetzt tatsächlich in mehreren SSTables stehen können. Leider können wir aber nicht alle Memtables im Speicher halten, so dass unser Verfahren Komplexität beim Lesen erzeugt Hinweis: Intern verwendet Cassandra multiple Dateien für die SSTables und deren Metadaten © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 577 Schreib-Pfad https://medium.com/nerd-for-tech/cassandra-internals-38e279c72c3e © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 578 Hilfsmittel für das schnelle Lesen Die “aktiven“ SSTables befinden sich im Speicher und werden dort innerhalb der JVM als Memtable gespeichert. Ein Zugriff auf diese Daten geht immer schnell Zusätzlich kann für jede Column-Family ein Row-Cache konfiguriert werden, der dauerhaft vollständige Zeilen vorhalten kann (ohne write-through; Änderungen invalidieren nur den Eintrag). © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 579 Hilfsmittel für das schnelle Lesen Die SSTable-Dateien (normales Dateisystem) haben zwar einen festgelegten Namensraum, allerdings orientiert sich dieser an den Keyspaces, die die Replikationsstrategie festlegen. Ein Bloomfilter wird verwendet, um dabei zu helfen zu entscheiden, ob ein Datum in einer SSTABLE-Datei ist BloomFilter zeigen an, ob eine SSTable-Datei die gesuchten Daten (Spalte) beinhalten (könnte). Anschaulich könnten die Daten in so vielen SSTAbles stehen, dass wir nicht alle im Speicher vorhalten können. Ohne Bloomfilter müssten wir alle laden und durchsuchen Wenn wir dann zugreifen, führen Bloomfilter zur Beschleunigung des Auffindens. Das dann ggf. erforderliche Lesen des SSTable-Indexes und die dann folgende Positionierung innerhalb einer Datei ist allerdings langsam. Daher gibt es einen Key-Cache der die Positionen von Datensätzen im Arbeitsspeicher, um den Zugriff auf häufig abgerufene Schlüssel zu beschleunigen. © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 580 Read Operations nutzen Bloom Filters Bloom Filter helfen dabei die Daten zu finden und werden in den Metadatendateien der SSTables gespeichert Ein Bloomfilter ist eine probabilistische Datenstruktur, mit deren Hilfe sehr schnell festgestellt werden kann, welche Daten in einem Datenstrom schon einmal vorgekommen sind und welche erstmals auftreten. Hierzu wird mit einer geeigneten Zahl von Hash-Funktionen ein „Fingerabdruck“ des gelesenen Datensatzes in einer einzeiligen Hashtabelle hinterlassen. wikipedia Es gibt keine False Negative, nur False Positive Jede SSTable besitzt also einen Bloomfilter der anzeigt, ob diese SSTable einen bestimmten row-key besitzt Hierbei werden alle vorhandenen Keys auch identifiziert, einige wenige nicht vorhandene jedoch auch (positive false Rate von ca. 0.0744%) © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 581 Die relevanten Dateien 1. Bloomfilter-Datei: Jede SSTable enthält einen Bloomfilter, der als Vorfilter für Lesevorgänge dient. Diese Dateien werden als -Filter.db bezeichnet 2. Indexdatei: Die Indexdatei speichert Informationen über den physischen Speicherort von Daten in der SSTable. Diese Datei wird -Index.db bezeichnet 3. Data-Datei: Die eigentlichen Daten einer SSTable werden in einer Datei gespeichert, die -Data.db. Diese Datei enthält die tatsächlichen gespeicherten Datenzeilen. 4. Summary-Datei: Die Summary-Datei (-Summary.db) enthält Informationen, die eine effiziente Navigation in der SSTable ermöglichen, ohne die gesamte Indexdatei laden zu müssen, quasi also eine komprimierte Index-Datei © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 582 Ablauf einer Read-Operation © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 583 Hilfsmittel für das schnelle Lesen https://medium.com/nerd-for-tech/cassandra-internals-38e279c72c3e © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 584 Ablauf einer Read-Operation https://www.syncfusion.com/succinctly-free-ebooks/cassandra/introduction https://medium.com/nerd-for-tech/cassandra-internals-38e279c72c3e © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 585 Compaction https://medium.com/nerd-for-tech/cassandra-internals-38e279c72c3e © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 586 Compaction Cassandra verdichtet die SSTables zu konfigurierbaren Zeitpunkten: SizeTieredCompactionStrategy bei write-intensive workloads LeveledCompactionStrategy bei read-intensive workloads DateTieredCompactionStrategy bei Zeitreihen und TTL-Ableben Mittels des nodetool compact Kommandos kann jederzeit eine Verdichtung gestartet werden. https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/dml_write_path_c.html © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 587 Cassandra Vorteile Passt gut als Speicher für Zeitreihen Hohe Performance Dezentral Gute Skalierbarkeit Replikation Kein Single-Point of Failure Und wir können mit MapReduce arbeiten © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 588 Cassandra Schwachstellen Keine referentielle Integrität ○ Wir haben kein JOIN CQL ist durchaus eine limitierte Abfragesprache Aggregate und Sortieren komplexer ○ Es fehlt ein GROUP BY ○ Sortieren wird pro Partition gemacht, wenn diese zu groß ist dauert es Keine Atomaren Operationen ○ Änderungen könnten auch im Fehlerfalle teilweise durchschlagen ○ Das Speicherkonzept kann auf fehlerhafte Nutzung zu empfindlichen Durchsatzeinbußen führen © FH AACHEN UNIVERSITY OF APPLIED SCIENCES Vorlesung Datenbanken II / Datenanalyse Dezember 23| 589