Při exportu velkého výpisu dat by mělo být vaším největším zájmem zmírnění selhání. I kdybyste mohli nasytit GB síťové připojení, přesun 10 TB dat zabere> 24 hodin. Nechcete, abyste to museli restartovat kvůli selhání (jako je časový limit připojení k databázi).
To znamená, že byste měli export rozdělit na více částí. Můžete to udělat přidáním rozsahu ID do příkazu select uvnitř kopie (právě jsem upravil váš příklad, takže se mohou vyskytovat chyby):
COPY (SELECT (ID, NAME, ADDRESS) FROM CUSTOMERS WHERE ID BETWEEN 0 and 1000000) TO ‘CUSTOMERS_DATA_0.CSV WITH DELIMITER '|' CSV;
Tyto příkazy byste samozřejmě vygenerovali pomocí krátkého programu; nezapomeňte u každého změnit název výstupního souboru. Doporučuji vybrat takový rozsah ID, který vám dává přibližně gigabajt na výstupní soubor, což vede k 10 000 přechodných souborů.
Je na vás, kam tyto soubory zapíšete. Pokud je S3FS dostatečně spolehlivý, myslím, že je to dobrý nápad.
Rozdělením vyložení na několik menších částí jej můžete také rozdělit mezi více instancí EC2. Šířku pásma databázového stroje pravděpodobně zaplníte jen několika málo čtečkami. Uvědomte si také, že AWS účtuje 0,01 USD za GB za přenos dat napříč AZ – s 10 TB je to 100 USD – takže se ujistěte, že tyto počítače EC2 jsou ve stejném AZ jako databázový stroj.
To také znamená, že můžete provést uvolnění, když databáze není jinak zaneprázdněna (tj. mimo běžnou pracovní dobu).
A konečně to znamená, že můžete otestovat svůj proces a můžete opravit jakékoli chyby v datech, aniž byste museli spouštět celý export (nebo zpracovávat 10 TB dat pro každou opravu).
Na straně importu může Redshift načíst více soubory paralelně . To by mělo zlepšit váš celkový čas, i když vlastně nedokážu říct o kolik.
Jedno upozornění:použijte soubor manifestu spíše než předpona názvu objektu. Setkal jsem se s případy, kdy případná konzistence S3 způsobila zahazování souborů během načítání.