|
FOROS PROFESIONALES
WINDEV, WEBDEV y WINDEV Mobile |
| | | | | |
| un très gros tableau en mémoire |
| Iniciado por roumegou, 04,ene. 2019 14:58 - 7 respuestas |
| |
| | | |
|
| |
| Publicado el 04,enero 2019 - 14:58 |
Bonjour
je dois charger un très gros tableau en mémoire
cela contiendra 3,5 millions d'items (et surement plus) et je vais
devoir vérifier que mon item n'existe pas déjà dans ce tableau.
J'ai déjà essayé de charger ce tableau à chaque client traité (et
n'avoir qu'un nombre limité dans ce tableau) mais cela fait trop de
requetes et ce n'est pas viable du tout en temps de réponse.
Du coup je veux tout charger en mémoire et tester en mémoire
Donc voici mes questions
Quel est le moyen le plus performant ?
- un tableau associatif et je peux tester l'existence de l'item
- un tableaucherche sur un tableau de chaine
- peut être uen zone mémoire (memcree) que je n'ai pas utilisée depuis
des années; mais peut être est-ce plus performant ?
Voilà en gros mon pb est de répondre à la question suivante
- est ce que pour un couple code client + email, j'ai déjà fait
l'action n° x ?
sachant que je pose cette question au moins 6 fois pour 650000 clients
Merci de vos réponses
--
Roumegou Eric
---
Cet email a fait l'objet d'une analyse antivirus par AVG.
http://www.avg.com |
| |
| |
| | | |
|
| | |
| |
| Publicado el 04,enero 2019 - 15:21 |
Roumegou Eric avait écrit le 04/01/2019 :
Bonjour
je dois charger un très gros tableau en mémoire
cela contiendra 3,5 millions d'items (et surement plus) et je vais devoir
vérifier que mon item n'existe pas déjà dans ce tableau.
J'ai déjà essayé de charger ce tableau à chaque client traité (et n'avoir
qu'un nombre limité dans ce tableau) mais cela fait trop de requetes et ce
n'est pas viable du tout en temps de réponse.
Du coup je veux tout charger en mémoire et tester en mémoire
Donc voici mes questions
Quel est le moyen le plus performant ?
- un tableau associatif et je peux tester l'existence de l'item
- un tableaucherche sur un tableau de chaine
- peut être uen zone mémoire (memcree) que je n'ai pas utilisée depuis des
années; mais peut être est-ce plus performant ?
Voilà en gros mon pb est de répondre à la question suivante
- est ce que pour un couple code client + email, j'ai déjà fait l'action n° x
?
sachant que je pose cette question au moins 6 fois pour 650000 clients
Merci de vos réponses
je me réponds même si je reste tout ouie pour vos conseils ...
zone mémoire c'est déprécié au profits des tableaux associatifs
tableaucherche ça va faire cher la recherche
je pars sur le tableau associatif. reste plus qu'à tester sur un tel
volume cette nuit
--
Roumegou Eric
---
Cet email a fait l'objet d'une analyse antivirus par AVG.
http://www.avg.com |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
1.330 mensajes |
|
| Publicado el 04,enero 2019 - 15:34 |
Salut Eric,
Quel est le type que tu vas stocker dans ton tableau, est-ce le code client + email ? (Un tableau de booléen ou un tableau de buffer, c'est pas vraiment la même taille) 
Et concernant la seconde question, je suppose que c'est un minimum de 6 actions par client, donc au minimum soit 3.900.000 requêtes
A+
Daryl
--
http://www.concept4u2.com |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
36 mensajes |
|
| Publicado el 04,enero 2019 - 15:39 |
Salut Eric,
on dirait que tu cherches à réinventer la roue (pardonne moi l'expression).
pourquoi ne pas utiliser la base (SQL) directement ?
Les données proviennent bien d'une base, non ?
Piste utile : tu peux utiliser une ou plusieurs tables temporaires pour stocker un pré-filtrage de tes résultats.
Ces tables sont spéciales et n'existe que dans la mémoire du serveur en principe (pas d'accès disque du cou).
Tu bénéficieras de la puissance de SQL en prime...
Bon courage !
Olivier |
| |
| |
| | | |
|
| | |
| |
| Publicado el 04,enero 2019 - 16:48 |
Olivier a formulé ce vendredi :
Salut Eric, on dirait que tu cherches à réinventer la roue (pardonne moi l'expression). pourquoi ne pas utiliser la base (SQL) directement ? Les données proviennent bien d'une base, non ? Piste utile : tu peux utiliser une ou plusieurs tables temporaires pour stocker un pré-filtrage de tes résultats. Ces tables sont spéciales et n'existe que dans la mémoire du serveur en principe (pas d'accès disque du cou). Tu bénéficieras de la puissance de SQL en prime... Bon courage ! Olivier --- Cet email a fait l'objet d'une analyse antivirus par AVG. http://www.avg.com
merci à tous de vos intérets pour mon problème
pour le sql, oui, étant la langue je maitrise le mieux après le
francais lol j'avais au début tout généré en sql avec des group_concat
et tout et tout
ça marchait très bien et ça restait viable en temps de traitement mais
(je passe sur le détail du traitement qui demande énormément de tests
avec des jokers etc ...) j'en arrivais à générer 70 milions de lignes
et il me restait à travailler sur cette table pour prendre les 6
meilleurs par clients etc ...
et là Mysql niveau mémoire, il n'en voulait plus.
J'aurais pu faire du tuning mais bon ce n'était pas très viable
Donc j'ai travaillé avec des tableaux de structure et arrivé à une
situation viable (3h1/2 de traitement) sauf que je n'avais pas encore
intégré le "si ça déjà été pris avant, ce n'est plus à prendre"
et donc là le rechercher en sql c'est comme disait Daryl 3.900.000
requetes (pas Glop!). Sinon c'est maxi 6 car dès qu'on en a trouvé 6;
on arrete pour le client concerné.
Du coup le tableau associatif (dont j'use et j'abuse depuis un moment)
me semble la bonne solution. Il vaut mieux tout charger en un coup et
travailler en tableau que de le faire pour occurence. C'est incroyable
en terme de gain de temps. Mais mon interrogation que j'espère lever
cette nuit, est le volume que va prendre ce tableau.
Et que va-t-il contenir pour répondre à Daryl ? oui une clé bien trop
longue à mon gout mais pas le choix car je n'ai pas d'identifiants. ce
sera n°d'action+codeclient+email donc si je requete une moyenne de
caract sur ma base j'obtiens 38 caract de moyennes
en disant cela je me demande si je n'aurais pas du générer mes propres
identifiants sur le fichier clients ... histoire de faire maigrir
drastiquement ce tableau
Comme quoi réexpliquer son problème fait souvent penser à des
solutions.
--
Roumegou Eric |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
96 mensajes |
|
| Publicado el 04,enero 2019 - 17:18 |
Bonjour (et bonne année),
ne serait-il pas possible de voir le problème autrement ?
D'après ce que j'ai compris, vous avez plusieurs actions à effectuer pour un client et une adresse mail donnée. Et vous ne devez faire chacune de ces actions qu'une seule fois.
Voici mon hypothèse :
Ne pourrait-on pas inverser le problème et dire :
Je fais l'action x pour le client y
Je fais l'action x + 1 pour le client y
Je fais l'action x + 2 pour le client y
J'arrête le traitement du client y dès que 6 actions ont été effectuées.
Je fais l'action x pour le client y + 1
Je fais l'action x + 1 pour le client y + 1
Je fais l'action x + 2 pour le client y + 1
J'arrête le traitement du client y + 1 dès que 6 actions ont été effectuées.
Si vous pouvez faire le traitement ainsi, il n'est plus nécessaire de stocker quelle action a été effectuée pour un client donné. Vous pourriez faire en un seul parcours l'ensemble de vos actions.
Dans tous les cas, pourriez-vous nous donner un peu plus de détail sur le traitement que vous souhaitez effectuer ? Cela permettra certainement de faire sortir d'autres idées.
Bonne journée à vous.
--
Johjo aka Jonathan Laurent
Codez mieux ! Codez plus vite !
Mon blog sur WinDev : http://www.ytreza.org
Me contacter sur slack (wx-community) : https://frama.link/BoBD0SY0
Faîtes moi un ping : http://www.ytreza.org/fr/services/ping-sur-forum |
| |
| |
| | | |
|
| | |
| |
| Publicado el 04,enero 2019 - 17:51 |
Johjo avait prétendu :
Bonjour (et bonne année),
ne serait-il pas possible de voir le problème autrement ?
D'après ce que j'ai compris, vous avez plusieurs actions à effectuer pour un
client et une adresse mail donnée. Et vous ne devez faire chacune de ces
actions qu'une seule fois.
Voici mon hypothèse :
Ne pourrait-on pas inverser le problème et dire :
Je fais l'action x pour le client y
Je fais l'action x + 1 pour le client y
Je fais l'action x + 2 pour le client y
J'arrête le traitement du client y dès que 6 actions ont été effectuées.
Je fais l'action x pour le client y + 1
Je fais l'action x + 1 pour le client y + 1
Je fais l'action x + 2 pour le client y + 1
J'arrête le traitement du client y + 1 dès que 6 actions ont été effectuées.
Si vous pouvez faire le traitement ainsi, il n'est plus nécessaire de stocker
quelle action a été effectuée pour un client donné. Vous pourriez faire en un
seul parcours l'ensemble de vos actions.
Dans tous les cas, pourriez-vous nous donner un peu plus de détail sur le
traitement que vous souhaitez effectuer ? Cela permettra certainement de
faire sortir d'autres idées.
Bonne journée à vous.
merci Johjo de votre réponse
le truc est celui là
j'ai environ 150 actions marketing de possibles sur un mois pour un
client
sur ces 150 actions on définit ce qu'on appelle des déclencheurs qui
vont tester le pays du client, son code fonction, ses centres
d'intérets, ce qu'il a déjà acheté, ce qu'il a vu ...
on a 7 déclencheurs différents avec des trucs du genre toutes les
fonction 10101 ou toutes les fonctions qui commencent par 1
donc un vrai petit casse-tête, enfin surtout beaucoup de traitements
dans les bases.
et il faut traiter les déclencheurs dans un certain ordre, et prendre
les meilleurs donc on a aussi un scoring.
Du coup je suis bien obligé de passer sur les 150 actions, et
d'appliquer ma cuisine selon les caractéristiques du client vs l'action
et ses déclencheurs. Et c'est là qu'un tableau de stucture et bien
c'est cool !!!
Ensuite je prends les 6 meilleures actions selon le scoring et les
priorités fixées. Et la prochaine fois, et bien je ne devrais pas
reprendre les actions déjà prises.
Après pas mal de travail je suis content de mon algo. Sur mille clients
(base de tests) ça me prends 18 secondes
Mais sur 700000 je tombe sur des difficultés.
je viens encore d'optimiser mon truc notamment en travaillant avec des
id
je vous tiens au courant sur le lancement "en base réel" du bouzin
--
Roumegou Eric
---
Cet email a fait l'objet d'une analyse antivirus par AVG.
http://www.avg.com |
| |
| |
| | | |
|
| | |
| |
| Publicado el 07,enero 2019 - 09:14 |
Le 04/01/2019, Roumegou Eric a supposé :
Il vaut mieux tout charger en un coup et travailler en tableau que de le
faire pour occurence. C'est incroyable en terme de gain de temps. Mais mon
interrogation que j'espère lever cette nuit, est le volume que va prendre ce
tableau.
Bon le chargement d'un tableau associatif de booleen (id en clé,
booleen) avec 3 à 4 millions d'occurences bloque mon traitement comme
je le craignais.
Du coup je suis passé par une requete sur le mysql; un truc génial que
j'utilise depuis quelques temps : le group_concat.
Je fais un select group_concat de mes actions en group by client.
Du coup une table temporaire, créée comme cela avec une reindexation
ensuite sur l'id client.
Je fais une jointure gauche avec ma table des 700000 clients et je
dispose des id déjà utilisés séparés par des virgules.
Reste plus qu'à charger ces id en tableau (maxi 4 x 6 au bout d'un
mois)et faire un tableaucherche pour vérifier s'ils existent déjà.
et c'est à peine plus long qu'avant.
C'est édifiant comme quoi il existe toujours plusieurs solutions; ni
bonnes ni mauvaises, juste à trouver la plus adaptée.
Merci de vos aides qui m'ont été précieuses comme d'habitude.
--
Roumegou Eric
---
Cet email a fait l'objet d'une analyse antivirus par AVG.
http://www.avg.com |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|