PostgreSQL für Transaktionen mit hohem Volumen und für Data Warehousing

Ich bin ziemlich neu in PostgreSQL. Ich habe noch nie eine große Bereitstellung damit durchgeführt. Aber ich habe gute Erfahrungen mit Unternehmenslösungen und möchte versuchen, etwas von dem anzuwenden, was ich mit PostgreSQL gelernt habe.

Ich habe eine Site, die so dimensioniert ist, dass sie eine große Anzahl von Daten und Datenverkehr verarbeiten kann. Die Infrastruktur wird unter Verwendung von Amazon (AWS) unter Verwendung von EC2-Instanzen und EBS-Volumes erstellt.

Das Design sollte über zwei Datenbanken verfügen, eine Haupttransaktionsdatenbank und ein Data Warehouse für Analyse und Berichterstellung.

Haupttransaktionsdatenbank

wird für Live-Websites verwendet, die Website ist auf mehreren Knoten aufgebaut, um gleichzeitige Benutzer zu skalieren. Hauptsächlich benötigen wir die Datenbank, damit dieser Fall beim Lesen extrem schnell ist. Wir erwarten> 100 GB Daten mit einem jährlichen Wachstum von 30%. Zu diesem Zeitpunkt planen wir, zwei EC2-Server zu verwenden ( und später nach Bedarf weitere hinzuzufügen ).

Meine Frage, was ist das empfohlene Setup für die oben genannten Anforderungen? Gibt es eine Möglichkeit, die Tabellen- und Volume-Partitionierung zu verwalten? Gibt es Empfehlungen für die Verwendung des AWS-Setups?

Data Warehouse-Datenbank

Wird hauptsächlich zum Erfassen aller Daten aus der Haupttransaktionsdatenbank in der Zeitdimension verwendet. So werden auch gelöschte Datensätze aus der Hauptdatenbank im DWH erfasst. Daher werden die Daten sehr groß sein und das Wachstum wird noch größer sein. Bei Bedarf werden auch einige EC2-Instanzen oder mehr verwendet.

Was ist das empfohlene Setup in diesem Fall? Dies erfordert aufgrund des konstanten Schreibens (ETL) einen schnellen Schreibvorgang. Können wir OLAP-Cubes in PostgreSQL erstellen? Wenn ja, hat es jemand da draußen versucht?

Verbindung zur Datenbank herstellen

Die Webserver stellen eine Verbindung zur Hauptdatenbank her, um abzufragen und zu schreiben. Wir entwickeln derzeit eine Anwendung mit Django, die eine native Bibliothek für die Verbindung verwendet. Wird empfohlen, dieselbe grundlegende Methode zu verwenden? oder sollten wir pgpool konfigurieren?

Data Warehouse (ETL)

Was ist die empfohlene Methode zum Erstellen von ETL-Prozessen zum Lesen von Haupt- und Ladevorgängen in Data Warehouse? Irgendwelche Werkzeuge? Methodik zu folgen? Bietet PostgreSQL hilfreiche Funktionen / Tools zum Erstellen von ETL-Prozessen?

Infrastruktur- / Datenbankdienste

Sie sollten dies wahrscheinlich lesen, um einen Überblick über eine hochvolumige Site zu erhalten, die unter AWS mit EBS ausgeführt wird. Sie sind in den kurzlebigen Speicher umgezogen, mussten jedoch Redundanz schaffen, um die Daten (erneut) speichern zu können.

http://blog.reddit.com/2012/01/january-2012-state-of-servers.html

Data Warehouse / ETL

Ich habe Pentaho in der Vergangenheit benutzt. Nicht direkt mit Postgres, aber ich habe festgestellt, dass es eine gute Lösung für OLAP (Mondrian) und ETL (Kettle) ist.

http://www.pentaho.com/

edit: "Community Editions" finden Sie hier

http://mondrian.pentaho.com/

http://kettle.pentaho.com/

Verbindung

Diese Leute scheinen pgbouncer wirklich zu mögen. /programming/1125504/django-persistent-database-connection

Ich habe jedoch keine Erfahrung damit. Anscheinend benutzt Disqus es.

Ihr Setup ähnelt einem, das ich für eine Universität entwickelt habe. Die Datenbank war nicht riesig, aber ziemlich groß, ungefähr 300 GB groß und die größte Tabelle enthielt ungefähr 500 Millionen Datensätze. Und wächst weiter.

Zu diesem Zweck wurden zwei wirklich leistungsfähige Server (echtes Eisen, nicht virtualisiert) verwendet, von denen einer für die Verarbeitung der Daten von einer Website und der andere für statistische Berechnungen und Analysen verwendet wurde. Die Daten wurden mit Slony in beide Richtungen repliziert. Die OLTP-Daten wurden kontinuierlich auf den OLAP-Server repliziert und einige Schemata und einzelne Tabellen wurden vom OLAP-Server auf den OLTP repliziert. Auf diese Weise könnten umfangreiche Berechnungen auf dem Analyseserver durchgeführt werden, ohne den OLTP-Server zu beeinträchtigen. Heutzutage gibt es einige Alternativen zu Slony zum Replizieren von Daten: http://www.postgresql.org/docs/9.2/static/different-replication-solutions.html

Slony war gut und schnell für unser Anliegen, aber es kann ein harter Lehrer sein.

Da der OLAP-Server stetig wächst, sollten Sie gegebenenfalls eine Partitionierung in Betracht ziehen.

Wenn Sie die Möglichkeit haben, verwenden Sie das Verbindungspooling. Ich habe nur PgPool verwendet und es hat einwandfrei funktioniert. PgBouncer ist eine weitere Option. Neben der Reduzierung der Init-Latenz werden auch der Sitzungsstart und das Sitzungsmanagement reduziert. http://momjian.us/main/blogs/pgblog/2012.html#April_25_2012

Ein weiterer Vorteil der Verwendung eines Verbindungspools besteht darin, dass Sie einen einzigen Punkt haben, an dem Sie Ihren Datenverkehr problemlos umleiten können (dies kann natürlich auch ein Risiko darstellen).

Ich habe keine vorgefertigte ETL zum Laden von Daten auf den OLAP-Server verwendet. Ich habe mein eigenes Skript in Python geschrieben, da einige der Daten in riesigen Textdateien mit einem besonderen Format geliefert wurden.

Die Struktur der Datenbank muss sorgfältig abgewogen werden. Die Verwendung von Schemata eignet sich zum Sammeln und erleichtert die Handhabung von Objekten. Es mag zunächst umständlich erscheinen, Schemata zu verwenden, aber wenn die Anzahl der Objekte zunimmt, werden Sie sich bedanken. Wenn Sie wissen, dass Sie Objekten explizit ihr Schema voranstellen müssen, wissen Sie genau, mit welchen Objekten Sie arbeiten. http://momjian.us/main/blogs/pgblog/2012.html#April_27_2012

Für die Wagemutigen ist PostgreSQL XC eine interessante Alternative oder nur ein übergroßes Kostüm. Http://postgres-xc.sourceforge.net/