Lister les derniers enregistrements

Bonjour,

Tout d’abord je vous souhaite mes meilleurs v?ux pour cette nouvelle annee.
Je souhaite avoir votre retour d’experience concernant une requete toute simple qui consiste a recuperer les 20 derniers dossiers d’un utilisateur. Cet utilisateur a environ 45000 dossiers dans notre base. Pour recuperer les 20 derniers dossiers nous realisons une recherche sur les dossiers et ensuite nous realisons un trie decroissant sur la date et l’heure de creation.
Auriez-vous une autre facon de faire ?

<code 4D>
CHERCHER ([SIMULATION];[SIMULATION]FkIdUtilisateurCreation=xxx)
TRIER([SIMULATION];[SIMULATION]DateDeSaisieWeb;<;[SIMULATION]HeureDeSaisieWeb;<)

</code 4D>

Pour information les champs [SIMULATION]FkIdUtilisateurCreation, [SIMULATION]DateDeSaisieWeb et [SIMULATION]HeureDeSaisieWeb sont indexes. Autre question, est-il preferable de realiser un index composite entre [SIMULATION]DateDeSaisieWeb et [SIMULATION]HeureDeSaisieWeb ?

Dans l’attente de vos retours.

Cordialement

Bonjour,

Meilleurs voeux a tous

Etant donnee la volumetrie annoncee, je ne suis pas convaincu de l’unicite de la reponse.
45000 dossiers pour un utilisateur. Je me demande immediatement combien d’utilisateurs et de dossiers�c
Dans ce cas, differentes approches seront envisagees, ces solutions dependent certainement de votre contexte, de ce contexte en particulier, et le choix se portera apres les mesures avec le retour d’experimentations.

Qu’importe, faisons l’impasse et essayons de repondre, tout en se rappelant que votre application est une application “web” uniquement.
A priori, sur le CHERCHER, vous n’avez pas de probleme de performances et vous lancez ce fil parce que votre TRIER n’est pas assez rapide

Sans savoir si l’index composite ameliorera, en lisant l’exemple 11 de la :doc: TRIER, on peut predire que le TRI sera sequentiel�c

  • Avez-vous la possibilite de TRIER moins de 45000, c’est a dire de faire une recherche plus selective ? Pourquoi trier 45000 dossiers lorsque les 20 derniers seulement vous interessent ?
    Votre CHERCHER est le meme pour tous et pour trouver les 20 derniers, il vous faut TRIER
    Malgre tout, est-ce que les dossiers vieux de plus de N mois vous interessent dans ce contexte ?
  • Vous pourriez aussi lire ou relire http://www.4d.com/fr/blog/timestampmonamour.htmlles 4 tomes de TimeStamp mon amour>, et vous sortirez du cas 11 et ne triant que sur le TimeStamp
    Assez simple a mettre en place, non ?
    Aller au dela est encore possible, mais avec cela vous devriez ameliorer la situation pour un effort peu consequent

Bonjour,

Tout d’abord merci pour votre retour.
La solution nous a saute aux yeux en meme temps que nous avons lu votre retour. Pourquoi recuperons-nous l’ensemble des dossiers de l’utilisateur depuis 2010 alors que nous n’affichons que les 20 derniers. Nous avons donc pense a filtrer la requete sur les 2 derniers mois.
Concernant le timestamp effectivement c’est je pense la meilleur solution. Nous y avions pense mais nous voulions avoir un avis exterieur.

Merci pour votre aide.

Cordialement

Je penserais a http://doc.4d.com/4Dv15R5/4D/15-R5/SCAN-INDEX.301-2937734.fr.htmlSCAN INDEX>. Si la cle primaire de la table est un entier long sequentiel, ca le fait. Si c’est un uuid, loupe, mais un petit timeStamp fera l’affaire (et remplacera avantageusement la paire de rames [SIMULATION]DateDeSaisieWeb / [SIMULATION]HeureDeSaisieWeb.)

Bonsoir,

Petit retour sur votre autre question

: Alexandre CHANOIR

Autre question, est-il preferable de realiser un index composite
entre [SIMULATION]DateDeSaisieWeb et [SIMULATION]HeureDeSaisieWeb ?
Pour ameliorer votre TRIER; Oui, tres certainement !
C’est ecrit dans la :doc:, et c’est aussi ecrit sur ce forum, dont un fil lance par votre collegue Arnaud
Sinon, et en reprenant le slogan : “pourquoi 4D se decarcasserait ?”
Dans la pre-classe du dernier 4D Summit, a la fin de la presentation d’Olivier sur l’optimisation de code, il y a clairement un appel a utiliser les index composites, puisque c’est gratuit et que cela ameliore les recherches et les tris sans changement de code�c
Plus loin encore, et en relisant mes notes de l’epoque du tour de France de la v11, une demo sur un index composite nom + prenom montrait un gain proche de 100. Avec un tel score, on peut supposer que l’index est bel et bien utilise et que ce tri - avec index composite - n’est pas sequentiel (au contraire de l’exemple 11 de la :doc: sur TRIER)

Quoiqu’il en soit, je reste persuade que dans le cas que vous presentez (Date+Heure), alors le TimeStamp (index sur entier long) donnera un meilleur resultat que l’index composite sur vos 2 champs Date et Heure
Mais evidemment, la mise en place du TimeStamp vous demandera un peu plus de temps.

Pourriez-vous faire les tests comparatifs et nous en donner les resultats puisque vous avez toute la matiere ? Ce serait interessant�c
Merci par avance.
Attention l’index composite n’est pas commutatif pour le TRI, comme il est dit dans le fil cite plus haut.

Bonjour,

J’ai fait les tests comparatifs en utilisant une boucle de 50 appels et en redemarrant la base et la machine entre chaque cas de test. Comme vous pourrez le remarquer le tri sur un timestamp est moins performant que le tri sur le champ date et heure avec un index composite. La difference est enorme sur le premier appel ce qui est lie au chargement du cache et est ensuite nivelee. Je vous joins ci-dessous les resultats :

Cordialement

: Alexandre CHANOIR

La difference est enorme sur le premier appel ce qui est lie au
chargement du cache et est ensuite nivelee.
Il y a une facon simple de pallier a cela, “chauffer le cache” au lancement de la base - genre chercher 1 ou 2 trucs dans les simulations. Cela dit, le lancement de la base n’est pas la situation “usuelle”.

Bonjour Alexandre,

Tout d’abord, merci pour la production de ces resultats
Eh bien, je dois avouer que j’ai perdu mon pari… :cry: Heureusement, je suis bien assis !
A moins que, a moins que…le TimeStamp est bien un Entier Long (n’est pas un Alpha) et lui aussi est indexe ?

En effet, le premier appel correspond au chargement du cache et pourrait sortir de l’analyse

Bonjour Jean-Jacques,

Effectivement les resultats sont bizarres. Je te confirme que le timestamp est bien un entier long et qu’il est indexe en automatique. Le premier appel n’est pas representatif et ne correspond pas a la realite mais permet de voir la rapidite de chargement du cache. L’interet etait uniquement d’isoler les cas de test.

Cordialement

Comme vous pourrez le remarquer le tri sur un timestamp est moins
performant que le tri sur le champ date et heure avec un index
composite
Effectivement les resultats sont bizarres.
? le stockage par 4D d’une date fait 8 octets, celui de l’heure pareil
? le long utilise comme timestamp fait 4 octets
Soit 4 fois moins pour la meme information, ce dans une table qui semble chargee en enregistrements (combien, au fait ?). C’est le genre de truc qui ferait qu’a ta place je ne tiendrais aucun compte du resultat de ce test.

J’etais reste sur l’idee que la requete, c’est “les 20 dernieres simulations de l’utilisateur courant” : pourquoi parles-tu de “filtrage sur 2 mois” ?

Diable :evil:, j’ai perdu !

: Alexandre CHANOIR

Effectivement les resultats sont bizarres.
Etant demandeur de ces resultats, je me serais bien garde de cette affirmation.
Apres toi, je dis mon etonnement.

Combien de simulation(s) avec le meme TimeStamp ?
Pour ce qui est le l’index, j’aurais donc ose faire le choix et j’aurais opte pour un b-tree, mais je ne crois pas que ce sera determinant pour changer les resultats deja affiches.

Bonjour Arnaud,

Suite a une proposition de Jean-Jacques de realiser un filtrage sur les 2 derniers mois afin d’avoir moins elements a trier j’ai inclus ce cas dans les tests de performance. Outre le gain de place il est bizarre qu’un timestamp soit plus lent qu’un index composite sur des champs date et heure.

Cordialement

Outre le gain de place il est bizarre qu’un timestamp soit plus lent
qu’un index composite sur des champs date et heure.
J’y insiste, mais je ne tiendrais aucun compte de ce constat. Le timestamp ne peut pas etre moins efficace.

: Alexandre CHANOIR

Suite a une proposition de Jean-Jacques de realiser un filtrage sur
les 2 derniers mois afin d’avoir moins elements a trier j’ai inclus
ce cas dans les tests de performance.
Vu ; comme le tri n’est pas le fort de 4d, on l’evite et si on ne peut pas on le limite.

Quel est le type du champ [SIMULATION]FkIdUtilisateurCreation ?
Combien y a t-il d’enregistrements dans les tables [SIMULATION] et [UTILISATEUR] ?
Quel sont les min/max/moyenne de saisie de simulations par utilisateur / periode ?

Je ne connais pas la volumetrie, mais 2 mois pour avoir les 20 derniers, ca ne me plait pas. Si tu as un user qui n’a rien simule sur cette periode et un autre qui a bosse d’arrache-pied, ca revient a taper largement au-dela des 20 demandes pour esperer les y trouver, apres un tri. Je privilegierais une approche qui donne d’emblee ce qui est attendu, ou au plus pres.

: Arnaud DE MONTARD

Quel est le type du champ [SIMULATION]FkIdUtilisateurCreation ?
Combien y a t-il d’enregistrements dans les tables [SIMULATION] et
[UTILISATEUR] ?
Quel sont les min/max/moyenne de saisie de simulations par
utilisateur / periode ?

Je me permets de repondre, travaillant sur le meme sujet qu’Alexandre.

[SIMULATION]FkIdUtilisateurCreation : entier long (indexe automatique)
[SIMULATION] : 556 000 enregs
[UTILISATEUR] : 12 300 enregs

Nous n’avons pas de stats sur les min/max/moyenne. C’est effectivement une etude a mener pour voir comment affiner la requete.

Concernant le choix de 2 mois, c’est plutot un test pour voir si on peut ameliorer les performances en limitant, ce qui n’est pas le cas finalement.

D’apres tes chiffres, ca fait une moyenne de 45 simus/user, c’est assez peu pour tenter un truc du genre :
chercher (toutes les simus de l’utilisateur)
selection vers tableau(numero enregistrement;t1;timestamp;t2)
trier les tableaux t1/t2 par t2 decroissant
ne garder que les 20 du debut de t1
creer selection sur tableau(t1)