Redshift als Ersatz oder Ergänzung

Question

Ein Kollege hat eine Web-App mit einem PHP-Framework erstellt, wo wir einige API-Aufrufe an andere Systeme konfigurieren können. Diese laufen in der Nacht, um neue Daten in eine Postgres-Datenbank einzutragen. Da es sich bei Postgres um eine OLTP-Datenbank handelt, die nicht für Analysen geeignet ist, habe ich angefangen, über Redshift zu lesen. Aber ich kann einfach nicht herausfinden, wie das alles zusammenpasst.

Oh, und für die Analytik würden wir uns PowerBI ansehen, die DirectQuery mit Redshift verwenden könnte. Aber wie ich es sehe, gibt es für Postgres nichts dergleichen.

Also für meine Frage werde ich alles in vier Teile aufgeteilt:

• Anwendung
• Benutzerdaten für die App (Benutzer, Schemata für die API-Aufrufe)
(login, Schnittstelle api Anrufe konfigurieren)
• Daten (Antworten der apis für spätere Analysen)
• Datawarehouse (Speicher für analytische Daten)

 
Solution | Application | Userdata | Data   | Datawarehouse 
-------- | ----------- | ---------- | ------------- | ---------------- 
Now  | PHP  | Postgres | Postgres  | 
1.  | PHP  | Postgres | Postgres  | Redshift 
2.  | PHP  | Postgres |    | Redshift 
3.  | PHP  | Redshift |    | Redshift 

So ist die Frage: Welche mögliche Lösung ist die "richtige"? Ich könnte die Infrastruktur nutzen, die wir haben, und Redshift hinzufügen. Aber dann verdopple ich die Kosten für die Speicherung. Ich könnte die Anwendungsdaten in einer kleineren Datenbank speichern und die Daten von den APIs direkt in Redshift speichern oder Redshift als einzige Datenbank verwenden.

Answer 1

Ihre Frage ist nicht ganz klar, wie Sie beabsichtigen, die Datenbanken zu verwenden, aber die beste Empfehlung ist, zu versuchen und verwenden, um eine „normale“ Datenbank (in Ihrem Fall, PostgreSQL) für alles.

Wenn Sie feststellen, dass Ihr Analytics zu lange nehmen und Sie haben Millionen oder Milliarden von Zeilen in der Datenbank, könnte man dann auch prüfen, Amazon Redshift für schnellere analytische Abfragen. Wenn Ihre Abfragen schreibgeschützt sind, können Sie auch die Verwendung von Amazon Athena in Erwägung ziehen, die Daten direkt aus in Amazon S3 gespeicherten Dateien lesen kann.

Answer 2

Welchen Zweck erfüllt die Postgres-Datenbank in diesem Szenario?

Ich würde vorschlagen, die Ausgabe der API-Aufrufe direkt in S3 zu schreiben und sie von dort in Redshift zu laden.

Wenn diese API-Antworten sind in JSON (wahrscheinlich) können Sie wollen, dass sie in CSVs abzuflachen für in Redshift geladen. Der JSON-Ladevorgang von Redshift ist ziemlich begrenzt.

Answer 3

Beide Systeme haben unterschiedliche Backend infra und werden für einige sehr spezifische Zwecke verwendet. Beide können zwar bei kleinen Datenmengen austauschbar verwendet werden, ändern sich jedoch drastisch, wenn umfangreiche Lese-/Schreibvorgänge beteiligt sind.

Hier nehme ich an, dass, wenn Sie sagen, dass Sie Postgres verwenden, Ihre vermutlich eine Zeilenausrichtung ist.

Zum Schreiben von Massendaten wird eine Zeilen-DB bevorzugt, da es schreibintensiv ist, wenn die Spalten-DB verwendet wird, wenn Ihre Operationen die Abfrage mehrerer Zeilen umfassen (eine typische Anforderung für Analysezwecke).Ein bester Mix besteht immer darin, die Transaktionsdaten über einer zeilenorientierten Datenbank zu speichern, einige der für analytische Zwecke erforderlichen Tabellen in eine Spalten-DB zu migrieren und dort Analyseabfragen auszuführen. Das hört sich absurd und teuer an, aber genau das tun einige Unternehmen, wenn sie keine Kompromisse mit Transaktionsdaten oder analytischen Daten eingehen wollen.

Wenn Ihr Produkt ein Unternehmen mit schweren (finanziellen) Transaktionen ist und Sie auch user_persona erfassen, teilen Sie beide über ein zeilen- und spaltenorientiertes Schema auf.

Ein Zeilen-DB ist schreibintensiv. Wenn die Anwendung Transaktions- schreibt, muss sie in Tabellen ohne Verzögerung geschrieben werden. Ich bin sicher, Sie werden auch mehrere Master_Slave-Konfiguration haben, so die Daten müssen auch zu Sklaven repliziert werden, und das auch, um die Echtzeit.

Man muss jetzt verstehen, dass analytische Daten sich sehr von den Transaktionsdaten unterscheiden. Transaktionsdaten sind nicht umfangreich - sagen wir, es wird eine Zeile in der Auftragstabelle erstellt und user_id mit einigen grundlegenden order_details für jede Bestellung zugeordnet werden; Aber Analytikdaten - Klickmuster auf dem Bildschirm, Details zu gesendeten Benachrichtigungen usw. werden jedes Mal generiert, wenn ein Nutzer in der App landet; ist umfangreich und kann nicht auf die gleiche Weise wie Transaktionsdaten gespeichert werden.

Säulenförmiger Ausrichtung (wie in RS Amazon) wird intensive lesen - eine typische Anforderung für analytische Daten, da es eine große Anzahl von Zeilen für einen gegebenen user_set abgerufen werden - Informationen über alle Mitteilungen gesendet werden, oder die gesamte Die Bildschirme wurden vom Benutzer durchsucht/angeklickt. Eine säulenförmige DB ist maßgeschneidert, um solche Anforderungen zu erfüllen.

Die Massenschreibvorgänge in der Spalten-DB sind langsam; Aber da es sich jetzt hauptsächlich um analytische Daten handelt, ist es nicht kritisch, Daten nicht in Echtzeit zu haben. Analytics braucht Zeit und Daten bis current_date-1 oder mit einem Rückstand von n Stunden kann immer bezeichnet werden, um eine Benutzer-Persona zu zeichnen.

Für ein großes Unternehmen mit umfangreichen Datenmengen muss ein Kompromiss eingehalten werden. Ich hoffe, Sie haben jetzt vielleicht eine schwache Vorstellung davon, wie Sie vorgehen sollen.