PostgreSQL per transazioni ad alto volume e per il data warehousing

Sono abbastanza nuovo in PostgreSQL, non ho mai fatto una grande distribuzione usando prima. Ma ho una buona esperienza nelle soluzioni aziendali e voglio provare ad applicare alcune delle cose che ho imparato usando PostgreSQL.

Ho un sito che è dimensionato per gestire un gran numero di dati e traffico. L'infrastruttura verrà costruita utilizzando su Amazon (AWS) utilizzando istanze EC2 e volumi EBS.

Il progetto dovrebbe avere due database, un database transazionale principale e un data warehouse per gestire analisi e reportistica.

Database transazionale principale

verrà utilizzato per il sito Web live, il sito è basato su più nodi per aumentare gli utenti simultanei. Principalmente richiediamo che il database per questo caso sia estremamente veloce nelle operazioni di lettura, prevediamo dati> 100 GB con una crescita annuale del 30%. A questo punto, stiamo pianificando di utilizzare due server EC2 ( e aggiungerne altri in seguito, se necessario ).

la mia domanda, qual è la configurazione consigliata per i requisiti di cui sopra? Inoltre, c'è un modo per gestire il partizionamento di tabelle e volumi? ci sono consigli per l'utilizzo della configurazione di AWS?

Database del data warehouse

Verrà utilizzato principalmente per acquisire tutti i dati dal database transazionale principale nella dimensione temporale. così, anche i record eliminati dal database principale verranno acquisiti nel DWH. Pertanto, i dati saranno molto grandi e la crescita sarà ancora più grande. Useremo anche un paio di istanze EC2 o più, se necessario.

Qual è l'impostazione consigliata in questo caso? questo richiederà un'operazione di scrittura rapida a causa della scrittura costante (ETL). Possiamo costruire cubi OLAP in PostgreSQL? se sì, qualcuno ha provato?

Connessione al database

I server Web si collegheranno al database principale per eseguire query e scrivere. Al momento stiamo sviluppando un'applicazione utilizzando django che utilizza la libreria nativa per la connessione. Si consiglia di utilizzare lo stesso metodo di base? o dovremmo configurare pgpool?

Data warehouse (ETL)

Qual è il modo consigliato per la creazione di processi ETL per leggere dal main e caricare nel data warehouse? Qualche attrezzo? metodologia da seguire? PostgreSQL offre utili funzioni / strumenti nella costruzione di processi ETL?

Infrastruttura / Servizi di database

Probabilmente dovresti leggere questo per una panoramica di un sito ad alto volume che funziona su AWS con EBS. Sono passati all'archiviazione effimera ma hanno dovuto creare ridondanza per poter (ri) archiviare i dati.

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

Data Warehouse / ETL

Ho usato Pentaho in passato. Non direttamente con Postgres, ma l'ho trovato un'ottima soluzione sia per OLAP (Mondrian) che per ETL (Kettle)

http://www.pentaho.com/

modifica: "Community Editions" è disponibile qui

http://mondrian.pentaho.com/

http://kettle.pentaho.com/

Connessione

Queste persone sembrano apprezzare davvero pgbouncer. /programming/1125504/django-persistent-database-connection

Non ho esperienza con esso, però. Apparentemente, Disqus lo usa.

Il tuo setup ricorda quello che ho sviluppato per un'università. Il database non era enorme, ma abbastanza grande, con dimensioni di circa 300 GB e la tabella più grande conteneva circa 500 milioni di record. E ancora in crescita.

Allo scopo sono stati utilizzati due server veramente potenti (vero ferro, non virtualizzato), uno dedicato alla gestione dei dati da un sito Web e l'altro utilizzato per calcoli e analisi statistiche. I dati sono stati replicati in entrambe le direzioni usando Slony. I dati OLTP sono stati replicati continuamente sul server OLAP e alcuni schemi e singole tabelle sono stati replicati dal server OLAP su OLTP. In questo modo è possibile eseguire calcoli pesanti sul server di analisi senza influire sul server OLTP. Oggi esistono alcune alternative a Slony per la replica dei dati: http://www.postgresql.org/docs/9.2/static/different-replication-solutions.html

Slony è stato buono e veloce per la nostra preoccupazione, ma potrebbe essere un duro insegnante.

Dato che il server OLAP crescerà costantemente, dovresti prendere in considerazione l'uso di un qualche tipo di partizionamento, se applicabile.

Se è possibile, utilizzare il pool di connessioni. Ho usato solo PgPool e ha funzionato perfettamente. PgBouncer è un'altra opzione. Oltre a ridurre la latenza di inizializzazione, riduce anche l'avvio e la gestione della sessione. http://momjian.us/main/blogs/pgblog/2012.html#April_25_2012

Un altro vantaggio dell'utilizzo di un pool di connessioni è che si ottiene un unico punto in cui è possibile reindirizzare facilmente il traffico (questo potrebbe ovviamente essere anche un rischio).

Non ho usato alcun ETL readymade per caricare i dati nel server OLAP. Ho scritto il mio script in Python poiché alcuni dei dati sono stati consegnati in enormi file di testo con un formato peculiare.

La struttura del database deve essere attentamente considerata. L'uso degli schemi è utile per raccogliere e facilitare la gestione degli oggetti. Inizialmente può sembrare complicato usare gli schemi, ma man mano che il numero di oggetti cresce ti ringrazierai. Sapendo che devi aggiungere esplicitamente il prefisso agli oggetti con il loro schema sai esattamente su quali oggetti operi. http://momjian.us/main/blogs/pgblog/2012.html#April_27_2012

Per i più audaci PostgreSQL XC può essere un'alternativa interessante o solo un costume di grandi dimensioni http://postgres-xc.sourceforge.net/