TOC

Datenmodellierung in Cassandra

Datenmodellierung in Cassandra

1. Überblick

Cassandra ist eine NoSQL-Datenbank, die hohe Verfügbarkeit und horizontale Skalierbarkeit ohne Leistungseinbußen bietet.

Um die beste Leistung von Cassandra zu erzielen, müssen wir das Schema sorgfältig anhand von Abfragemustern entwerfen, die für das jeweilige Geschäftsproblem spezifisch sind.

In diesem Artikel werden einige der Schlüsselkonzepte umhow to approach data modeling in Cassandra besprochen.

Bevor Sie fortfahren, lesen Sie unseren Artikel zuCassandra with Java, um die Grundlagen und die Verbindung zu Cassandra mit Java zu verstehen.

2. Partitionsschlüssel

Cassandra ist eine verteilte Datenbank, in der Daten auf mehrere Knoten in einem Cluster verteilt und gespeichert werden.

Der Partitionsschlüssel besteht aus einem oder mehreren Datenfeldern und istused by the partitioner to generate a token via hashing to distribute the data uniformly across a cluster.

3. Clustering-Schlüssel

Ein Clustering-Schlüssel besteht aus einem oder mehreren Feldern und hilft dabei, Zeilen mit demselben Partitionsschlüssel zu gruppieren oder zu gruppieren und in sortierter Reihenfolge zu speichern.

Angenommen, wir speichern Zeitreihendaten in Cassandra und möchten die Daten in chronologischer Reihenfolge abrufen. Ein Clustering-Schlüssel, der Zeitreihendatenfelder enthält, ist sehr hilfreich, um Daten für diesen Anwendungsfall effizient abzurufen.

Hinweis: Die Kombination aus Partitionsschlüssel und Clusterschlüssel bildet den Primärschlüssel und identifiziert jeden Datensatz im Cassandra-Cluster eindeutig.

4. Richtlinien für Abfragemuster

Bevor Sie mit der Datenmodellierung in Cassandra beginnen, sollten Sie die Abfragemuster identifizieren und sicherstellen, dass sie den folgenden Richtlinien entsprechen:

  1. Jede Abfrage sollte Daten von einer einzelnen Partition abrufen

  2. Wir sollten nachverfolgen, wie viele Daten in einer Partition gespeichert werden, da Cassandra die Anzahl der Spalten, die in einer einzelnen Partition gespeichert werden können, begrenzt

  3. Es ist in Ordnung, die Daten zu denormalisieren und zu duplizieren, um verschiedene Arten von Abfragemustern für dieselben Daten zu unterstützen

Schauen wir uns anhand der oben genannten Richtlinien einige reale Anwendungsfälle an und wie wir die Cassandra-Datenmodelle für sie modellieren würden.

5. Beispiele für die Modellierung realer Daten

5.1. Facebook Beiträge

Angenommen, wir speichern Facebook-Beiträge verschiedener Benutzer in Cassandra. Eines der gängigen Abfragemuster ist das Abrufen der obersten "N" - Beiträge eines bestimmten Benutzers.

Somitwe need tostore all data for a particular user on a single partition gemäß den obigen Richtlinien.

Die Verwendung des Post-Zeitstempels als Clustering-Schlüssel ist außerdem hilfreich, um die Top-Posts vonNeffizienter abzurufen.

Definieren wir das Cassandra-Tabellenschema für diesen Anwendungsfall: 

CREATE TABLE posts_facebook (
  user_id uuid,
  post_id timeuuid,
  content text,
  PRIMARY KEY (user_id, post_id) )
WITH CLUSTERING ORDER BY (post_id DESC);

Schreiben wir nun eine Abfrage, um die 20 besten Beiträge für den BenutzerAnna zu finden: 

SELECT content FROM posts_facebook WHERE user_id = "Anna_id" LIMIT 20

5.2. Turnhallen im ganzen Land

Angenommen, wir speichern die Details verschiedener Partner-Fitnessstudios in den verschiedenen Städten und Bundesstaaten vieler Länder und möchten die Fitnessstudios für eine bestimmte Stadt abrufen.

Nehmen wir außerdem an, wir müssen die Ergebnisse zurückgeben, wenn die Turnhallen nach ihrem Eröffnungsdatum sortiert sind.

Basierend auf den oben genannten Richtlinien sollten wir die Fitnessstudios in einer bestimmten Stadt eines bestimmten Staates und Landes auf einer einzelnen Partition speichern und das Eröffnungsdatum und den Namen des Fitnessstudios als Clustering-Schlüssel verwenden.

Definieren wir das Cassandra-Tabellenschema für dieses Beispiel: 

CREATE TABLE gyms_by_city (
 country_code text,
 state text,
 city text,
 gym_name text,
 opening_date timestamp,
 PRIMARY KEY (
   (country_code, state_province, city),
   (opening_date, gym_name))
 WITH CLUSTERING ORDER BY (opening_date ASC, gym_name ASC);

Schauen wir uns nun eine Abfrage an, bei der die ersten zehn Fitnessstudios nach ihrem Eröffnungsdatum für die Stadt Phoenix in den USA abgerufen werden. Bundesstaat Arizona: 

SELECT * FROM gyms_by_city
  WHERE country_code = "us" AND state = "Arizona" AND city = "Phoenix"
  LIMIT 10

Als nächstes sehen wir uns eine Abfrage an, die die zehn zuletzt eröffneten Fitnessstudios in der Stadt Phoenix in den USA abruft. Bundesstaat Arizona: 

SELECT * FROM gyms_by_city
  WHERE country_code = "us" and state = "Arizona" and city = "Phoenix"
  ORDER BY opening_date DESC
  LIMIT 10

Hinweis: Da die Sortierreihenfolge der letzten Abfrage der bei der Tabellenerstellung definierten Sortierreihenfolge entgegengesetzt ist, wird die Abfrage langsamer ausgeführt, da Cassandra die Daten zuerst abruft und dann im Speicher sortiert.

5.3. E-Commerce-Kunden und -Produkte

Nehmen wir an, wir betreiben einen E-Commerce-Shop und speichern die InformationenCustomer undProductin Cassandra. Schauen wir uns einige der gängigen Abfragemuster für diesen Anwendungsfall an:

  1. Holen Sie sichCustomer Informationen

  2. Holen Sie sichProduct Informationen

  3. Holen Sie sich alleCustomers, die eine bestimmteProduct mögen

  4. Holen Sie sich alleProducts ein gegebenesCustomer Likes

Wir beginnen mit der Verwendung separater Tabellen zum Speichern der Informationen zuCustomer undProduct. Wir müssen jedoch ein gutes Maß an Denormalisierung einführen, um die oben gezeigten Abfragen 3 und 4 zu unterstützen.

Wir werden zwei weitere Tabellen erstellen, um dies zu erreichen - "Customer_by_Product" und "Product_by_Customer".

Schauen wir uns das Cassandra-Tabellenschema für dieses Beispiel an: 

CREATE TABLE Customer (
  cust_id text,
  first_name text,
  last_name text,
  registered_on timestamp,
  PRIMARY KEY (cust_id));

CREATE TABLE Product (
  prdt_id text,
  title text,
  PRIMARY KEY (prdt_id));

CREATE TABLE Customer_By_Liked_Product (
  liked_prdt_id text,
  liked_on timestamp,
  title text,
  cust_id text,
  first_name text,
  last_name text,
  PRIMARY KEY (prdt_id, liked_on));

CREATE TABLE Product_Liked_By_Customer (
  cust_id text,
  first_name text,
  last_name text,
  liked_prdt_id text,
  liked_on timestamp,
  title text,
  PRIMARY KEY (cust_id, liked_on));

Hinweis: Um sowohl die Abfragen zu unterstützen, die kürzlich von einem bestimmten Kunden gemocht wurden, als auch Kunden, denen kürzlich ein bestimmtes Produkt gefallen hat, haben wir die Spalte "liked_on" als Clustering-Schlüssel verwendet.

Schauen wir uns die Abfrage an, um die zehn Kunden zu finden, denen das Produkt "Pepsi" zuletzt gefallen hat: 

SELECT * FROM Customer_By_Liked_Product WHERE title = "Pepsi" LIMIT 10

Schauen wir uns die Abfrage an, in der die zuletzt beliebten Produkte (bis zu zehn) eines Kunden mit dem Namen "Anna" gefunden werden: 

SELECT * FROM Product_Liked_By_Customer
  WHERE first_name = "Anna" LIMIT 10

6. Ineffiziente Abfragemuster

Aufgrund der Art und Weise, wie Cassandra Daten speichert, sind einige Abfragemuster überhaupt nicht effizient, einschließlich der folgenden:

  • Fetching data from multiple partitions - Hierfür muss ein Koordinator die Daten von mehreren Knoten abrufen, vorübergehend im Heap speichern und die Daten dann aggregieren, bevor die Ergebnisse an den Benutzer zurückgegeben werden

  • Join-based queries - Aufgrund seiner verteilten Natur unterstützt Cassandra Tabellenverknüpfungen in Abfragen nicht wie eine relationale Datenbank und daherqueries withjoins will be slower and can also lead to inconsistency and availability issues

7. Fazit

In diesem Lernprogramm haben wir einige bewährte Methoden zur Vorgehensweise bei der Datenmodellierung in Cassandra behandelt.

Um ein korrektes Datenmodell zu entwerfen, das die beste Leistung eines Cassandra-Clusters erzielt, ist es erforderlich, die Kernkonzepte zu verstehen und die Abfragemuster im Voraus zu identifizieren.

Related