Redshift Schema-Design

Question

Ich versuche, ein Datenbankschema zu entwerfen, die auf einer Reihe von Daten arbeiten muss, die wie folgt aussieht:

Events 
event_id|time|key1|key2|data 

Und es braucht, um Abfragen auszuführen wie diese effizient:

Erhalten Sie alle Veranstaltungen, bei denen Schlüssel1/key2 = ... und die Zeit zwischen ... und ...

Ein Schema ich gedacht wäre

Events 
primary_key=event_id|key1|key2|data 

Key1Lookup 
primary_key=key1|sortkey=time|event_id 

Key2Lookup 
primary_key=key2|sortkey=time|event_id 

Damit meine Abfrage wie

SELECT data FROM Events, Key1Lookup WHERE key1=... AND time BETWEEN ... AND ... AND Events.event_id = Key1Lookup.event_id

oder

SELECT data FROM Events, Key2Lookup WHERE key2=... AND time BETWEEN ... AND ... AND Events.event_id = Key2Lookup.event_id

scheint dies wie die rechte Taste Auswahl/Abfrage-Design aussehen könnte? Ich bin völlig neu in der Rotverschiebung, also brauche ich hier wirklich Anleitung.

Zusätzliche Informationen: Die event_id ist einzigartig. In Key1Lookup ist key1 nicht eindeutig, aber es gibt nur ein paar Wiederholungen in Key1Lookup (denken Sie daran wie eine user_id in einer Kommentartabelle). In Key2Lookup ist key2 nicht eindeutig, aber es gibt nur ein paar Wiederholungen in Key2Lookup (denke an eine location_id in einer Kommentartabelle). Es gibt eine große Anzahl unterschiedlicher key1s, und es gibt eine große Anzahl unterschiedlicher key2s. Ich erwarte, dass sich die Anzahl der Schlüssel1 stark erhöht, und ich erwarte, dass sich die Anzahl der Schlüssel2 deutlich erhöht.

Answer 1

Zuerst ein paar Hinweise relevant, was Sie erwähnt haben:

• Redshift nicht wirklich versteht Primärschlüssel oder tut jede intern Indizierung. Dies ist, was die documentation sagt.

Einmaligkeit Primärschlüssel und Fremdschlüssel-Constraints sind nur informativen ; Sie werden nicht von Amazon Redshift erzwungen.

• Rotverschiebung speichert Daten in Spaltenformat. Wenn sich Ihre Auswahlabfrage nicht auf eine bestimmte Spalte bezieht, werden alle Daten in dieser Spalte ignoriert.
• Verteilungsschlüssel können zum gemeinsamen Suchen von Joins auf zwei Tabellen verwendet werden. In diesen beiden Tabellen kann jedoch nur ein dist-Schlüssel enthalten sein.

Basierend auf diesen beiden, würde ich folgendes empfehlen:

• Auf jeden Fall eine Art-Schlüssel auf timestamp haben. Also jede between ... and ... Abfrage auf timestamp wird einfach unnötige Zeilen überspringen.
• Wenn Sie nur eine key hätten, hätten Sie das von Ihnen vorgeschlagene Schema verwenden können.key wäre der dist-key gewesen, aufgrund dessen Ihre Joins (mit der Tabelle Events) sehr effizient gewesen wären. Aber diese Route kann nicht gehen, weil Sie zwei Schlüssel haben.
• So wäre die De-normalisierte Daten (event_id=primary-key|timestamp=sort-key|key1|key2|data) sehr effizient.
• Es wird besser sein, als jedes Mal an 3 Tischen (von denen jede mit der Zeit wächst) teilzunehmen.
• Und wie ich bereits sagte, wenn Ihre Select-Abfrage eine Bedingung nur für einen Schlüssel (z. B. key1=...) hat, wird die gesamte Spalte key2 ignoriert.