Comment puis-je exporter un sous-ensemble de tabledata d'une base de données de production dans ma base de données de test locale?

Nous avons une base de données postgres de production relativement importante: ~ 20 Go. La base de données PostgreSQL est hébergée sur heroku.

Je voudrais copier un petit sous-ensemble des données de la table dans ma base de données locale afin de pouvoir exécuter des tests dessus sans avoir à travailler sur la production.

Je ne veux pas générer moi-même des exemples de données, mais plutôt utiliser les données qui existent déjà dans l'environnement de production.

~ 100 lignes de chaque table de la base de données seraient suffisantes. Y a-t-il un moyen facile d'accomplir cela?

Je n'ai pas utilisé cet outil, mais Jailer promet de le faire

Outil de sous-ensemble et de navigation de base de données. Exporte des ensembles de lignes cohérents et intacts par référence à partir de bases de données relationnelles (JDBC)

http://sourceforge.net/projects/jailer/

Le geôlier peut aider dans cette situation. Je travaille sur le même que le vôtre (en essayant d'obtenir ~ 100 enregistrements de chaque table) et voici les étapes que j'ai faites: - Trouvez l'entité racine (celle qui est associée à presque les tables) et obtenez un sous-ensemble des enregistrements d'un racine (par exemple, racine est des personnes, je vais rechercher tous les enregistrements associés à people.id = 1 ...) - Après avoir terminé l'étape 1, recommencez avec une autre table (celle que vous souhaitez avoir 100 enregistrements ) et obtenir son sous-ensemble à partir du résultat ci-dessus.

Une autre option est quelque chose que je viens de venir récemment à travers (Accordé, je suis encore à l' utiliser, mais plan pour bientôt): rdbms-subsetter.

Il est un peu plus simple et plus léger que Jailer, avec quelques fonctionnalités / avantages:

• CLI si facile à connecter à l'outillage existant
• Open source
• Suivra les clés étrangères pour récupérer un sous-ensemble cohérent de données
  • Si vous n'avez pas de clés étrangères bien définies, les relations peuvent être fournies via un fichier de configuration JSON. Dans mon cas, je prévois de générer cette configuration à partir des métadonnées de schéma stockées ailleurs (merci, Rails: \)
• Vous pouvez cibler une ligne spécifique et obtenir tous les enregistrements associés (par exemple, un client spécifique a des problèmes, vous pouvez donc tout dérouler pour rendre les données de travail de leur compte accessibles localement)
• Il peut prendre un nombre constant d'enregistrements par table ou prendre un logarithme pour obtenir plus de données à partir de tables plus grandes sans aller trop loin.

Il convient de mentionner une autre option pour les bases de données Heroku en particulier, que j'ai beaucoup utilisée (car j'y travaillais auparavant).

Heroku est en fait assez rapide pour créer une nouvelle base de données instantanée car il tire d'abord les journaux d'écriture anticipée pour se préparer, puis se connecte à la base de données principale pour rattraper son retard, puis arrête de la suivre. Vous pouvez créer ces "fourches" dans les applications pour éviter d'affecter trop la production:

$ heroku addons:create heroku-postgres[:specific-plan] \
    --fork your-production-app::DATABASE \
    --app some-other-app-to-own-forked-database \
    [--as PRODUCTION_SNAPSHOT]

Ensuite, vous pouvez démarrer votre application localement pointée vers cet instantané. Je l'utilise fréquemment pour effectuer une migration à sec des données ou des migrations de schéma ou déboguer les problèmes des clients.

Dans cette commande ci-dessus, si vous avez une base de données accessible avec DATABASE_URLon your-production-app, vous vous retrouverez avec une base de données accessible avec PRODUCTION_SNAPSHOT_URL(si vous avez spécifié --as) sur une autre application nommée some-other-app-to-own-forked-database.

Pour obtenir un ensemble aléatoire de lignes, vous pouvez utiliser LIMIT comme ceci:

SELECT * FROM my_table LIMIT 100

Ceci est le plus simple et ne fera que choisir les 100 premières lignes rencontrées par PostreSQL. Il peut s'agir des 100 derniers insérés ou peut-être des 100 premiers. Si vous avez besoin de quelque chose de vraiment aléatoire, regardez cette réponse Stackoverflow .