a.1 geschichte, charakteristikakfg/db/cassandra.pdf · elevator pitch of nishant neeraj: apache...

Anhang A

Cassandra

A.1 Geschichte, Charakteristika

• Beginn bei Facebook (Prashant Malik und Avinash Lakshman), ab 2008 Open SourceProjekt

• 2010 Top-Level-Project von Apache Software Foundation

• Elevator pitch of Nishant Neeraj: Apache Cassandra is an open source, distributed, decen-tralized, elastically scalable, highly available, fault-tolerant, tunable consistent, row-orienteddatabase that bases its distribution design on Amazons Dynamo and its data model on Goo-gles Bigtable. Created at Facebook, it is now used at some of the most popular sites on theWeb.

• Vollstandig in Java geschrieben.

• CAP-Theorem: Cassandra bietet hohe Availability und Partition Tolerance auf Kostenvon Consistency, die einstellbar (tunable) ist.

• Referenzen: Uber 1000 Firmen, Instagram, Spotify, Facebook, Netflix, Apple

A.2 Installation

A.2.1 MacOS X

1. Download apache-cassandra-......tar

Momentane Version: apache-cassandra-3.9Native Protocol v4

2. Auspacken des tar-Files:

$ tar -zxvf apache-cassandra-...tar

1

2 ANHANG A. CASSANDRA

3. Verschiebe Cassandra-Verzeichnis in ein eigenes Verzeichnis (z.B. $HOME/cassandra ).

Alle Daten einer Datenbank befinden sich im Verzeichnis:

$HOME/cassandra/data/data/<keyspace>

z.B.$HOME/cassandra/data/data/bsp

4. Erweitere Pfad in .profile um $HOME/cassandra/bin

5. • Starten des Datenbankservers im Vordergrund:$ cassandra -f

Stoppen des Datenbankservers:<ctrl> + C

im Terminal, wo der DB-Server gestartet wurde.

• Starten des Datenbankservers im Hintergrund:$ cassandra

Stoppen des im Hintergrund gestarteten Datenbankservers:$ kill <pid>

im Terminal, wo der DB-Server gestartet wurde.(Die pid kann man finden mit $ ps.)

6. Starten der Cassandra-Query-Language-Shell (CQL-Shell):

$ cqlsh <dbserver>

7. Ausfuhrung einer Datei mit CQL-Anweisungen (z.B. f1.cql) in der Betriebs-System-Shell:

$ cqlsh -f f1.cql

8. Ausfuhrung einer Datei mit CQL-Anweisungen (z.B. f1.cql) in der CQL-Shell:

cqlsh> SOURCE ’f1.cql’

9. Entwickungsumgebung:

DataStax DevCenter(https://academy.datastax.com/downloads )

A.3 CQL – Cassandra Query Language

A.3.1 Verbindung mit der Datenbank

Verbindung zum Datenbank-Server aufbauen:$ cqlsh localhost

(Oder mit --port und --host Optionen.) ?

A.3. CQL – CASSANDRA QUERY LANGUAGE 3

A.3.2 Erste CQL-Anweisungen

1. Erste Anfrage:cqlsh> SELECT cluster_name, listen_address FROM system.local;

2. Einige Info-Anweisungen:cqlsh> SHOW HOST;

cqlsh> SHOW VERSION;

cqlsh> DESCRIBE CLUSTER;

cqlsh> DESCRIBE KEYSPACES;

cqlsh> DESCRIBE TABLES;

3. Beenden:cqlsh> EXIT;

A.3.3 Weitere CQL-Anweisungen

Dieser Abschnitt gibt einen praktischen Uberblick uber CQL, das große Ahnlichkeit mit SQL hat.Auf viele Optionen und deren Bedeutung gehen wir nicht ein. Sie sollten der CQL-Dokumentationoder einem Lehrbuch entnommen werden[6].

Die Syntax von CQL ist uber HELP zuganglich:cqlsh> HELP;

Viele Kommandos konnen mit dem Tabulator erganzt bzw. vervollstandigt werden. Groß- undKleinschreibung spielt in CQL keine Rolle.

Zunachst muss ein Keyspace (entspricht in etwa einer Datenbank) erzeugt werden. Im einfach-sten Fall sieht das folgendermaßen aus:

cqlsh> CREATE KEYSPACE bsp WITH REPLICATION

= { ’class’ : ’SimpleStrategy’, ’replication_factor’ : 1 };

Mitcqlsh> DESCRIBE KEYSPACE bsp;

konnen wir uns den Keyspace und alle seine Tabellen (Column Families) anschauen.

Mitcqlsh> USE bsp;

begeben wir uns in den Keyspace bsp. Dadurch andert sich der Prompt zu:cqlsh:bsp>

Die Objekte des Keyspaces (z.B. Tabellen) mussen nicht mehr durch seinen Namen spezifiziertwerden.

Erzeugen einer Tabelle:cqlsh:bsp> CREATE TABLE stud(

vorname text,

nachname text,


PRIMARY KEY(vorname));

Wichtig: Es muss ein Schlussel definiert werden!

Schauen wir uns die Tabelle naher an mit:cqlsh:bsp> DESCRIBE TABLE stud;

Dabei werden die Default-Werte samtlicher Optionen ausgegeben.

Einfugen einer Zeile in die Tabelle stud und Uberprufung:cqlsh:bsp> INSERT INTO stud(vorname, nachname) VALUES(’Oskar’, ’Mueller’);

cqlsh:bsp> INSERT INTO stud JSON ’{"vorname": "Max", "nachname": "Mayer"}’;cqlsh:bsp> SELECT COUNT(*) FROM stud;

cqlsh:bsp> SELECT * FROM stud WHERE vorname=’Oskar’;

cqlsh:bsp> SELECT * FROM stud WHERE nachname=’Mueller’;

cqlsh:bsp> SELECT * FROM stud WHERE nachname=’Mueller’ ALLOW FILTERING;

Jederzeit kann eine Spalte hinzugefugt werden:cqlsh:bsp> ALTER TABLE stud ADD beruf text;

cqlsh:bsp> INSERT INTO stud(vorname, nachname, beruf)

VALUES(’Manfred’, ’Barth’, ’Maurer’);

Und nun loschen wir unseren Eintrag ”scheibchenweise” (eine Spalte, eine Zeile, alle Zeilen undschließlich Vernichtung der ganzen Tabelle):

cqlsh:bsp> DELETE nachname FROM stud WHERE vorname=’Oskar’;

cqlsh:bsp> DELETE FROM stud WHERE vorname=’Oskar’;

cqlsh:bsp> TRUNCATE stud;

cqlsh:bsp> DROP TABLE stud;

A.4. DATEN-MODELL 5

A.4 Daten-Modell

Bevor wir naher auf Cassandras Daten-Modell (CDM) eingehen, wollen wir noch mal einen Blickauf das relationale Modell werfen, zu dem das CDM zunachst sehr große Ahnlichkeit hat.

A.4.1 Relationales Daten-Modell

Im relationalen Daten-Modell ist die Datenbank (database) die außerste Schicht. Sie ist einBehalter (container), der Tabellen (Relationen, tables, relations) enthalt. Jede Tabellebesteht aus Zeilen (Tupeln, rows, tuples) und Spalten (Attributen, columns, attribu-tes).

Daten werden als ganze Zeilen eingefugt, wobei fur jede Spalte ein Wert oder Null zu spezifizierenist.

Eine Spalte oder eine Kombination von Spalten kann als Schlussel (primary key) definiertwerden. Mit dem Schlussel oder mit irgendwelchen Suchkriterien konnen eine oder mehrere Zeilenin der Datenbank wieder gefunden werden.

Zur Vermeidung von Daten-Redundanz werden Daten in unterschiedlichen Tabellen gespeichert,die sich eventuell gegenseitig durch Schlussel-Fremdschlussel-Beziehungen (key – foreign key)referenzieren. Die Auflosung dieser – heutzutage sich oft uber viele Tabellen erstreckenden –Beziehungen durch einen sogenannten Join ist aufwandig in SQL zu formulieren und oft auch einPerformanzengpass. Das ist einer der Grunde, warum eventuell NoSQL-Daten-Modelle eingesetztwerden.

A.4.2 Cassandras Daten-Modell

In einer ”Bottom-up-Sicht” haben wir in Cassandra folgende Datenstrukturen (Es werden abjetzt hauptsachlich die englischen Begriffe als Termini technici verwendet.):

• Column: Name/Value-Pair

• Row: Container fur Columns eindeutig referenziert durch einen Primary Key (PK)

• Table (Column Family): Container fur Rows. Hat einen Keyspace-weit eindeutigen Na-men.

• Keyspace: Container fur Tables. Hat einen Cluster-weit eindeutigen Namen.

• Cluster: Container fur Keyspaces. Uberspannt einen oder mehrere Knoten.

In den folgenden Abschnitten betrachten wir diese Strukturen etwas naher, aber ”Top-down”.

A.4.3 Cluster

Zum Design van Cassandra gehort, dass die Datenbank verteilt ist uber mehrere Knoten (Clusteroder Ring), die aber fur den End-Benutzer der Datenbank als eine Maschine erscheinen. AlleKnoten sind gleichberechtigt und konzeptionell in einem Ring angeordnet.


A.4.4 Keyspace

Ein Keyspace reprasentiert ungefahr das, was man bei relationalen Systemen unter ”Database”versteht. So wie eine relationale Datenbank aus Tabellen besteht, besteht ein Keyspace ausColumn Families = Table. Diese Parallelitat zu einem RDBS wird dadurch unterstrichen,dass TABLE und COLUMNFAMILY in CQL synonym verwendet werden konnen.

Allerdings besteht die Datenbank einer Anwendung oft aus mehreren Keyspaces.

Ein Keyspace hat Attribute, die sein Verhalten beschreiben.

A.4.5 Table, Column Family

Eine Table enthalt sortierte Rows. Sie muss einen Primary Key (PK) haben. Die Sortierungwird durch die PK-Columns bestimmt. Wenn eine neue Row angelegt wird, mussen mindestensValues fur die PK-Columns angegeben werden. Alle anderen Column-Values sind optional.

Jeder Zeit kann fur eine Tabelle eine zusatzliche Column definiert werden.

A.4.6 Column

Die Basis-Einheit einer Daten-Struktur in Cassandra ist die Column. Sie enthalt Name undValue. Wir nennen das auch eine Zelle. Der Value hat einen Type. Zwei weitere Attribute derColumn sind Timestamp und Time to live.

Timestamp

Jedesmal wenn eine Zelle (Name/Value-Pair) geschrieben oder aktualisiert wird, wird ein Time-stamp (in Millisekunden) generiert. Damit werden Schreib-Konflikte gelost. Im allgemeinen giltder letzte Timestamp.

Den Timestamp kann man sich ausgegeben lassen:

SELECT vorname, nachname, writetime(nachname) FROM stud;

Fur PRIMARY KEYs oder Teile davon ist das allerdings nicht erlaubt!

Es ist moglich den Timestamp selbst zu setzen:

UPDATE stud USING TIMESTAMP 1234567890123456

SET nachname=’Maler’ WHERE vorname=’Oskar’;

Dabei muss der Timestamp in der Zukunft liegen. Diese Moglichkeit sollte mit Vorsicht verwendetwerden.

A.5. DATENTYPEN IN CQL 7

Time to live (TTL)

Fur jede Zelle, die nicht zum Primary Key gehort, kann eine Lebenszeit in Sekunden definiertwerden. Die Default-Lebenszeit ist unendlich (TTL-Wert = 0). Diese Lebenszeit kann gesetztwerden, wenn eine Zelle eingefugt oder aktualisiert wird.

INSERT INTO stud (vorname, nachname) VALUES (’Jos’, ’Mayhof’) USING TTL 3600;

SELECT vorname, nachname, ttl(nachname) FROM stud;

UPDATE stud USING TTL 3600 SET nachname=’Mayerhofer’ WHERE vorname=’Jos’;

SELECT vorname, nachname, ttl(nachname) FROM stud;

A.5 Datentypen in CQL

A.5.1 Numerische Datentypen

int: 32-bit signed integer

bigint: 64-bit signed integer

smallint: 16-bit signed integer

tinyint: 8-bit signed integer

varint: variable precision signed integer

float: 32-bit IEEE-754 floating point

double: 64-bit IEEE-754 floating point

decimal: variable precision decimal

A.5.2 Textuelle Datentypen

text: UTF-8 character string

varchar: synonym fur text

ascii: ASCII character string

A.5.3 Zeit- und Identitats-Datentypen

timestamp:

date:

time:


uuid: Ein UUID-Identifikator ist ein Typ-4 128-bit-Wert, der ganz von Zufallszahlen abhangt.Beispiel:

ALTER TABLE stud ADD id uuid;

UPDATE stud SET id=uuid() WHERE vorname=’Oskar’;

SELECT vorname, id FROM stud WHERE vorname=’Oskar’;

timeuuid: Dieser Identifikator ist ein Typ-1 128-bit-Wert und beruht auf der MAC-Adresse desRechners, der System-Zeit und einer laufenden Nummer. Außer der Erzeugungsfunktionnow() gibt es noch dateOf() und unixTimestampOf(), die offenbar der Grund dafur sind,dass dieser Identifikator haufig benutzt wird. Beispiel:

ALTER TABLE stud ADD tid timeuuid;

UPDATE stud SET tid=now() WHERE vorname=’Oskar’;

SELECT vorname, tid FROM stud WHERE vorname=’Oskar’;

SELECT vorname, tid, dateOf(tid), unixTimestampOf(tid)

FROM stud WHERE vorname=’Oskar’;

uuid oder timeuuid sollten fur Columns des Primary Keys verwendet werden.

Primary Keys konnen nie geandert werden! (Die Idiotie, in der Tabelle stud als Primar-Schlussel vorname genommen zu haben, kann nachtraglich nicht verbessert werden!)

A.5.4 Andere einfache Datentypen

boolean:

blob:

inet:

counter:

A.5.5 Collection-Datentypen

Die Elemente der Collections konnen einfache Typen sein, aber auch Collections und Benutzer-definierte Typen.

set: Die Elemente von set sind nicht sortiert. (Die Ausgabe erfolgt allerdings sortiert.) Beispielmehrere Email-Adressen:

ALTER TABLE stud ADD emails set<text>;

UPDATE stud SET emails={’[email protected]’} WHERE vorname=’Oskar’;

SELECT vorname, emails FROM stud WHERE vorname=’Oskar’;

UPDATE stud SET emails=emails + {’[email protected]’} WHERE vorname=’Oskar’;


UPDATE stud SET emails=emails - {’[email protected]’} WHERE vorname=’Oskar’;


A.5. DATENTYPEN IN CQL 9

UPDATE stud SET emails={} WHERE vorname=’Oskar’;


list: Eine Liste enthalt die Elemente in der Reihenfolge, in der sie addiert werden. Beispielmehrere Telefon-Nummern:

ALTER TABLE stud ADD telefone list<text>;

UPDATE stud SET telefone=[’12345’] WHERE vorname=’Oskar’;

SELECT vorname, telefone FROM stud WHERE vorname=’Oskar’;

UPDATE stud SET telefone=telefone + [’0345-672’] WHERE vorname=’Oskar’;


UPDATE stud SET telefone=[’345123’] + telefone WHERE vorname=’Oskar’;


UPDATE stud SET telefone=telefone - [’12345’] WHERE vorname=’Oskar’;


Listen-Elemente konnen uber den Index referenziert werden:UPDATE stud SET telefone[1]=’0345-672666’ WHERE vorname=’Oskar’;


DELETE telefone[0] FROM stud WHERE vorname=’Oskar’;


map: Eine Map kann Key/Value-Paare speichern. Außer counter konnen alle Datentypen alsKey oder als Value verwendet werden. Als Beispiel nehmen wir Temperaturwerte abhangigvon der Zeit:

ALTER TABLE stud ADD temperatur map<timeuuid, float>;

UPDATE stud SET temperatur={now(): 37.3, now(): 40.5} WHERE vorname=’Oskar’;

SELECT vorname, temperatur FROM stud WHERE vorname=’Oskar’;

Man kann Map-Elemente auch uber ihren Key referenzieren.

A.5.6 Benutzer-definierte Datentypen (UDT)

Man kann eigene Strukturen als Datentypen (User Defined Type, UDT) definieren. AlsBeispiel nehmen wir die Adresse:

CREATE TYPE adresse (strasse text, stadt text, plz int);

ALTER TABLE stud ADD adressen map<text, frozen<adresse>>;

Das frozen ist ein Mechanismus, der wegen Upward-Compatibility bis zu einer neueren Versionvon Cassandra noch zu verwenden ist.

Und jetzt noch eine komplexere Struktur – ein Modul mit seinen Units:CREATE TYPE unit (nummer text, titel text, note tinyint);


CREATE TYPE modul (nummer text, titel text, units frozen<list<frozen<unit>>>);

ALTER TABLE stud ADD module map<text, frozen<modul>>;

UPDATE stud SET module = module + {’DBII’:{nummer: ’4304’, titel: ’Datenbanken II’,

units: [{nummer: ’1’, titel: ’DBIM’, note: 18},{nummer: ’2’, titel: ’DWH/DM’, note: 23}]}}

WHERE vorname=’Oskar’;

SELECT vorname, module FROM stud WHERE vorname=’Oskar’;

Die UDTs erscheinen dann in der Keyspace-Definition:DESCRIBE KEYSPACE bsp;

A.6 Sekundar-Indexe

Von relationalen DB-Systemen sind wir gewohnt, Suchbedingungen auf Nicht-Schlussel-Attributen zu formulieren. In Cassandra geht das nur mit dem Zusatz ALLOW FILTERING, wobeiman allerdings Performanzeinbußen riskiert.

Wenn wir das in Cassandra performant machen wollen, mussen wir erst einen Index auf solcheinem Nicht-Schlussel-Attribut (d.h. Nicht-Schlussel-Column) definieren. Ab Cassandra 3.4sollte man SASI-Indexe (SSTable Attached Secondary Index) verwenden:

CREATE CUSTOM INDEX ON stud (nachname)

USING ’org.apache.cassandra.index.sasi.SASIIndex’;

MitDESCRIBE KEYSPACE bsp;

sehen wir den Index. Und nun sind Anfragen wie folgende moglich:SELECT * FROM stud WHERE nachname LIKE ’Ma%’;

A.7 Daten-Modellierung

A.7.1 Begriffe, Design-Prinzipien, Notation

Key, Schlussel: In Cassandra werden verschiedene Keys (Primary Key, Partition Key, Sim-ple Key, Composite Key, Compound Key, Clustering Key) verwendet, deren Bedeutungzunachst geklart werden soll.

• Simple Key: Der Key besteht aus einer Column.

• Composite (= Compound) Key: Der Key besteht aus mehreren Columns (Mul-tiple Column Key).

Jeder Key kann simple oder composite sein.

A.7. DATEN-MODELLIERUNG 11

• Primary Key: Identifiziert eine Row einer Tabelle eindeutig. Wird in CQL mitPRIMARY KEY

spezifiziert. Wenn der Primary Key aus mehreren Columns besteht, spielt die Reihen-folge der Columns eine Rolle (siehe Partition Key).

• Partition Key: Identifiziert die Rows einer Tabelle, die physisch auf einem Knotendes Clusters gespeichert werden sollen. Wenn der Partition Key simple ist, dann istes die erste Column der Primary-Key-Spezifikation.

Bei einem composite Partition Key werden die dazugehorigen Columns bei derPrimary-Key-Spezifikation zusatzlich geklammert, z.B.:

PRIMARY KEY ((c1, c2), c3, c4, c5)

Der Partition Key wird dann durch c1 und c2 gebildet. Alle Rows mit denselbenWerten fur (c1, c2) werden auf einem Knoten gespeichert.

• Clustering Key: Sind alle Nicht-Partition-Key-Columns des Primary Keys. Mit ih-nen kann eine Sortierung der zu einer Partition gehorigen Rows definiert werden.

Weiter Beispiele:

• PRIMARY KEY (a): Partition Key ist a.

• PRIMARY KEY (a, b): Partition Key ist a, Clustering Key ist b.

• PRIMARY KEY (a, b, c): Partition Key ist a, Composite Clustering Key ist (b, c).

• PRIMARY KEY ((a, b), c):Composite Partition Key ist (a, b), Clustering Key ist c.

• PRIMARY KEY ((a, b), c, d):Composite Partition Key ist (a, b), Composite Clustering Key ist (c, d).

Die WHERE-Klausel eines SELECTs muss mindestens den Partition Key enthalten. WeitereColumns des Primary Keys konnen nur in der definierten Reihenfolge hinzugenommen wer-den. Columns durfen dabei nicht ubersprungen werden. Z.B. mit oben definiertem PrimaryKey:

• Richtig:c1 and c2

c1 and c2 and c3

c1 and c2 and c3 and c4

• Falsch:c1 and c2 and c4

alles ohne c1 and c2

Wide Row: Es gibt wide und skinny Rows. Die skinny Row ist vergleichbar mit einer Zeileeiner Tabelle einer RDB, hat also eine eher begrenzte Anzahl Spalten.

Eine wide Row aber kann sehr viele – tausende – Columns haben, deren Anzahl undNamen von Row zu Row sehr unterschiedlich sein kann. Fur eine Row werden nur dieColumns gespeichert, die auch Werte haben. Das Resultat ist eine dunnbesetzte (sparse),multidimensionale Struktur.

Normalisierung, Joins: In CQL sind keine Joins moglich, um die Information aus normali-sierten Tabellen zusammenzufuhren.


Entweder wird das irgendwie durch die Anwendung realisiert, oder man muss denormali-sierte Tabellen erzeugen, die Join-Resultate reprasentieren. Letztere Option ist vorzuzie-hen, wobei naturlich Daten dupliziert werden.

Referenzielle Integritat hat fur Cassandra keine Bedeutung.

Denormalisierung: In RDBs wird manchmal wegen Performanz denormalisiert. Ein zweiterGrund ist, dass man, um etwa die Historie zu dokumentieren, einen Schnappschuss vonTeilen einer Tabelle benotigt, die viele andere Tabellen referenziert.

Neben denormalisierten Tabellen bietet Cassandra auch Materialized Views. Diese Viewswerden automatisch mit den zu Grunde liegenden Tabellen synchronisiert.

Query-first Design: Bei einem RDBS liefern die Entitaten normalisierte Tabellen (Entity-first Design) und Relationships eventuell Join-Tabellen. Anfragen sind zunachst eherzweitrangig.

Wie aber kommt man in Cassandra zu Tabellen? Man startet nicht mit einem Datenmodell,sondern mit einem Anfrage- oder Query-Modell. Zuerst muss also eine Liste von Querieserstellt werden, mit der dann Tabellen definiert werden.

Optimal Storage Design: Bei RDB spielt auf Design-Ebene die Speicherstruktur fast keineRolle.

Bei Cassandra wird man versuchen, zusammengehorige Columns in einer Tabelle zu defi-nieren. Ein wichtiges Prinzip ist, die Anzahl der Partitionen, die durch eine Query betroffensind, zu minimieren, da die Partition eine Speichereinheit ist, die nicht uber mehrere Knotenverteilt wird.

Sortieren ist eine Design-Entscheidung. Die Sortierung wird bestimmt durch die Wahl derClustering-Columns.

Als Beispiel werden wir im folgenden ein Hotel-Buchungs-System (HBS) behandeln. Das Beispielorientiert sich an dem Beispiel im Buch von Carpenter und Hewitt[6], vermeidet aber verschiedeneFehler dort.

A.7.2 HBS: Systembeschreibung

Das Hotel-Buchungs-System (HBS) verwaltet Hotels, deren Zimmer von Gasten gebucht werdenkonnen.

Die Hotels befinden sich in der Nahe von Points of Interest (POI, Sehenswurdigkeit). DieHotels haben einen Namen, eine Telefonnummer und eine Adresse. Ferner haben sie mehrereZimmer zu vermieten.

Die POIs haben einen Namen und eine Beschreibung.

Jedes Zimmer hat eine Nummer, ist frei oder nicht, bietet verschiedene Annehmlichkeiten(Vorzuge) und hat einen Preis, der vom Datum abhangt.

Ein Gast mit Vor- und Nachname, Adressen und Telefonnummern kann in einem Hotel ein odermehrere Zimmer buchen. Eine Buchung hat ein Startdatum, ein Endedatum und eine Bestaeti-gungsnummer.

Die Adresse besteht aus Straße, Stadt, Region, PLZ und Land.


A.7.3 HBS: Relationales Datenmodell

Das Design von relationalen Datenbanksystemen beruht auf der Erstellung eines Entity-Relationship-Diagramms (E/R). Die Systembeschreibung gibt dabei Hinweise auf die Entitaten(Substantive) und ihre Attribute (Eigenschaften der Substantive) und die Beziehungen zwischenEntitaten (Verben oder oft Substantive mit Endung ”-ung”).

Fur ein RDBS wurde man etwa folgendes E/R-Diagramm (in UML-Notation) erstellen:

HotelName

Telefon

:Adresse

*

*

PoiNameBeschreibung

*

ZimmerNummer

*

*

VorzugBeschreibung

Verfuegbarkeit

Frei :boolean:Datum

Preis :int

GastVorname

Nachname

Titel:Adresse[*]

Telefon[*]

*

BuchungBestaetigung

Start :Datum

Ende :Datum

*

AdresseStrasse

StadtRegion

PLZ

Land

DatumJahr :intMonat :intTag :int

ist in der Nahe


Bemerkungen:

• Attribute ohne Typ-Angabe sind Strings.

• ”Verfuegbarkeit” ist eine etwas merkwurdig Bezeichnung fur den Tag, an dem ein Zimmergebucht werden kann.

• Ein Gast bucht nicht Zimmer, sondern die Verfuegbarkeiten eines Zimmers oder mehrererZimmer.

• Der Preis eines Zimmers kann sich von Tag zu Tag andern.

• Die Buchung hat die Verfuegbarkeiten als Aggregat, da eine Verfuegbarkeit zwar nur zuhochstens einer Buchung gehoren kann, aber die Buchung wechseln kann bzw. nicht mehrgebucht sein kann.

Das E/R-Modell fur dieses System war relativ problemlos zu erstellen. Die Umsetzung in Tabellenfolgt einem Automatismus. Moglicherweise ist die Formulierung von Anfragen (z.B. ob ein Hotelnoch ein Zimmer frei hat) nicht ganz trivial.

Fur ein Column-Family-Modell sind zunachst ein Query-Modell und dann insgesamt drei Daten-modelle zu erstellen: Logisches, physisches und Implementierungs-Datenmodell.


A.7.4 HBS: Definition der Queries

Im ersten Design-Schritt muss ermittelt werden, wie die Datenbank verwendet wird (Use-Case-Driven).

Wahrscheinlich sind folgende Anfragen zu erwarten:

• A1: Finde Hotels, deren Namen und Adresse in der Nahe eines POI (Point of Interest,Sehenswurdigkeit).

• A2: Finde mehr Informationen wie Telefon und Beschreibung uber ein Hotel.

• A3: Finde POIs in der Nahe eines Hotels.

• A4: Finde freie Zimmer in einem Datumsfenster.

• A5: Finde Preis und Annehmlichkeiten (Vorzuge) eines Zimmers.

• A6: Finde eine Buchung zu einer Bestatigungsnummer.

• A7: Finde eine Buchung uber Hotel, Datum und Zimmernummer

• A8: Finde alle Buchungen eines Gastes (Nachname).

• A9: Finde Informationen uber einen Gast.

Folgendes Diagramm zeigt die Anfragen, die sich aus einem moglichen dem Workflow (Ablauf,Arbeitsfluss) der HBS-Anwendung ergeben:


ViewHotels in

der Nahe von

POI

A1

ViewInfo von

Hotel

A2

ViewPOIs in

der Nahe von

Hotel

A3

FreieRaume ingegebenem

Hotel

A4

Detailseines

Raums

A5

Bucheeinen

Raum

ViewBuchung

zu einerBuchungs-

nummer

A6

ViewBuchungen

zu einem

Gast(Nachname)

A8

ViewBuchungen

zu

Datum

Hotel

undZimmernummer

A7

ViewDetailseines

Gastes

A9A9

A9


A.7.5 HBS: Logisches Datenmodell

Fur jede oben definierte Query wird eine Tabelle entworfen. Eine Query hat zwei Teile:

– Suchziel (Was wird gesucht? z.B. hotels)und– Suchkriterien (z.B. ein POI bzw. Inhalt einer WHERE-Klausel)

Eine vernunftige Art, den Namen der Query-Tabelle zu definieren, ist:

Tabellenname = suchziel_by_suchkriterium

• Das Suchkriterium definiert den Primarschlussel i.a. bestehend aus Partition und ClusteringKey Columns. Dadurch wird Eindeutigkeit garantiert und eine gewisse Sortierung definiert.

• Die ubrigen Non-Key Columns definieren das Suchziel.

• Attribute, die fur jede Instanz des Partition Keys den gleichen Wert haben, stehen in einerstatic Column.

Als Notation verwenden wir Chebotko-Diagramme (Artem Chebotko). Ein Chebotko LogicalDiagram folgende allgemeine Struktur:

Column_name_1

Column_name_2

Column_name_3

Column_name_4

Column_name_5

Column_name_6

Column_name_7

Column_name_8

K

K

K

C\

C/

C

S

Table_name_1

Q1 durch Tabelle 1 unterstutzte Query

Partition Key Column

Clustering Key Column (DESC)

Clustering Key Column (ASC)

Clustering Key Column

Static (Non-Key) Column

Andere (Non-Key) Column

... K

Table_name_2

Q2 Downstream Queries


Folgendes Chebotko-Diagramm zeigt die Tabellen, die etwas mit Hotels zu tun haben:

poiname

hoteloidname

adresse

K

C/

hotels_by_poi

A1

oidname

telefon

adressebeschreibung

K

hotels

A2

hoteloidpoiname

beschreibung

K

C/

pois_by_hotelA3

hoteloid

datumzimmernummer

frei

K

C/

C/

freie_zimmer_by_hotel_datum

A4

hoteloidzimmernummervorzugname

beschreibung

K

K

C/

vorzuege_by_zimmer

A5

Tabelle hotels_by_poi reprasentiert Query A1, wo nach Hotels in der Nahe eines POI ge-sucht wird. Das Suchkriterium ist POI. Wir nehmen poi in den Partition Key auf. DasSuchziel sind Hotels mit den Attributen Name, Telefon und Adresse. Diese Attribute neh-men wir als Non-Key Columns auf.

Da es zu einem POI mehr als ein Hotel geben kann, ist unser Primary Key noch nichteindeutig. Um ihn eindeutig zu machen, nehmen wir noch die Hotel-ID hoteloid als Clu-stering Key auf. Eindeutige Primary Keys sind wichtig, da man sonst das Uberschreibenvon Daten riskiert.

Tabelle hotels (Query A2) sucht detailierte Informationen uber ein Hotel. Suchkriterium istdie Hotel-ID hoteloid. Wir hatten diese Infromationen auch in die Tabelle hotels_by_poiaufnehmen konnen. Aber um unserem Workflow Genuge zu tun, haben wir dort nur Nameund Adresse aufgenommen.

In Tabelle pois_by_hotel (Query A3) haben wir wieder poiname als Cluster Key Columnhinzugenommen, um Eindeutigkeit des Schlussels zu erreichen.


Mit Tabelle freie_zimmer_by_hotel_datum (Query A4) suchen wir nach freien Zimmern ineinem Datumsbereich. Deshalb definieren wir das Datum auf jeden Fall als aufsteigendsortierte (ASC) Clustering Key Column.

Tabelle vorzuege_by_zimmer (Query A5) gibt uns detailierte Informationen – nach Namenaufsteigend sortiert – uber ein Hotelzimmer.

Das folgende Chebotko-Diagramm zeigt das logische Design der Tabellen, die mit der Reservie-rung von Hotelzimmern zu tun haben:

hoteloid

startdatumzimmernummer

endedatumbestaetigung

gastoid

K

K

C/

buchungen_by_hotel_datum

A7

gastnachname

hoteloidzimmernummer

startdatum


gastoid

K

C/

C/

C/

buchungen_by_gast

A8

bestaetigung


startdatum

endedatumgastoid

K

C/

buchungen_by_bestaetigung

A6

gastoidvorname

nachname

titel

email

telefone

adressen

K

gaesteA9

A9

A9

Tabelle buchungen_by_bestaetigung (Query A6) soll zu einer Bestatigung die Buchungsda-ten liefern. Das Suchkriterium ist also die Bestatigung. Sie wird zum Partition Key. Diehoteloid wird als aufsteigender Clustering Key dazugenommen, um den Primary Keyeindeutig zu machen.


Tabelle buchungen_by_hotel_datum (Query A7) liefert Buchungsdaten fur ein Hotel undStartdatum. Hotel und Startdatum bilden daher den Partition Key, der sicher nicht ein-deutig ist, aber mit der Zimmernummer als Clustering Key eindeutiger Primary Key wird.

Tabelle buchungen_by_gast (Query A8) gibt zu einem Gastnamen die Buchungsdaten, ins-besondere auch die gastoid, mit der wir die Downstream-Query machen konnen.

Tabelle gaeste (Query A9) wird Downstream von A6, A7 und A8 zur Ermittlung von Gastda-ten mittels der gastoid verwendet.

A.7.6 HBS: Physisches Datenmodell

Das Physische Modell erganzt die Column-Namen um CQL-Typen. Fur mehrwertige Columnswerden passende Collections definiert.

Insbesondere werden Keyspaces definiert. Bequem ist es zwar, nur einen einzigen Keyspace zudefinieren. Die Design-Empfehlung lautet allerdings, mit Keyspaces nicht zu sparen, um verschie-dene Belange (concerns) zu trennen. Im Beispiel HBS trennen wird Hotels und Buchungen durchDefinition der beiden Keyspaces hotel und buchung.

Das physische Datenmodell kann in einem Chebotko Physical Diagram dargestellt werden,das folgende allgemeine Form hat:

<<Keyspace>>

keyspace_name

CQL-Type

CQL-Type

CQL-Type

CQL-Type

CQL-Type

CQL-Type

CQL-Type

CQL-Type

CQL-Type

CQL-Type

UDT-NameCQL-Type

CQL-Type

Column_name_1

Column_name_2

Column_name_3

Column_name_4

Column_name_5

Column_name_6

Column_name_7[Column_name_8]

{Column_name_8}<Column_name_10>

*Column_name_11*(Column_name_12)

Column_name_13

K

C/

C\

C

S

IDX

++

Table_name

Partition Key Column

Clustering Key Column (ASC)

Clustering Key Column (DESC)

Clustering Key Column

Static ColumnSecondary Index Column

Counter Column

List Collection Column

Set Collection ColumnMap Collection Column

UDT ColumnTuple Column

Regular Column

Bemerkungen:

Identifikatoren: Es ist i.a. sinnvoll, uuid oder timeuuid als Identifikatoren zu verwenden.Aber es ist nicht verboten, eigene Text-IDs zu definieren, wie es hier in diesem Beispiel oft


gemacht wird. Diese sind allerdings nicht notwendig global eindeutig, bzw. die Anwendungmuss fur Eindeutigkeit sorgen.

Typ text ist ziemlich universell einsetzbar und daher auch fur viele scheinbar numerische Co-lumns wie Telefonnummern zu empfehlen. In unserem Beispiel haben wir fur die Zimmer-nummer ein smallint verwendet, was sich sicher rachen wird.

UDT: Ein User Defined Type ist nur in einem Keyspace gultig. Wenn er in anderen Keyspacesauch verwendet wird, muss er dort auch definiert werden. In unserem Beispiel wird derUDT adresse zweimal definiert. Das ist eine lastige Redundanz.


Chebotko Physical Diagram fur Keyspace hotel:

<<Keyspace>>

hotel

text

text

text

*adresse*text

oidname

telefon

adressebeschreibung

K

hotelstext

smallinttext

text

hoteloidzimmernummervorzugname

beschreibung

K

K

C/

vorzuege_by_zimmer

text

text

text

text

text

strasse

stadtregion

plz

land

*adresse*

text

text

text

*adresse*

poiname

hoteloidname

adresse

K

C/

hotels_by_poi

text

text

text

hoteloidpoiname

beschreibung

K

C/

pois_by_hotels

text

date

smallint

boolean

hoteloid

datumzimmernummer

frei

K

C/

C/

freie_zimmer_by_hotel_datum


Chebotko Physical Diagram fur Keyspace buchung:

Das Chebotko Logical Diagram fur den Keyspace buchung hat drei Tabellen mit Buchungen alsSuchziel. Die Daten einer Buchung (z.B. das Endedatum) werden in den drei Tabellen redundantgefuhrt. Diese Redundanz muss die Anwendung verwalten, wenn wir die logischen Tabellen alsregulare Tabellen implementieren. Unter Cassandra gibt es aber auch die Moglichkeit einigedieser Tabellen als sogenannte Materialized Views (siehe unten) zu definieren.

In unserem Keyspace buchung werden wir die Tabellen buchungen_by_gast undbuchungen_by_hotel_datum als regulare Tabellen implementieren. Die Tabellebuchungen_by_bestaetigung implementieren wir als materialisierten View der Tabellebuchungen_by_hotel_datum. Das wird verdeutlicht durch kursive Schreibweise und einengestrichelten Pfeil zur Basis-Tabelle.

<<Keyspace>>

buchung

text

date

smallint

datetext

uuid

hoteloid



gastoid

K

K

C/

buchungen_by_hotel_datum

text

text

smallint

date

datetext

uuid

gastnachname


startdatum


gastoid

K

C/

C/

C/

buchungen_by_gast

text

text

date

smallint

date

uuid

bestaetigung

hoteloid


endedatumgastoid

K

C/

C/

C/

buchungen_by_bestaetigung

uuidtext

text

text

text

texttext, *adresse*

gastoidvorname

nachname

titel{email}[telefone]

<adressen>

K

gaeste

text

text

text

text

text

strasse

stadtregion

plz

land

*adresse*

Die Tabelle gaeste liefert Beispiele fur die Collection-Datentypen set, list und map.


Materialized Views

Cassandra ubernimmt die Verantwortung fur die Konsistenz der materialisierten Views zur refe-renzierten Basis-Tabelle. Die CQL-Sytax ist etwa:

CREATE MATERIALIZED VIEW <viewTable> AS

SELECT * FROM <baseTable>

WHERE <anyColumn> IS NOT NULL

AND <baseTablePrimaryKeyColumn> IS NOT NULL ...

PRIMARY KEY ((<anyColumn>), <all baseTablePrimaryKeyColumns> );

Der Primary Key des Views muss mindestens den ganzen Primary Key der Basis-Tabelle enthal-ten. Als Partition Key wird normalerweise eine zusatzliche Column (hier anyColumn) genommen.In Zukunft sind wahrscheinlich auch mehrere Columns moglich.

Anstatt SELECT * kann naturlich auch eine Auswahl an Columns getroffen werden, solange derPrimary Key der Basis-Tabelle enthalten ist.

In unserem Beispiel lohnt sich der materialisierte View insbesondere deshalb, weil die Columnbestaetigung eine hohe Kardinalitat hat.

Die Konsistenzerhaltung hat zwar Performanzkosten, die aber durch Ersparnisse in der Anwen-dung normalerweise mehr als ausgeglichen werden.


A.7.7 HBS: CQL-Implementierungs-Datenmodell

Implementierung des Chebotko-Diagramms fur Keyspace hotel:

CQL-Datei: hotel.cql

CREATE KEYSPACE IF NOT EXISTS hotelWITH replication = {’class’: ’SimpleStrategy’, ’replication_factor’: 3};

USE hotel;

CREATE TYPE IF NOT EXISTS adresse (strasse text,stadt text,region text,plz text,land text

);

CREATE TABLE IF NOT EXISTS hotels_by_poi (poiname text,hoteloid text,name text,adresse frozen<adresse>,PRIMARY KEY ((poiname), hoteloid)

) WITH comment = ’A1: Finde alle Hotels in der Nahe eines POIs’AND CLUSTERING ORDER BY (hoteloid ASC);

CREATE TABLE IF NOT EXISTS hotels (oid text PRIMARY KEY,name text,telefon text,adresse frozen<adresse>,beschreibung text

) WITH comment = ’A2: Finde Info uber ein Hotel (? pois set<text>)’;

CREATE TABLE IF NOT EXISTS pois_by_hotel (hoteloid text,poiname text,beschreibung text,PRIMARY KEY ((hoteloid), poiname)

) WITH comment = ’A3: Finde POIs in der Nahe eines Hotels’;

CREATE TABLE IF NOT EXISTS freie_zimmer_by_hotel_datum (hoteloid text,datum date,zimmernummer smallint,frei boolean,PRIMARY KEY ((hoteloid), datum, zimmernummer)

) WITH comment = ’A4: Finde freie Zimmer eines Hotels an einem Datum’;

CREATE TABLE IF NOT EXISTS vorzuege_by_zimmer (hoteloid text,zimmernummer smallint,vorzugname text,beschreibung text,PRIMARY KEY ((hoteloid, zimmernummer), vorzugname)

) WITH comment = ’A5: Finde Vorzuge eines Zimmers in einem Hotel’;


Implementierung des Chebotko-Diagramms fur Keyspace buchung:

CQL-Datei: buchung.cql

CREATE KEYSPACE IF NOT EXISTS buchungWITH replication = {’class’: ’SimpleStrategy’, ’replication_factor’: 3};

USE buchung;

CREATE TYPE IF NOT EXISTS adresse (strasse text,stadt text,region text,plz text,land text

);

CREATE TABLE IF NOT EXISTS buchungen_by_hotel_datum (hoteloid text,startdatum date,zimmernummer smallint,endedatum date,bestaetigung text,gastoid uuid,PRIMARY KEY ((hoteloid, startdatum), zimmernummer)

) WITH comment = ’A7: Finde Buchungen in einem Hotel an einem Start-Datum’;

CREATE MATERIALIZED VIEW IF NOT EXISTS buchungen_by_bestaetigung ASSELECT * FROM buchungen_by_hotel_datumWHERE bestaetigung IS NOT NULL AND hoteloid IS NOT NULL

AND startdatum IS NOT NULL AND zimmernummer IS NOT NULLPRIMARY KEY (bestaetigung, hoteloid, startdatum, zimmernummer);

CREATE TABLE IF NOT EXISTS buchungen_by_gast (gastnachname text,hoteloid text,zimmernummer smallint,startdatum date,endedatum date,bestaetigung text,gastoid uuid,PRIMARY KEY ((gastnachname), hoteloid, zimmernummer, startdatum)

) WITH comment = ’A8: Finde Buchungen eines Gastes mit Nachname.’;

CREATE TABLE IF NOT EXISTS gaeste (gastoid uuid PRIMARY KEY,vorname text,nachname text,titel text,emails set<text>,telefone list<text>,adressen map<text, frozen<adresse>>

) WITH comment = ’A9: Finde Gast mit OID.’;


Abfullung von Beispiel-Daten im Keyspace hotel:

CQL-Datei: hoteldaten.cql

USE hotel;

INSERT INTO hotels (oid, name, telefon, adresse, beschreibung)VALUES (’ul1’, ’Donaublick’, ’0731-68376’,

{strasse: ’Fritz-Mayer-Str. 12’, stadt: ’Ulm’,region: ’Baden-Wurttemberg’, plz: ’89070’, land: ’Germany’},’Jedes Hotelzimmer bietet einen wundervollen Blick auf die Donau.’);

INSERT INTO hotels (oid, name, telefon, adresse, beschreibung)VALUES (’ul2’, ’Gasthof am Munster’, ’0731-384729’,

{strasse: ’Munsterplatz 7’, stadt: ’Ulm’,region: ’Baden-Wurttemberg’, plz: ’89060’, land: ’Germany’},’Jedes Hotelzimmer bietet einen wundervollen Blick auf das Munster.’);

INSERT INTO hotels (oid, name, telefon, adresse, beschreibung)VALUES (’s1’, ’Maritim’, ’0711-863835’,

{strasse: ’Augustenstr. 51’, stadt: ’Stuttgart’,region: ’Baden-Wurttemberg’, plz: ’78156’, land: ’Germany’},’Wir sind ein Luxushotel und haben nur sehr teure Zimmer.’);

INSERT INTO hotels_by_poi (poiname, hoteloid, name, adresse)VALUES (’donau’, ’ul1’, ’Donaublick’,

{strasse: ’Fritz-Mayer-Str. 12’, stadt: ’Ulm’,region: ’Baden-Wurttemberg’, plz: ’89070’, land: ’Germany’});

INSERT INTO hotels_by_poi (poiname, hoteloid, name, adresse)VALUES (’ulmue’, ’ul1’, ’Donaublick’,

{strasse: ’Fritz-Mayer-Str. 12’, stadt: ’Ulm’,region: ’Baden-Wurttemberg’, plz: ’89070’, land: ’Germany’});

INSERT INTO hotels_by_poi (poiname, hoteloid, name, adresse)VALUES (’donau’, ’ul2’, ’Gasthof am Munster’,

{strasse: ’Munsterplatz 7’, stadt: ’Ulm’,region: ’Baden-Wurttemberg’, plz: ’89060’, land: ’Germany’});

INSERT INTO hotels_by_poi (poiname, hoteloid, name, adresse)VALUES (’ulmue’, ’ul2’, ’Gasthof am Munster’,

{strasse: ’Munsterplatz 7’, stadt: ’Ulm’,region: ’Baden-Wurttemberg’, plz: ’89060’, land: ’Germany’});

INSERT INTO hotels_by_poi (poiname, hoteloid, name, adresse)VALUES (’sfst’, ’s1’, ’Maritim’,

{strasse: ’Augustenstr. 51’, stadt: ’Stuttgart’,region: ’Baden-Wurttemberg’, plz: ’78156’, land: ’Germany’});

INSERT INTO pois_by_hotel (hoteloid, poiname, beschreibung)VALUES (’ul1’, ’donau’,

’Die blaue Donau ist mit 2800 km der langste Fluss Europas.’);INSERT INTO pois_by_hotel (hoteloid, poiname, beschreibung)

VALUES (’ul1’, ’ulmue’,’Das Ulmer Munster ist mit 168 Metern der hochste Kirchturm Europas.’);

INSERT INTO pois_by_hotel (hoteloid, poiname, beschreibung)VALUES (’ul2’, ’donau’,

’Die blaue Donau ist mit 2800 km der langste Fluss Europas.’);INSERT INTO pois_by_hotel (hoteloid, poiname, beschreibung)

VALUES (’ul2’, ’ulmue’,’Das Ulmer Munster ist mit 168 Metern der hochste Kirchturm Europas.’);

INSERT INTO pois_by_hotel (hoteloid, poiname, beschreibung)VALUES (’s1’, ’sfst’,

’Der Stuttgarter Fernsehturm ist mit 211 Metern der hochste Turm in BW.’);

INSERT INTO vorzuege_by_zimmer (hoteloid, zimmernummer, vorzugname, beschreibung)

VALUES (’ul1’, 11, ’Mobiliar’,’Dieser Zimmer ist im Stil des Barock mobliert.’);

INSERT INTO vorzuege_by_zimmer (hoteloid, zimmernummer, vorzugname, beschreibung)

VALUES (’ul1’, 11, ’Aussicht’,’Dieser Zimmer hat einen wundervollen Blick auf den Reitstall.’);

INSERT INTO freie_zimmer_by_hotel_datum (hoteloid, datum, zimmernummer, frei)

VALUES (’ul1’, ’2016-11-09’, 11, True);INSERT INTO freie_zimmer_by_hotel_datum (


hoteloid, datum, zimmernummer, frei)VALUES (’ul1’, ’2016-11-10’, 11, False);

INSERT INTO freie_zimmer_by_hotel_datum (hoteloid, datum, zimmernummer, frei)

VALUES (’ul1’, ’2016-11-11’, 11, False);


Abfullung von Beispiel-Daten im Keyspace buchung:

CQL-Datei: buchungdaten.cql

USE buchung;

INSERT INTO gaeste (gastoid, vorname, nachname, titel, emails, telefone, adressen)VALUES (uuid(), ’Finn’, ’Ledford’, ’Herr Prof. Dr.’, {’fi@super’, ’fl@boston’},

[’0761-373641’, ’07071-2316’, ’0711-8729’],{’home’: {strasse: ’Bahnhof-Str. 50’, stadt: ’Freiburg’,region: ’Baden-Wurttemberg’, plz: ’78071’, land: ’Germany’},’arbeit’: {strasse: ’Immental-Str. 16’, stadt: ’Freiburg’,region: ’Baden-Wurttemberg’, plz: ’78073’, land: ’Germany’}});

INSERT INTO buchungen_by_hotel_datum (hoteloid, startdatum, zimmernummer,endedatum, bestaetigung, gastoid)

VALUES (’ul1’, ’2016-11-09’, 11, ’2016-11-15’, ’ul116-11-09’,2f0b0441-f0be-46d1-a393-be9c94bf45c1);

INSERT INTO buchungen_by_gast (gastnachname, hoteloid, zimmernummer, startdatum,endedatum, bestaetigung, gastoid)

VALUES (’Ledford’, ’ul1’, 11, ’2016-11-09’, ’2016-11-15’, ’ul116-11-09’,2f0b0441-f0be-46d1-a393-be9c94bf45c1);


A.7.8 Aufspaltung zu großer Partitionen

Es kann relativ leicht passieren, dass eine Partition nicht mehr auf einen Knoten passt. Dannmuss sie aufgeteilt werden.

Eine Moglichkeit ist, eine Key-Column mit in den Partition Key aufzunehmen. Wenn wir z.B. inder Tabelle freie_zimmer_by_hotel_datum das Datum mit in den Partition Key aufnehmen,werden die Partitionen wesentlich kleiner sein, aber vielleicht zu klein, weil dann aufeinanderfolgende Tage wahrscheinlich auf unterschiedlichen Knoten liegen.

Eine weitere Moglichkeit ist das Bucketing, wobei eine zusatzliche, oft redundante Columneingefuhrt wird. In unserem Beispiel konnte man den Monat (redundant zum Datum) als zusatz-liche Column einfuhren und in den Partition Key aufnehmen. Das wurde die Partitionsgroßevernunftig reduzieren.

A.8. BEISPIELE IN GOLANG 31

A.8 Beispiele in Golang

Im wesentlichen werden CQL-Anweisungen der Session-Methode Query(...) ubergeben. Dabeiist der CQL-Code ein Template (in einfachen Grave-Akzenten ‘any ? cql-co?de‘). Die Frage-zeichen werden durch die weiteren Argumente von Query(...) ersetzt.

A.8.1 Beispiel ”Gezwitscher”

Installation des Go-Treibers:

go get github.com/gocql/gocql

Voraussetzung: Datenbank und cqlsh starten.

Folgende cqlsh-Kommandos sind vorher zu geben:

cqlsh> create keyspace bsp with replication= { ’class’ : ’SimpleStrategy’, ’replication_factor’ : 1 };

cqlsh> create table bsp.zwitscher(zeitlinie text, id TIMEUUID, text text, PRIMARY KEY(id));

cqlsh> create index on bsp.zwitscher(zeitlinie);

Im Programm-Code war es wichtig, die Protokoll-Version auf 4 zu setzen:

cluster.ProtoVersion = 4

Das Programm funktioniert unter:

Cassandra 3.9

gocql-Version?

Programm-Code:

// Zwitscher.go

package main

import ("fmt""log""github.com/gocql/gocql"

)

func main() {// connect to the cluster//cluster := gocql.NewCluster("192.168.1.1", "192.168.1.2", "192.168.1.3")cluster := gocql.NewCluster("127.0.0.1")cluster.Keyspace = "bsp"cluster.ProtoVersion = 4 // ! Important because default is 2 !cluster.Consistency = gocql.Quorumsession, _ := cluster.CreateSession()defer session.Close()

// insert a tweet:if err := session.Query(

‘INSERT INTO zwitscher (zeitlinie, id, text) VALUES (?, ?, ?)‘,"ich", gocql.TimeUUID(), "Guten Tag").Exec(); err != nil {

log.Fatal(err)


}var id gocql.UUIDvar text string

/* Search for a specific set of records whose ’zeitlinie’ column matches* the value ’ich’. The secondary index that we created earlier will be* used for optimizing the search */if err := session.Query(

‘SELECT id, text FROM zwitscher WHERE zeitlinie = ? LIMIT 1‘,"ich").Consistency(gocql.One).Scan(&id, &text); err != nil {

log.Fatal(err)}fmt.Println("Gezwitscher:", id, text)

// list all tweetsiter := session.Query(

‘SELECT id, text FROM zwitscher WHERE zeitlinie = ? ‘, "ich").Iter()for iter.Scan(&id, &text) {

fmt.Println("Gezwitscher:", id, text)}if err := iter.Close(); err != nil {

log.Fatal(err)}

}

Starten des Programms:go run Zwitscher.go

A.9. BEISPIELE IN JAVA 33

A.9 Beispiele in Java

Im wesentlichen werden CQL-Anweisungen der Session-Methode execute(aQueryString) uber-geben.

A.9.1 Beispiel ”GettingStarted”

Es war langwierig den folgenden Code zum Laufen zu bringen. Das Tutorial scheint vollig veraltetzu sein.

Das Programm funktioniert unter:

Cassandra 3.9

cassandra-java-driver-3.1.0

Am bequemsten ist es den Java-Treiber in den CLASSPATH aufzunehmen, z.B. unter UNIX in.profile in der Form:CLASSPATH="...:$HOME/cassandra-java-driver/*:$HOME/cassandra-java-driver/lib/*"

Dazu muss der Inhalt eines heruntergeladenen binary tarballs in das Verzeichniscassandra-java-driver kopiert werden.

Programm-Code:

import com.datastax.driver.core.*;import java.util.UUID;

public class GettingStarted {public static void main(String[] args) {

//org.apache.log4j.BasicConfigurator.configure();

Cluster cluster;Session session;

// Connect to the cluster and keyspace "bsp"cluster = Cluster.builder().addContactPoint("127.0.0.1")

.withProtocolVersion(ProtocolVersion.V3)

.build();session = cluster.connect("bsp");

System.err.println ("1*");

// Create tablesession.execute("CREATE TABLE IF NOT EXISTS benutzer"

+ "(id uuid PRIMARY KEY, nachname text, age int, stadt text,"+ " email text, vorname text)");


// Insert one record into the users tablesession.execute("INSERT INTO benutzer "

+ "(id, nachname, age, stadt, email, vorname)"+ "VALUES (uuid(), ’Hachinger’, 33, ’Munchen’,"+ " ’[email protected]’, ’Nepomuk’)");


// Use select to get the user we just enteredResultSet results = session.execute(

"SELECT * FROM benutzer WHERE nachname=’Hachinger’"+ " ALLOW FILTERING");

UUID pk = null;for (Row row : results) {

System.out.format("%s %s %d\n",(pk = row.getUUID("id")).toString (),row.getString("vorname"), row.getInt("age"));

}System.err.println ("4*");


// Update the same user with a new ageString pks = pk.toString ();//session.execute("UPDATE benutzer SET age = 34 WHERE nachname = ’Hachinger’");session.execute(

"UPDATE benutzer SET age = 34 WHERE id = " + pks);//+ " AND nachname = ’Hachinger’");

System.err.println ("41*");// Select and show the changeresults = session.execute(

"SELECT * FROM benutzer WHERE nachname=’Hachinger’"+ " ALLOW FILTERING");

for (Row row : results) {System.out.format( "%s %d\n",

row.getString("vorname"), row.getInt("age"));}System.err.println ("5*");

// Delete the user from the users table//session.execute("DELETE FROM benutzer WHERE nachname = ’Hachinger’");session.execute("DELETE FROM benutzer WHERE id = " + pks);// Show that the user is goneresults = session.execute("SELECT * FROM benutzer");for (Row row : results) {

System.out.format("%s %s %d %s %s %s\n",row.getUUID("id").toString (),row.getString("nachname"), row.getInt("age"),row.getString("stadt"), row.getString("email"),row.getString("vorname"));

}System.err.println ("6*");

// Clean up the connection by closing itcluster.close();

}}

Das Programm wird mitjavac GettingStarted.java

ubersetzt und mitjava GettingStarted

laufen gelassen.

A.10 What more about Cassandra?

A lot such as:

Cassandra-Konfiguration

Physikalische Cluster-Topologie: Data Centers – Racks – Nodes

Logische Cluster-Topologie: Rings – Nodes, Tokens

Data Distribution by Partition Key: Die Daten werden gleichmaßig uber das Cluster ver-teilt.

Konsistenz Niveaus: Schreiben und Lesen von Daten.

Replication Strategies

A.10. WHAT MORE ABOUT CASSANDRA? 35

Speicherstrukter: Memtables, SSTables, Commit Logs, Caching

Monitoring

Wartung

Performance Tuning

Sicherheit

Literaturverzeichnis

[1] Carlo Batini, Stefano Ceri und Shamkant B. Navathe, ”Conceptual Database Design”, TheBenjamin/Cummings Publishing Company 1992

[2] Christian Bauer und Gavin King, ”Java Persistence with Hibernate”, Manning Publications2006

[3] Grady Booch, ”Object-Oriented Analysis and Design”, The Benjamin/Cummings Publis-hing Company 1994

[4] Rainer Burkhardt, ”UML – Unified Modeling Language”, Addison-Wesley 1997

[5] Stephen Cannan und Gerard Otten, ”SQL — The Standard Handbook”, McGraw-Hill In-ternational 1993

[6] Jeff Carpenter und Eben Hewitt, ”Cassandra – The Definitive Guide”, O’Reilly

[7] Rick G. G. Cattell und Douglas K. Barry, ”The Object Data Standard: ODMG 3.0” MorganKaufmann Publishers 2000

[8] Peter Pin-Shan Chen, ”The Entity-Relationship Model: Toward a Unified View of Data”,ACM Transactions on Database Systems 1, 9-36 (1976)

[9] Peter Coad und Edward Yourdon, ”Object-Oriented Analysis”, Prentice-Hall 1991

[10] Peter Coad und Edward Yourdon, ”Object-Oriented Design”, Prentice-Hall 1991

[11] Edgar Frank Codd, ”The Relational Model for Database Management Version 2”, Addison-Wesley 1990

[12] Thomas Connolly und Carolyn Begg, ”Database Systems”, Addison-Wesley 2002

[13] C. J. Date, ”An Introduction to Database Systems”, Addison-Wesley

[14] C. J. Date und Hugh Darwen, ”A Guide to the SQL Standard”, Addison-Wesley 1993

[15] David Flanagan, Jim Farley, William Crawford und Kris Magnusson, ”Java Enterprise in aNutshell”, O’Reilly & Associates 1999

[16] Stefan Edlich, Achim Friedland, Jens Hampe, Benjamin Brauer und Markus Bruckner,”NoSQL – Einstieg in die Welt nichtrelationaler Web 2.0 Datenbanken”, Hanser

[17] Ramez Elmasri und Shamkant B. Navathe, ”Fundamentals of Database Systems”, The Ben-jamin/Cummings Publishing Company

1

2 LITERATURVERZEICHNIS

[18] Volker Gaede und Oliver Gunther, ”Multidimensional Access Methods”, ACM ComputingSurveys 30, 170-231 (1998)

[19] Hector Garcia-Molina, Jeffrey D. Ullman und Jennifer Widom, ”Database Systems TheComplete Book” Pearson Prentice Hall

[20] Jim Gray und Andreas Reuter, ”Transaction Processing: Concepts and Techniques”, MorganKaufmann (1992)

[21] Terry Halpin und Tony Morgan ”Information Modeling and Relational Databases”, MorganKaufmann 2008

[22] Andreas Heuer und Gunter Saake, ”Datenbanken: Konzepte und Sprachen” MITP 2000

[23] Uwe Hohenstein und Volkmar Pleßer, ”Oracle8 Effiziente Anwendungsentwicklung mit ob-jektrelationalen Konzepten”, dpunkt.verlag 1998

[24] John G. Hughes, ”Objektorientierte Datenbanken”, Hanser und Prentice-Hall International1992

[25] Jennifer Little in ”High Performance Web-Databases”, ed. Sanjiv Purba, Auerbach 2001

[26] Alfons Kemper und Andre Eickler, ”Datenbanksysteme”, R.Oldenbourg 1999

[27] W. Kim, ”On Optinizing an SQL-like Nested Query”, ACM Transactions on Database Sy-stems 7, 443 (1982)

[28] Michael Kofler, ”MySQL”, Addison-Wesley 2001

[29] Jochen Ludewig, ”Einfuhrung in die Informatik”, Verlag der Fachvereine Zurich 1989

[30] D. Maier, ”The Theory of Relational Databases”, Computer Science Press 1983

[31] Jim Melton und Alan R. Simon, ”Understanding The New SQL: A Complete Guide”, Mor-gan Kaufmann 1993

[32] Greg Riccardi, ”Principles of Database Systems with Internet and Java Applications”,Addison-Wesley 2001

[33] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy und William Loren-sen, ”Object-Oriented Modeling and Design”, Prentice Hall (Deutsch bei Hanser)

[34] Gunter Saake und Andreas Heuer, ”Datenbanken: Implementierungstechniken” MITP 2005

[35] Gunter Saake und Kai-Uwe Sattler, ”Datenbanken & Java JDBC, SQLJ und ODMG”dpunkt 2000

[36] Pramod J. Sadalage und Martin Fowler, ”NoSQL Distilled” Addison-Wesley 2013

[37] Sanjiv Purba in ”High Performance Web-Databases”, ed. Sanjiv Purba, Auerbach 2001

[38] ”Database Language SQL”, ISO/IEC 9075:1992 oder ANSI X3.135-1992

[39] Michael Stonebraker und Paul Brown, ”Object-Relational DBMSs”, Morgan Kaufmann 1999

[40] Christof Strauch, ”NoSQL Databases”http://home.aubg.bg/students/ENL100/Cloud%20Computing/Research%20Paper/nosqldbs.pdf

(24. Januar 2014)

[41] Niklaus Wirth, ”Algorithmen und Datenstrukturen” Teubner 1986

a.1 geschichte, charakteristikakfg/db/cassandra.pdf · elevator pitch of nishant neeraj: apache...

Documents