Lenteur lors d'un chargement incrémental [QVD > 100 Millions de lignes]

[Anonymous]

Bonjour à tous,

Je rencontre des problèmes de lenteur lors de l'un de mes script incrémental.

La table actualisé : [Détail Commande]

Actuellement mon QVD [Détail Commande] contient plus de 106 millions de lignes,

Lorsque mon script vas chercher la date max du champ "LastUpdateDate" de ma table [Détail Commande] cela prend 25 min.

Ci-dessous la partie du script qui vas chercher le max du champ "LastUpdateDate"

Tmp:

     Load

          Max(LastUpdateDate)     AS max_dt

     From

          [$(vFileName)] (QVD)

     ;

J'ai pensé à deux choses pour pour pallier à ce problème, mais j'aimerais avoir votre avis d'expert

- intégrer dans un fichier annexe la dernière ligne charger de ma base (qui devrait être la ligne avec le "LastUpdateDate" max)

- intégrer un champ dans mon QVD "MaxLastUpdateDate" qui serait écrasé avec la valeur du champs "LastUpdateDate" max chargé à chaque chargement

Je reste bien évidement à votre disposition pour toutes demandes de renseignements supplémentaires

Merci d'avance,

[sfatoux72]

‌Peux-tu attacher un fichier contenant toute la partie de ton script permettant le chargement incrémental de ta table ?

Y a peut-être moyen de simplifier

[Anonymous]

Avec plaisir

[#4]

Bonjour, mon probléme n'est pas encore résolu car j'ai des dates qui sont ex traitent de base de données mais leurs formats est le suivant: AAAAMMJJ sans séparateur.

Lorsque je veux faire une date canonique en nommant  mes dates par le même nom et je crée après le calendrier de jour, mois  et année j'ai des année en chiffre comme 57098.

Des solutions ou indications?

Merci à vous.

[sfatoux72]

Je crois que tu t'est trompé de discussion ...

[sfatoux72]

Par rapport au solutions que tu envisageais:

1. Intégrer dans un fichier annexe la dernière ligne charger de ma base (qui devrait être la ligne avec le "LastUpdateDate" max)
   • Avantage : Tu vas gagner en rapidité car tu n'auras qu'une seul ligne
   • Désavantage : C'est dans un fichier séparé. Dans ce cas, autant garder cette information dans ton application sous forme de variable.
     
     
2. Intégrer un champ dans mon QVD "MaxLastUpdateDate" qui serait écrasé avec la valeur du champs "LastUpdateDate" max chargé à chaque chargement
   • Avantage : Tu peux extraire que la première ligne du fichier ( First 1 LOAD ... ) pour récupérer ton résultat
   • Désavantage : Ton QVD sera un peu plus gros et il faudra bien géré le chargement incrémental de ton fichier afin de conserver le chargement optimisé de ton QVD.
     
     

Autres solution :

1. Utiliser la date de modification de ton QVD
   • Tu peux récupérer la date de modification de ton QVD en utilisant la fonction FileTime ‒ QlikView
   • Vu que la dateTime de modification sera quelques minutes/secondes supérieures à la date d'extraction des données de la base, je ne conserverai que la date (supprimer heure minute seconde).
2. Tu peux également travailler avec deux QVD. Un QVD Histo qui contient le gros des données (qui ne change plus) et un fichier courant (plus petit) que tu utiliseras pour le chargement incrémental.
   • Avantage : Ton fichier courant est petit, tu vas donc gagner beaucoup de temps sur ton chargement incrémentale.
   • Désavantage : Tu dois créer une autre application que tu pourras exécuter une fois par année ou par mois suivant la quantité de données pour déplacer une partie des données du QVD courant au QVD Histo.
     • Il faudra également charger tes 2 fichiers dans les applis qui utilisent ton QVD, mais si tu ajoute simplement le suffixe _Histo à ton QVD Histo, tu pourras simplement ajouter * pour charger tes 2 QVD  (TonQvd*.qvd)

[Anonymous]

Je trouve ton idée, d'intégrer le max "LastUptdateDate" du dernier chargement dans une variable, très bien.

Par contre je pensais que le rechargement écrasait toutes les variable, peux tu m'expliquer un peu la manière de procéder.

J'aimerais aussi avoir ton avis sur "La best practice",

Désolé, mais ta réponse à généré une autre question, au vus de la volumétrie du QVD (106 Millions de lignes) sachant que chaque jours je rajoute entre 500 k et 1 M de lignes, es ce que je devrait enlever 2016 de mon QVD pour le stocker à part et avoir un QVD moins volumineux.

Et à partir de combien de Go est il dangereux d'utiliser un QVD, (peut être mal formulé, mais je pense qu'un QVD d'un Tera est trop problématique à utiliser)

[sfatoux72 · Accepted solution]

Non, les variables sont conservées durant le chargement, sauf bien sur si elles sont modifiées par le script de chargement.

Tu trouveras en pièce jointe un exemple basé sur ton chargement.

Lorsque tu ouvres l'application, elle ne contiendra ni la variable, ni les données.

1er chargement:

• La variable sera créée et initialisée par les données du QVD (25 minutes 😉 )
• Les données de la table sont chargées en se limitant au données mise à jour après ou pendant la valeur correspondant à la variable (--> 2 lignes chargées)
• Les données du QVD sont chargées en filtrant les données déjà présente (--> 2 lignes)
• Mise à jour de la variable pour le prochain charge

2ème et prochain chargement:

• La variable est existante
• Les données de la table sont chargées en se limitant au données mise à jour après ou pendant la valeur correspondant à la variable (--> 1 lignes chargées)
• Les données du QVD sont chargées en filtrant les données déjà présente (--> 3 lignes)
• Mise à jour de la variable pour le prochain charge

Pour moi, c'est la bonne practice, en la combinant avec ma dernière proposition (Histo) ont résout le problème de volumétrie des QVD en ne faisant pas un seul Histo, mais plusieurs (un par année).

Franchement, je n'ai aucune idée de taille max supportée par un QVD. Mais ça reste un fichier sous Windows, donc je ne tenterai pas le diable.

Mais es-tu conscient que si tu avais un QVD de 1 Tera, tu aurais également une application d'un peu plus de 1 tera qui devra monter en mémoire sur ton serveur (en se décompressant).  ==> Qu'as-tu comme serveur?

[Anonymous]

Nous n'avons pas vraiment un serveur mais plutôt une grosse station de travail,

Processeur 32 cœurs

512 Go de RAM

20 To de HDD

1 To de SSD

[sfatoux72]

Y a déjà de quoi faire 😉

Comme tu peux le lire ci-dessous, la limitation pour QlikView est seulement dans le nombre de valeur distinct par champs, mais ce genre de champs sont principalement des clés (comme ton champ id).

Limitations de la quantité de données à charger

La quantité de données pouvant être chargées dans un document QlikView est très importante. Elle est surtout limitée par la mémoire principale de l'ordinateur. Cependant, il existe une limitation inhérente à QlikView dont vous devez tenir compte lors de l'élaboration de documents volumineux. Un document QlikView ne peut pas comprendre plus de 2 147 483 648 valeurs distinctes dans un champ.

Le nombre de champs et de tables, de même que le nombre de cellules de table et de lignes de table, pouvant être chargés, est uniquement limité par la RAM disponible.