Was sind die Standardmethoden zum Synchronisieren (Kopieren) von Daten zwischen einigen Tabellen in Cassandra?

Question

Ich bin neu in Cassandra, kürzlich sah ich sehr gut tutorials auf DataStax, die über Datenmodellierung war.

Wie ich verstanden habe, müssen wir in Cassandra immer verschiedene Tabellen für Abfragen haben, die wir haben wollen, zum Beispiel sogar eine einfache Abfrage zum Sortieren von Daten nach Zeit oder ID.

Es bedeutet, dass wir einige Tabellen für jede Entität haben müssen, die Daten gemäß der Abfrage hat, die wir später haben möchten. Stellen Sie sich vor, wir haben Videos und wir haben vielleicht einige Tabellen für Videos entity.

Erste Frage, wie ich für jede Abfrage gesagt, dass wir einen Tisch haben müssen, werden wir andere Art von Sorten auf Video von verschiedenen Spalten haben:

unserer Spalten für Video Tabelle sind:

video_id | video_title | video_create_year | director | timestap 

Jetzt sollten wir andere Tabellen für andere Sortierung machen können wir brauchen?

Wir müssen die Tabelle von Regisseur Namen sortieren (ASC | DESC), video_create_year (ASC | DESC), video_title (ASC | DESC)

Ich bin nicht sicher, sollten wir verschiedene Tabellen machen jede unterschiedliche Sortierung?

wie:

videos_by_diractor_asc 
videos_by_diractor_desc 
videos_by_title_asc 
videos_by_title_desc 

so weiter ...

Habe ich es richtig verstanden habe?

Zweite Frage,, wenn ich es richtig verstanden habe, dann vergaß ich einen Tisch zu machen, die ich in unserer Website benötigt kann (Man stelle ich eines Tages ich video_by_title_asc bekommen haben vergessen) dann, was soll ich tun? Soll ich ein Programm schreiben und ganze Daten vom Videotable kopieren? Oder gibt es in Kassandra einige Möglichkeiten, ganze Daten zu kopieren, wenn es nötig ist?

Ich hoffe, die Frage war nicht verwirrend.

Answer 1

Okay, Sie verstehen Cassandra teilweise richtig.

Ich hoffe, ich verstehe dich richtig. Ihr Primärschlüssel dieser Tabellen würde wie folgt aussehen:

videos_by_diractor_asc PRIMARY KEY(director) 
videos_by_title_asc PRIMARY KEY(title) 

Aber in diesem Fall vergessen hat, eine Sache: Die Partitionsschlüssel. Der Partitionsschlüssel ist der erste Teil des Primärschlüssels. Ich denke, in Ihrem Fall macht das Jahr Sinn. Alle Zeilen mit demselben Partitionsschlüssel befinden sich immer auf demselben Knoten. Cassandra teilt Ihre Zeilen mit dem Partitionsschlüssel auf. Die Spalten nach den Partitionsschlüsseln, Spaltenschlüssel genannt, sind sortiert. Die Partitionsschlüssel selbst sind nicht sortiert. Das bedeutet: node1 kann das Jahr 2015, 1998 und 1950 und node2 2010, 1990, 1577 haben. Cassandra verteilt die Daten gleichmäßig zwischen den Knoten. Beim Modellieren müssen Sie über eine wichtige Sache nachdenken: Was ist die erwartete Größe meiner Tabelle innerhalb eines Partitionsschlüssels? Dies bedeutet im Videofall, wie viele Zeilen erwarten Sie in einem Jahr? 2 Millionen? 1 Bln? Wenn Sie mehr als 2bln Zeilen x Spalte bekommen, werden Sie ein riesiges Problem haben. 2bln ist die maximale Größe jedes Partitionsschlüssels. Aber denken Sie daran: Es ist das Maximum.Ich empfehle nicht mehr als 500 Mio. Ich berechne im schlimmsten Fall mit 500 Mio.

So jetzt können wir über die Spaltenschlüssel sprechen. Ja, jede Sortierung benötigt eine neue Tabelle. Außerdem benötigen Sie eine neue Tabelle, wenn Sie auf Daten in Ihren WHERE-Bedingungen in verschiedenen Aufträgen zugreifen möchten. Ein Beispiel: Sie haben diesen Primärschlüssel PRIMARY KEY (Jahr, Regisseur, Titel)

Die erste ist die Partition Schlüssel. Das bedeutet: Sie brauchen das Jahr immer in Ihrem Wohnort. Dann werden Ihre Daten, mit dem gleichen Partitionsschlüssel, sortiert, Standard in ASC, nach Direktor. Nach dem Regisseur nach Titel. In diesem Fall können Sie diese WHERE-Bedingung nicht verwenden: WHERE Jahr = 2016 und title = "was auch immer"

Okay, jetzt werde ich Ihre Hauptfrage beantworten :) Die Sache mit den duplizierten Daten. In Cassandra 3.0 können Sie materialisierte Ansichten verwenden. Ja, es ist ein nettes Feature, aber es hat seinen Overhead. Die beste Lösung besteht darin, einen Wrapper um Cassandra zu schreiben. Dieser Wrapper macht nur eines: Er verarbeitet all diese duplizierten Daten. Er weiß, wie man am besten auf Daten zugreift, wenn man sie nach Titel und dann nach Regisseur sortiert und nicht nach Regisseur und Titel sortiert. Und eine Sache: Habe keine Bedenken, Daten 5 oder öfter zu schreiben. Cassandra ist zum Schreiben optimiert. Es ist in Ordnung, Daten zu schreiben. Aber vergessen Sie keines: Cassandra ist eine Datenbank für bekannte Abfragen. Wenn Sie wissen, dass Sie die Daten wirklich häufig in dieser Sortierreihenfolge benötigen, erstellen Sie eine Tabelle dafür. Aber wenn Sie es nicht wissen und Sie erstellen diese Tabelle nur für den Fall, wenn: Erstellen Sie keine Tabelle. Für diese, manchmal Abfragen, können Sie Funken oder eine andere Lösung verwenden.

Und noch eins: Wenn Sie nur Daten nach einer Sache abfragen müssen, wie nur nach Titel, nur nach Regisseur, verwenden Sie nicht cassandra dafür. Dies ist ein Hauptmerkmal eines Schlüsselwertspeichers.