Je suis nouveau sur PDI, j'utilise PDI 7, j'ai une entrée Excel avec 6 lignes et je veux l'insérer dans postgresDB. Ma transformation est: EXCEL INPUT -> Postgres Bulk Loader (2 étapes seulement).

Condition 1: lorsque j'exécute la transformation, le chargement en bloc de Postgres ne s'arrête pas et n'insère rien dans mon postgresDB.

Condition 2: Donc, j'ajoute l'étape "Insertion / Mise à jour" après Postgres Bulk Loader, et toutes les données insérées dans postgresDB ce qui signifie succès, mais le Bulk Loader est toujours en cours d'exécution.

Ma transformation

De toutes les sources que je peux obtenir, ils n'ont besoin que de l'entrée et de l'étape du chargeur en bloc, et après avoir terminé la transformation, le chargeur en bloc est "terminé" (le mien "en cours d'exécution"). Alors, je veux vous demander comment faire cela correctement pour Postgres? Dois-je ignorer quelque chose d'important? Merci.

0
blackgee 24 janv. 2017 à 12:11

4 réponses

Meilleure réponse

J'ai fait quelques expériences.

Environnement:

  • DB: Postgresv9.5x64
  • PDI KETTLE v5.2.0
  • Paramètres jvm par défaut de PDI KETTLE 512 Mo
  • Source de données: DBF FILE sur 2_215_000 lignes
  • PDI et Kettle sur le même hôte local
  • Tableau tronqué à chaque exécution
  • PDI Kettle a redémarré à chaque exécution (pour éviter une charge CPU importante de gc run en raison d'un nombre énorme de lignes)

Les résultats sont en dessous pour vous aider à prendre une décision

  1. Chargeur en vrac: en moyenne plus de 150_000 lignes par seconde environ 13-15 s

  2. Sortie de table (inserts sql): moyenne de 11_500 lignes par seconde. Le total est d'environ 3min 18s

  3. Sortie de table (insertions de lots, taille de lot 10_000): moyenne de 28_000 lignes par seconde. Le total est d'environ 1min 30s

  4. Sortie de table (insertions de lots dans 5 threads taille de lot 3_000): moyenne de 7_600 lignes par seconde pour chaque thread. Cela signifie environ 37_000 lignes par seconde. Le temps total est d'environ 59 secondes.

L'avantage de Buld Loader est qu'il ne remplit pas la mémoire de jmv, toutes les données sont immédiatement diffusées dans le processus psql.

La sortie de table remplit la mémoire jvm avec des données. En fait, après environ 1_600_000 lignes, la mémoire est pleine et gc démarre. CPU ce temps chargé jusqu'à 100% et la vitesse ralentit considérablement. C'est pourquoi il vaut la peine de jouer avec la taille du lot, pour trouver la valeur qui fournira les meilleures performances (plus grandes meilleures), mais à un certain niveau, cela entraînera une surcharge du GC.

Dernière expérience. La mémoire fournie à jvm est suffisante pour contenir des données. Cela peut être modifié dans la variable PENTAHO_DI_JAVA_OPTIONS. J'ai défini la valeur de la taille du tas jvm sur 1024 Mo et augmenté la valeur de la taille du lot.

  1. Sortie de table (insertions de lots dans 5 threads taille de lot 10_000): moyenne de 12_500 lignes par seconde pour chaque thread. Signifie un total d'environ 60_000 lignes par seconde. Le temps total est d'environ 35 secondes.

Maintenant beaucoup plus facile de prendre une décision. Mais vous devez remarquer le fait que la bouilloire pdi et la base de données sont situées sur le même hôte. Dans le cas où les hôtes sont différents, la bande passante du réseau peut jouer un rôle dans les performances.

enter image description here

0
simar 31 janv. 2017 à 06:43

Pour insérer seulement 7 lignes, vous n'avez pas besoin de chargeur en vrac. Chargeur en vrac conçu pour charger une énorme quantité de données. Il utilise un client psql natif. Le client PSQL transfère les données beaucoup plus rapidement car il utilise toutes les fonctionnalités du protocole binaire sans aucune restriction de la spécification jdbc. JDBC est utilisé dans d'autres étapes comme la sortie de table. La plupart du temps, la sortie du tableau est suffisante.

L'étape Postgres Bulk Loader ne fait que créer des données mémoire au format csv à partir des étapes entrantes et les transmettre au client psql.

0
simar 25 janv. 2017 à 14:13

Le chargeur en bloc PostgreSQL n'était autrefois que expérimental. Je ne l'ai pas essayé depuis un certain temps. Etes-vous sûr d'en avoir besoin? Si vous chargez depuis Excel, il est peu probable que vous disposiez de suffisamment de lignes pour justifier l'utilisation d'un chargeur en bloc.

Essayez uniquement l'étape normale Table Output. Si vous insérez uniquement, vous ne devriez pas non plus avoir besoin de l'étape Insert/Update.

1
Brian.D.Myers 24 janv. 2017 à 17:18

Étape d'insertion / mise à jour lente Pourquoi devez-vous éviter d'utiliser l'insertion / mise à jour (en cas d'énorme quantité de données traitées ou si vous êtes limité par le temps)?

Regardons la documentation

L'étape Insérer / Mettre à jour recherche d'abord une ligne dans une table à l'aide d'une ou plusieurs clés de recherche. Si la ligne est introuvable, elle insère la ligne. S'il peut être trouvé et que les champs à mettre à jour sont les mêmes, rien n'est fait. S'ils ne sont pas tous identiques, la ligne du tableau est mise à jour.

Avant les états, pour chaque ligne de l'étape de flux exécutera 2 requêtes. Il s'agit d'abord de rechercher, puis de mettre à jour ou d'insérer. La source de PDI Kettle indique que PreparedStatement est utilisé pour toutes les requêtes: insertion, mise à jour et recherche.

Donc, si cette étape est un goulot d'étranglement, essayez de déterminer ce qui est exactement lent.

  • La recherche est-elle lente? (Exécutez manuellement une requête de recherche sur la base de données sur des exemples de données. Vérifiez-vous que c'est lent? Les champs de recherche ont-ils un index sur les colonnes utilisées pour trouver la ligne correspondante dans la base de données)
  • La mise à jour est-elle lente? (Exécuter manuellement une requête de recherche sur la base de données sur des exemples de données. La vérification est lente? La clause where de mise à jour utilise-t-elle l'index sur les champs de recherche)

Quoi qu'il en soit, cette étape est lente car elle nécessite beaucoup de communication réseau et de traitement de données dans la bouilloire.

Le seul moyen de le rendre plus rapide est de charger toutes les données de la base de données dans la table "temporaire" et d'appeler la fonction qui va upsert des données. Ou utilisez simplement une étape SQL simple dans le travail pour faire de même.

0
simar 15 févr. 2017 à 10:08