Discussion :

[bruno.a]

Bonjour,

Je cherche à optimiser une mise à jour régulière de gros fichier (+ de 30 000 enreg comme le fichier HEXAPOSTE par exemple qui fait environ 55000 enreg).
Mes clients sont en réseau (classique ou CS).
Actuellement, je fabrique le fichier MONFICHIER.FIC , je zippe et je l'incorpore dans l'install du logiciel. Le premier poste qui se connecte à la base compare la version et dézippe le fichier si besoin. En classique pas de souci mais en CS le fichier est de temps en temps occupé par le moteur donc la copie ne passe pas.
J'ai essayé de sérialiser et de désérialiser le fichier puis de faire un INSERT multiple mais suivant les configs les temps sont trop longs (55 min d'insert pour 55 000 enreg sur un serveur 2003 32 bits alors que 50s sur un sbs 2008 64 bits !).
Comment faites-vous pour faire ce genre de mise à jour ?

Merci

Brun

[Lo²]

Bonjour,

Intéressé également par cette discussion car je rencontre la même problématique.

[LeonCosnyd]

1. Prévoir une réplication ?

2. Dans un thread, au lancement de l'appli, taper dans un .xml en ligne pour vérifier version (numéro/date/heure) et se mettre à jour en tache de fond si besoin ?

[michel.souris]

Bonjour,

Pour gérer ce type de problème je :

• [->]liste les clients connectés
  [->] propose à l'utilisateur en cours de mise à jour de :
  
  • envoyer un message aux utilisateurs connectés (via HFSQL)
  • forcer la déconnexion des utilisateurs connectés (via HFSQL)
  • réessayer]
  
  [->] interdit la connexion (via HFSQL)
  [->] réalise l'opération voulue
  [->] lève le verrou sur la BDD (via HFSQL)

Je traite ainsi les cas suivants :
-> mise à jour du modèle de données
-> mise à jour des données de référence (typiquement, c'est votre cas)
-> sauvegarde
-> restauration

[Hemgé]

mise à jour régulière de gros fichier (+ de 30 000 enreg comme le fichier HEXAPOSTE par exemple qui fait environ 55000 enreg).

Bonjour,

Vous envisagez d'envoyer l'intégralité du fichier ou seulement les mises à jour ?

Nous allons devoir traiter un cas similaire avec des volumes de mise à jour mensuelle oscillant entre 5 et 25 GB, à redistribuer à plusieurs centaines d'utilisateurs.
Le propriétaire des fichiers envoie chaque fois des enregistrements complets destinés à écraser purement et simplement les enregistrements à mettre à jour.
Par écraser, on entend en fait un DELETE de l'enregistrement existant suivi d'un ADD de sa mise à jour.
En plus, chaque enregistrement de la mise à jour est l'enregistrement original complété par une rubrique 'Update' positionnée à DELETE ou ADD, ce qui signifie que tout enregistrement mis à jour figure deux fois dans le fichier, une première fois en DELETE et une seconde en ADD.
Ce n'est pas la première mise à jour de ce genre que je rencontre.

Nous envisageons un traitement intermédiaire, par lequel nous identifierons les rubriques modifiées pour ne redistribuer que celles-là, avec une réduction drastique des volumes à diffuser, des temps de traitement vraisemblablement meilleurs et moins d'impact sur une possible fragmentation des fichiers / partitions.

[tatayo]

Bonjour,

Par écraser, on entend en fait un DELETE de l'enregistrement existant suivi d'un ADD de sa mise à jour.

Dans ce cas, pourquoi ne pas faire un INSERT INTO... UPDATE DUPLICATES ? Ainsi tu n'as plus qu'une seule requête au lieu de 2.
De plus si tu as des clé étrangères qui "pointent" sur la ligne à supprimer, un UPDATE DUPLICATES posera moins de problème qu'un couple DELETE/INSERT.

Tatayo.

[michel.souris]

Sauf très bonne nouvelle, HFSQL ne gère ni l'UPSERT, ni le UPDATE duplicates....

http://www.developpez.net/forums/d14...-hyperfilesql/

[Hemgé]

Comme mentionné, nous n'allons certainement pas opérer de manière aussi lourde et massive que le fournisseur des données.
Et ce ne sera pas HFSQL, mais postgreSQL (ODBC - SQL, pas d'accès natif).

L'idée est de
- constituer les paires DELETE / ADD, parce que s'il n'y a pas de ADD, c'est une suppression et s'il n'y a qu'un ADD, c'est une création ... (on dispose quand même d'une date de début et de fin de validité pour contrôle)
- comparer les enregistrements de ces paires entre eux ou avec notre base existante pour identifier les rubriques (colonnes) modifiées
- générer un fichier de mise à jour qui comprendra l'ID, un code de traitement, les couples nom de rubrique (colonne) et nouvelle valeur, au format texte ou XML.
Les couples nom / valeur pourraient être remplacés par une Structure (ou un Enregistrement, ce qui revient au même).
Le tout pourrait être sérialisé ou pas. La réflexion est ouverte.
Il y aura a priori un hashage du fichier.

[michel.souris]

Je répondais plus à la problématique initiale (celle de bruno.a) sur Hyperfile "mais en CS le fichier est de temps en temps occupé par le moteur donc la copie ne passe pas.". D'où l'idée d'un verrou initial... mais après je n'ai pas fait assez attention à la digression de la discussion...

Concernant votre problème je pense que une combinaison d'UPSERT et de DELETE est une bonne piste puisque l'instruction UPSERT est supportée par Postgre.

Concernant le support nous travaillons avec des fichiers XML car ils permettent de s'auto-définir (en ne transmettant par exemple que les champs à mettre à jour et l'ID). En gros un fichier dont la structure correspond au champ de la table à mettre à jour. Le principal défaut de cette solution est que le poids du fichier peut être relativement important car la définition est faite par enregistrement... je sais pas si ces informations peuvent vous être utile !

[bruno.a]

Bonjour à tous

Finalement nous avons procéder de la façon suivante:

1- Nous fabriquons le .FIC et .NDX que nous livrons par l'installation du logiciel ou via Internet/webservice le tout sous forme de ZIP
2- Si HF Classique, nous décompressons le fichier dans la base, Si HFCS, nous décompressons dans le dossier temp de WIndows, et avant de copier le fichier vers la base, nous déconnectons les personnes qui utilisent ce fichier et seulement elles. Si des personnes sont dans le logiciel mais sans utilisation de ce fichier, elle reste connecté.

Pour les plus petits fichiers, nous avons monté un système de sérialisation d'un tableau associatif de chaine avec en Clé le nom du .FIC et en valeur la requete INSERT avec toutes les valeurs à inserer.
Du coup pour la mise à jour, on désérialise le fichier, on fait HSupprimeTout et on execute la requete INSERT

Bruno

[Lo²]

Merci pour le retour bruno.a.

[Invité]

Bonsoir,

@ Hemgé :
Je crois que ce DIF sera extrêmement compliqué à réaliser car il va dépendre de la version du slave.
La moindre imperfection est c'est la cata.
Pour l'avoir expérimenté par le passé, concevoir le DIF est aisé mais reconnaître la version initiale l'est beaucoup moins.
Surtout s'il ne vous est pas possible de contrôler que tous les slaves ont bien appliqué la màj.

Les techniques avec des DIF ou de rejeux de type DEL + INS ressemblent à des algo de réplication.
Rappelons-nous que ces algo comptent parmi les plus complexes de notre métier.

Ce qui a donné de bons résultats sans prise de tête (je pars du principe qu'une première version de la base slave est présente) :
Vous calculez le hash des enregistrements 1 à x puis x+1 à 2x puis ... de la base master
Vous calculez sur la destination (slave) le hash des enregistrements 1 à x puis x+1 à 2x puis ... et vous les comparez à ceux reçus du master
Et vous ne chargez que les "paquets" différents.
Vous pouvez jouer sur la granularité en faisant des paquets plus ou moins gros ou faire 2 passes : Analyse du paquet 1 à 1000 et si différent entre master et slave alors calcul du hash de 1 à 500 puis 501 à 1000
C'est très solide car cela ne dépend d'aucun prédicat initial (le slave peut être dans n'importe quelle version)
Cela ne nécessite aucune table supplémentaire car les hash sont réalisés directement sur les données et à la volée.
C'est très économe en bande passante si les changements entre 2 versions sont faibles (ce qui est généralement le cas sinon on recharge tout !)
Note : Attention de ne pas utiliser des "paquets" de x enregistrements car une suppression sur l'un des 1er enregistrement conduirait à un rechargement total car les hash qui suivent seraient forcément différents entre master et slave.

Cordialement,

[Invité]

En relisant mon post, je m'aperçois que je n'ai pas été très clair sur mon explication des "paquets".
Le hash doit être calculé sur les enregistrement dont l'identifiant est compris entre 1 et x puis entre x+1 à 2x.
Et non sur le paquet des x premiers puis x suivants.
Car dans ce dernier cas si 1 enregistrement du premier paquet est supprimé ce "paquet" et les suivants seront considéré comme modifié (hash différents)