Beispiel: Modellierung einer Wide Column-Datenbank mithilfe der Chebotko-Notation

Für Cassandra-Datenbanken nutzen wir in der Regel die Chebotko-Notation, die im Folgenden demonstriert werden soll.

Es sei ein Abfragetool für Hotels mit folgendem Programmfluss gegeben:

Aus dem Programmfluss wurden die folgenden Queries abgeleitet:

  • Q1. Find hotels near a given point of interest.
  • Q2. Find information about a given hotel, such as its name and location.
  • Q3. Find points of interest near a given hotel.
  • Q4. Find an available room in a given date range.
  • Q5. Find the rate and amenities for a room.

Für jede Query erstellen wir zunächst ein Chebotko-Logical Model wie folgt:

Dabei kennzeichnet das K den Partition-Key und C den Clustering-Key der jeweiligen Tabelle. Der Pfeil nach dem C gibt an, ob die Einträge auf- () oder absteigend () nach dem Clustering Key sortiert werden sollen.

Auch wenn in dem Beispiel nicht gezeigt, können Spalten bereits im Logical-Model mit einem S als statisch gekennzeichnet werden. Statische Spalten sind für alle Einträge der Partition identisch und können so effizienter abgespeichert werden.

Bevor wir die Tabellen in Cassandra anlegen können, müssen wir noch entscheiden, welchen Datentyp die einzelnen Spalten erhalten und in welchem Keyspace (auch Namespace) von Cassandra sie untergebracht werden sollen.

Das entsprechend angereicherte Diagramm bezeichnen wir als Chebotko-Physical Model:

Dabei ist *address* ein sog. User Defined Type (UDT).

Auch wenn hier nicht dargestellt, können die Datentypen von Spalten auch Collections sein, bspw. kann eine Spalte vom Typ string[] sein.

Die Spezifikation entnehmen wir der folgenden Darstellung:

Anmerkung

Auszeichnung von Queries mit PlantUML

Mit PlantUML können wir die Queries, die von einer Tabelle eines Modells genutzt werden, wie folgt darstellen:

@startuml
 
hide circle
hide members
show fields
 
class **projects_by_department**<Q1, Q2, Q5>{ 
    department_name : text **K**
    project_id : int **C↑**
    department_city : string **S**
    department_zip_code : int **S**
    project_start_date : timestamp
    project_end_date : timestamp
}
 
@enduml