Crate: Warum muss die PRIMARY KEY-Spalte in einer PARTITIONED BY-Klausel vorhanden sein?

Question

Können Sie mir helfen zu verstehen, was ich in dieser Dokumentation lese? https://crate.io/docs/reference/sql/partitioned_tables.html

In diesem Beispiel Tabellen, Spalte id long ist kein primary_key; in der Tat, hier id kein Primärschlüssel sein könnte, weil, wie unten angegeben

In meinem app „wenn ein Primärschlüssel festgelegt ist, es in der PARTITION BY Klausel vorhanden sein muss“, habe ich historisch ein primary key auf id string NOT NULL habe, Aber jetzt möchte ich eine Partitionierung für diese Tabelle hinzufügen, in einer Spalte für das generierte Datum, genau wie im Beispiel partition_date timestamp GENERATED ALWAYS AS date_trunc('day', created_at). Ich habe gelesen, dass die Partitionierung in einer Datumsspalte bei der Geschwindigkeit von Abfragen hilft, die auf den Zeitraum abgestimmt sind (z. B. würden alle heutigen Datensätze nur die heutigen Partitionen treffen) und ältere Datenrahmen archivieren (z. B. alles> 180 Tage)), aber ich möchte die Leistung einzelner PK-Lookups nicht verlieren.

So, da ich nicht PARTITIONED BY (partition_date) nur tun kann, ist es am besten, wenn ich ...

a) Entfernen Sie die Primärschlüsselbedingung von id? Ich bin nervös das würde meine Leistung für Single-Zeilen-Lookups beeinflussen! In diesem Zusammenhang macht es Sinn, dass sich PK im Partitionsschlüssel befinden muss, denn zum Nachschlagen sollte im Idealfall nur einen einzigen Knoten treffen.

oder

b) beiden Spalten als Partitionsschlüssel verwenden, wie PARTITIONED BY (id, partition_date) - Das scheint seltsam, denn instinktiv, ich möchte davon ausgehen, dass id würde hohe Mächtigkeit hat und eine schlechte Wahl für eine Partition Spalte sein, und "Tag" oder "Monat" wäre besser, wie im Beispiel in Ihren Dokumenten angezeigt. In diesem Fall, ist mein PK-Lookup auf jede Partition oder weiß es genau wohin? Wenn ich eine Aggregatabfrage ausführen würde, die nur auf heute beschränkt ist, wird sie dann jede Partition treffen oder nur diejenige, die die heutigen Daten enthält?

Answer 1

Das ist also eine gute Frage! Da Partitionen "Untertabellen" von sort sind, hilft dies, die Größe der abgefragten Daten zu reduzieren.

Ein Primärschlüssel beeinflusst routing in CrateDB, so dass das Hinzufügen zu einer partitionierten Tabelle (die ein umfangreicheres Routing erfordert) alle Nicht-Primärschlüsselspalten in partitioned by clause zurückweist. So sind Ihre Optionen wie folgt:

• a) Während dies die Fähigkeit, effektiv PK-Lookups zu tun entfernt, dies wie eine sinnvolle Option scheint zu tun - regelmäßige String-Lookups durch die Verwendung eines fulltext index beschleunigt werden kann - aber es ist auch zu entfernen Nach-Nach-Schreib-konsistente Primärschlüssel-Lookups hinzufügen. Abhängig von der Art und Weise, wie Sie den Primärschlüssel generieren, ist es möglich, stattdessen die interne Spalte _id (für Nachschlagevorgänge) zu verwenden oder vor einer ID-Suche eine REFRESH TABLE auszugeben.
• b) Wird in so viele Partitionen führen, da Primärschlüssel sind (und da sie einzigartig sind ...) - so wird diese Option erstellen zu viele Partitionen

Seit Option b) in Chaos führen wird, Ich würde die Option a) empfehlen. Wenn die Suche nach Primärschlüsseln jedoch für Ihre Anwendung entscheidend ist und die erwartete Datenmenge nicht so groß ist (einige Millionen sind in Ordnung - abhängig von der Clustergröße und den Maschinenspezifikationen natürlich), könnte es ohne Partitionierung funktionieren!

Prost, Claus