Scénario hypothétique - J'ai un cluster Greenplum à 10 nœuds avec 100 To de données dans 1000 tables qui doit être déchargé sur S3 pour des raisons. Idéalement, le résultat final est un fichier .csv qui correspond à chaque table de la base de données.Exportation d'une base de données Greenplum vers Amazon S3 en tant que .csv
J'ai trois approches possibles, chacune avec des positifs et des négatifs. COPY - Il y a une question qui répond déjà au comment, mais le problème avec psql COPY dans une architecture distribuée, c'est que tout doit passer par le maître, créant un goulot d'étranglement pour le déplacement de 100 To de données. Gpcrondump - Cela créerait 10 fichiers par table et le format est TAB Delimited, ce qui nécessiterait un ETL post-gpcrondump pour unir les fichiers en un seul fichier .csv, mais il tire pleinement parti de l'architecture distribuée et enregistre automatiquement transferts réussis/échoués. EWT - Prend avantage de l'architecture distribuée et écrit chaque table dans un seul fichier sans la conserver dans la mémoire locale jusqu'à la construction du fichier complet, mais sera probablement le plus compliqué des scripts à écrire car vous devez implémenter l'ETL, vous ne pouvez pas le faire séparément, après la décharge. Toutes les options vont avoir des problèmes différents avec les verrous de table que nous parcourons la base de données et déterminer quelles tables ont échoué afin que nous puissions les ré-adresser pour un transfert de données complet.
Quelle approche utiliseriez-vous et pourquoi?
Vous ne voulez pas utiliser gpcrondump - accrochez-vous vous retrouvez avec des fichiers qui, non seulement les données au format COPY, mais aussi avec des instructions SQL supplémentaires qui sont nécessaires pour restaurer la sauvegarde . –