Når du eksporterer et stort datadump, bør din største bekymring være at afbøde fejl. Selv hvis du kunne mætte en GB netværksforbindelse, vil flytning af 10 TB data tage> 24 timer. Du ønsker ikke at skulle genstarte det på grund af en fejl (såsom en timeout for databaseforbindelse).
Dette indebærer, at du bør opdele eksporten i flere stykker. Du kan gøre dette ved at tilføje et ID-område til select-sætningen inde i kopien (jeg har lige redigeret dit eksempel, så der kan være fejl):
COPY (SELECT (ID, NAME, ADDRESS) FROM CUSTOMERS WHERE ID BETWEEN 0 and 1000000) TO ‘CUSTOMERS_DATA_0.CSV WITH DELIMITER '|' CSV;
Du ville selvfølgelig generere disse udsagn med et kort program; glem ikke at ændre navnet på outputfilen for hver enkelt. Jeg anbefaler at vælge et ID-område, der giver dig en gigabyte eller deromkring pr. outputfil, hvilket resulterer i 10.000 mellemliggende filer.
Hvor du skriver disse filer er op til dig. Hvis S3FS er tilstrækkelig pålidelig, synes jeg det er en god idé.
Ved at dele aflæsningen op i flere mindre stykker, kan du også opdele den mellem flere EC2-instanser. Du vil sandsynligvis mætte databasemaskinens båndbredde med kun få læsere. Vær også opmærksom på, at AWS opkræver 0,01 USD pr. GB for dataoverførsel på tværs af AZ – med 10 TB, det er 100 USD – så sørg for, at disse EC2-maskiner er i samme AZ som databasemaskinen.
Det betyder også, at du kan udføre aflæsningen, mens databasen ellers ikke er optaget (dvs. uden for normal arbejdstid).
Endelig betyder det, at du kan teste din proces, og du kan rette eventuelle datafejl uden at skulle køre hele eksporten (eller behandle 10 TB data for hver rettelse).
På importsiden kan Redshift indlæse flere filer parallelt . Dette burde forbedre din samlede tid, selvom jeg ikke rigtig kan sige hvor meget.
En advarsel:brug en manifestfil i stedet for et objektnavn-præfiks. Jeg er stødt på tilfælde, hvor S3's endelige konsistens forårsagede, at filer blev slettet under en indlæsning.