PostgreSQL al data warehouse:L'approccio migliore per l'ETL/estrazione dei dati quasi in tempo reale

Question

Sfondo:

Ho un database PostgreSQL (v8.3) fortemente ottimizzato per OLTP.

Ho bisogno di estrarne i dati in tempo semi-reale (qualcuno si chiederà cosa significa semi-tempo reale e la risposta è il più frequentemente possibile, ma sarò pragmatico, come punto di riferimento diciamo che sperano ogni 15 minuti) e inserirli in un data warehouse.

Quanti dati?Nelle ore di punta si parla di circa 80-100.000 righe al minuto sul lato OLTP, nelle ore non di punta questo scenderà in modo significativo a 15-20.000.Le righe aggiornate più frequentemente sono circa 64 byte ciascuna, ma ci sono varie tabelle ecc. Quindi i dati sono piuttosto diversi e possono variare fino a 4000 byte per riga.L'OLTP è attivo 24 ore su 24, 5,5.

Soluzione migliore?

Da quello che riesco a mettere insieme la soluzione più pratica è la seguente:

• Crea un TRIGGER per scrivere tutta l'attività DML in un file di registro CSV a rotazione
• Esegui tutte le trasformazioni richieste
• Utilizza lo strumento nativo di data pump DW per pompare in modo efficiente il CSV trasformato nel DW

Perché questo approccio?

• I TRIGGER consentono di prendere di mira tabelle selettive anziché essere estese a tutto il sistema + l'output è configurabile (ad es.in un CSV) e sono relativamente facili da scrivere e distribuire.SLONY utilizza un approccio simile e le spese generali sono accettabili
• CSV facile e veloce da trasformare
• Facile pompare CSV nel DW

Alternative considerate....

• Utilizzando la registrazione nativa (http://www.postgresql.org/docs/8.3/static/runtime-config-logging.html).Il problema è che sembrava molto dettagliato rispetto a ciò di cui avevo bisogno ed era un po' più complicato da analizzare e trasformare.Tuttavia potrebbe essere più veloce poiché presumo che ci sia meno sovraccarico rispetto a un TRIGGER.Certamente renderebbe più semplice l'amministrazione in quanto è a livello di sistema ma, ancora una volta, non ho bisogno di alcune tabelle (alcune sono utilizzate per l'archiviazione persistente di messaggi JMS che non voglio registrare)
• Interrogare i dati direttamente tramite uno strumento ETL come Talend e inserirli nel DW...il problema è che lo schema OLTP dovrebbe essere modificato per supportare questo e ciò ha molti effetti collaterali negativi
• Utilizzando uno SLONY modificato/compromesso: SLONY fa un buon lavoro di registrazione e migrazione delle modifiche su uno slave, quindi il quadro concettuale è presente ma la soluzione proposta sembra semplicemente più semplice e più pulita
• Utilizzando il WAL

Qualcuno lo ha già fatto?vuoi condividere i tuoi pensieri?

Answer 1

Supponendo che le tue tabelle di interesse abbiano (o possano essere aumentate con) una chiave sequenziale univoca, indicizzata, otterrai un valore molto migliore semplicemente emettendo SELECT ... FROM table ... WHERE key > :last_max_key con output in un file, dove last_max_key è l'ultimo valore chiave dell'ultima estrazione (0 se la prima estrazione). This l'approccio incrementale e disaccoppiato evita introducendo attivare la latenza nel datapath di inserimento (che si tratti di trigger personalizzati o Slony modificato) e, a seconda della configurazione, potrebbe scalare meglio con il numero di CPU, ecc.(Tuttavia, se anche tu devi traccia UPDATES, e la chiave sequenziale è stata aggiunta da te, quindi da your UPDATE le dichiarazioni dovrebbero SET la colonna chiave a NULL quindi ottiene un nuovo valore e viene selezionato per l'estrazione successiva.Tu vorresti non essere in grado di tracciare DELETES senza trigger.) È questo che avevi in ​​mente quando hai menzionato Talend?

Vorrei non utilizzare la funzione di registrazione a meno che non sia possibile implementare la soluzione di cui sopra;la registrazione molto probabilmente implica chiusura in alto per garantire che le righe di registro siano scritte in sequenza e non si sovrappongano/sovrascrivano a vicenda quando più backend scrivono nel registro (controlla il sorgente Postgres). L'overhead di blocco potrebbe non essere catastrofico, ma puoi farne a meno se puoi utilizzare il metodo incrementale SELECT alternativa.Inoltre, la registrazione delle istruzioni verrebbe soffocata eventuali messaggi di AVVISO o ERRORE utili e il l'analisi stessa non sarà istantanea.

A meno che tu non sia disposto ad analizzare i WAL (incluso il monitoraggio dello stato delle transazioni e ad essere pronto a riscrivere il codice ogni volta che aggiorni Postgres), non utilizzerei necessariamente nemmeno i WAL, cioè a meno che tu avere a disposizione l'hardware aggiuntivo, nel qual caso potresti spedire i WAL a un'altra macchina per l'estrazione (sulla seconda macchina puoi utilizzare i trigger senza vergogna - o anche la registrazione delle istruzioni - poiché qualunque cosa accada lì non influisce INSERT/UPDATE/DELETE prestazioni sulla macchina primaria.) Tieni presente che dal punto di vista delle prestazioni (sulla macchina primaria), a meno che tu non possa scrivere i log su una SAN, otterrai un calo prestazionale comparabile (in termini di thrashing della cache del filesystem, principalmente) dalla spedizione dei WAL su una macchina diversa dall'esecuzione dell'operazione incrementale SELECT.

Answer 2

se si può pensare ad una 'tabella di checksum' che contiene solo le ID e la 'checksum' è possibile non solo fare un rapido selezionare dei nuovi record, ma anche i record modificati e cancellate.

il checksum potrebbe essere una funzione CRC32 checksum che ti piace.

Answer 3

La nuova clausola ON CONFLICT in PostgreSQL ha cambiato il mio modo di fare molti aggiornamenti. Tiro i nuovi dati (sulla base di un row_update_timestamp) in una tabella temporanea, allora in uno SQL INSERT nella tabella di destinazione con ON conflitto di aggiornamento. Se la tabella di destinazione è partizionata allora avete bisogno di passare attraverso un paio di cerchi (vale a dire ha colpito direttamente la tabella delle partizioni). L'ETL può accadere come si carica la tabella del Temp (più probabile) o nel conflitto SQL ON (se banale). Rispetto ad altri sistemi "upsert" (Update, inserire se zero righe etc.) questa mostra un enorme miglioramento della velocità. Nel nostro particolare ambiente DW non abbiamo bisogno / voglia di ospitare DELETE. Controlla la documentazione sul conflitto - dà MERGE di Oracle una corsa per il suo denaro