Chargement des données en base en asynchrone

[bouttier]

Après l’étape de correspondance des champs, les données sont chargé dans une table transitoire qui sert aux différents contrôles. Le chargement des données est fait de manière synchrone, ce qui limite la taille des fichiers qu’il est possible d’importer (disons environ 50k lignes actuellement pour un timeout par défaut à 30 secondes).

Les données sont actuellement importé avec bulk_insert_mappings. Il y a peut-être des manières plus rapide, mais on risque de garder une limite atteignable.

La solution pour s’affranchir totalement de cette limite est de passer cette étape en asynchrone.

[bouttier]

L’utilisation de bluk_insert_mappings utilise en arrière plan executemany qui exécute une requête d’insertion par ligne. Ceci est modifié dans SQLAlchemy 1.4 (si ma compréhension est bonne), qui est alors capable d’exécuter une unique requête Insert.

https://docs.sqlalchemy.org/en/14/changelog/migration_14.html#psycopg2-dialect-features-execute-values-with-returning-for-insert-statements-by-default

Le gain annoncé est de l’ordre de 5 fois plus rapide. Cela repousse déjà pas mal la nécessité du passage à l’asynchrone.

À noter que l’utilisation de bluk_insert_mappings permet tout de même de gagner grandement sur le temps de traitement Python par rapport à l’utilisation de l’ORM.

[bouttier]

Le ticket GeoNature sur le passage à SQLAlchemy 1.4 / 2.0 : https://github.com/PnX-SI/GeoNature/issues/1812

[bouttier]

Testé sur un fichier de 115k lignes, chargement en 38 secondes avec SQLAlchemy 1.3, chargement en 19 secondes avec SQLAlchemy 1.4.

[bouttier]

La release 2.14 de GeoNature met à jour SQLAlchemy en version 1.4, permettant donc de bénéficier de cette amélioration de performance (exécution d'une requête insert par batch plutôt qu'une requête insert par ligne, grâce à la modification de l'implémentation de la fonction bulk_insert_mapping entre sqla 1.3 et 1.4).

La prochaine version du module d'import en préparation permettant d'importer vers plusieurs destination abandonne l'utilisation de la fonction bulk_insert_mapping au profit d'un insert par batch exécuté manuellement (pour des raisons autres que les perfs, pour pouvoir manipuler une dataframe à cette étape). Les performances devraient être donc identique, mais il peut être intéressant de le vérifier.