PostgreSQL naar Data-Warehouse:beste aanpak voor bijna realtime ETL / extractie van gegevens

Ervan uitgaande dat uw tabellen van belang hebben (of kunnen worden uitgebreid met) een unieke, geïndexeerde, sequentiële sleutel, dan krijgt u veel veel betere waarde door simpelweg SELECT ... FROM table ... WHERE key> uit te geven:last_max_key met uitvoer naar een bestand, waar last_max_key is de laatste sleutelwaarde van de laatste extractie (0 als de eerste extractie.) Deze incrementele, ontkoppelde benadering vermijdt introductie van triggerlatentie in het invoeggegevenspad (of het nu aangepaste triggers of aangepaste Slony zijn), en afhankelijk van je setup zou het beter kunnen schalen met het aantal CPU's enz. (Als je echter ook UPDATE moet volgen s , en de sequentiële sleutel is door u toegevoegd, vervolgens uw UPDATE instructies moeten SET de sleutelkolom naar NULL dus het krijgt een nieuwe waarde en wordt gekozen door de volgende extractie. Je zou niet in staat zijn om DELETE te volgen s zonder een trigger.) Was dit wat je in gedachten had toen je Talend noemde?

Ik zou de logfunctie niet gebruiken, tenzij je de bovenstaande oplossing niet kunt implementeren; loggen heeft hoogstwaarschijnlijk betrekking op locking overhead om ervoor te zorgen dat logregels opeenvolgend worden geschreven en elkaar niet overlappen/overschrijven wanneer meerdere backends naar het log schrijven (controleer de Postgres-bron.) De vergrendelingsoverhead is misschien niet catastrofaal, maar u kunt het zonder doen als u de incrementele SELECTEER alternatief. Bovendien zou het loggen van verklaringen overstemmen alle nuttige WAARSCHUWING- of FOUT-berichten, en het parseren zelf zal niet onmiddellijk zijn .

Tenzij je bereid bent WAL's te ontleden (inclusief het volgen van de transactiestatus en klaar zijn om de code elke keer dat je Postgres upgradet te herschrijven), zou ik de WAL's ook niet per se gebruiken -- dat wil zeggen, tenzij je de extra hardware beschikbaar hebt , in dat geval kunt u WAL's naar een andere machine verzenden voor extractie (op de tweede machine kun je schaamteloos triggers gebruiken -- of zelfs het loggen van verklaringen -- aangezien wat daar ook gebeurt, geen invloed heeft op INSERT /UPDATE /VERWIJDEREN prestaties op de primaire machine.) Merk op dat qua prestaties (op de primaire machine), tenzij je de logs naar een SAN kunt schrijven, je een vergelijkbare prestatiehit zou krijgen (in termen van het verslaan van bestandssysteemcache, meestal) van het verzenden van WAL's naar een andere machine vanaf het uitvoeren van de incrementele SELECT .