Discussion :

[maccormick]

Bonjour,
Je travaille actuellement sur un analyseur de listes de discussion. Chaque liste peut contenir de 100 messages à 200 000 messages, chaque message une douzaine de champs.
Je dois faire des statistiques sur ces messages. Le problème, c'est que pour effectuer ces statistiques, je dois extraire les messages puis les manipuler pour les classer, les trier ... etc.
Tout marche très bien avec 10 000 voire 50 000 messages. Mais le problème se corse avec 200 000 messages, ce qui entraine des dépassements de mémoire, que cela soit en tout objet (si j'utilise l'objet Message), ou en base de données (table Message).
Dans le premier cas, la mémoire se sature lorsque j'applique des comparators sur plusieurs critères à mes messages (par sujet ET par date par exemple) afin de classifier les messages en discussion.
Dans le second cas (avec H2), la mémoire se sature lorsque je fais un simple SELECT sur 3 champs de ma table Message.

Java est-il inadéquat dans mon cas de manipulation de grandes quantités de données ou avez-vous des idées qui pourraient me sortir de l'impasse ?

[biljava]

Bonjour maccormick,

Je ne sais pas quels types de comparaisons tu souhaites faire, si tes données sont rangées dans un fichier Excel tu peux faire des comparaisons statistiques avec matlab (voir scilab qui est gratuit), donne nous plus de precisions sur le type de comparaisons.

[maccormick]

Salut,
Je travaille directement sur les fichiers EML :
1/ j'importe une boite aux lettres (répertoire de fichiers EML)
2/ j'extrais les messages avec l'API javamail (getSubject(), getFrom() ... etc
3/ je fais des calculs dessus, notamment la classification en conversation, ce qui me pose actuellement problème. Voilà comment ça se déroule :
1/ je tronque les sujets des messages à 15 caractères, en ayant enlever tous les caractères supplémentaires (-, ., ... etc)
2/ je range les messages selon leur sujet tronqué ET leur date d'envoi
3/ j'itère ma liste de message et je les classe en conversation selon :
- si le message en cours a le même sujet tronqué que le précédent, je regarde sa date d'envoi. si celle-ci est inférieure ou égale au paramètre fourni, je le range dans la même conversation, sinon je crée une nouvelle conversation
- sinon, je regarde sa distance de Levenshtein d'avec le message précédent (qui est une distance calculée selon les caractères en commun) : si elle est inférieure au paramètre fourni, je regarde la date puis je le range ou pas dans la même conversation, sinon je crée une nouvelle conversation

Mon algorithme repose donc essentiellement sur le TRI (j'effectue ensuite d'autres statistiques dans lesquels j'effectue beaucoup de tris) et le problème vient de là lorsque je ne fais que de l'objet (un comparator sur 2 paramètres sur 200 000 messages me plantent le système !)

[NeptuS]

Apparemment, ton problème vient de tes stats.
Je ne pense pas que tu devrais tout charger en mémoire.

Tout d'abord : une question : Mis à part pour les statistiques, as-tu besoin de garder tous les messages après intégration ?

2 pistes s'offrent à toi :
- Construire (calculer) tes statistiques au fur et à mesure de l'intégration (sans stockage en mémoire : les données ne font que passer, seules les stats restent).
- Si, comme tu l'as évoqué précédemment, tu stocke tout en base, pourquoi ne récupères-tu pas des stats via des storeProc ? (Attention : le calcul devra se faire dans la requête : ici encore, tu ne charge pas tout en mémoire pour calculer les stats en java, mais bien en SQL)

[maccormick]

Tout d'abord : une question : Mis à part pour les statistiques, as-tu besoin de garder tous les messages après intégration ?

Pour l'instant oui, mais je réfléchis à l'usage d'avoir 200 000 messages sous les yeux

[Robin56]

- Si, comme tu l'as évoqué précédemment, tu stocke tout en base, pourquoi ne récupères-tu pas des stats via des storeProc ?

Histoire de clarifier les choses, je suppose que tu sous-entends par "storeProc", les procédures stockées ?

[NeptuS]

Oui.
Il manque peut-être un 'd', histoire d'écrire en Anglais presque correct : "storedProc", Alias "Stored Procedure"

[Jimmy_]

Bonjour,

Il ne faut pas tout charger en mémoire, avec un volume pareil il te faut une stratégie différente. Tu dois faire un batch qui prépare tes données dans des bases temporaires. Ensuite tu construits tes stats à partir de ces tables pré-calculées.

Ensuite, il ne faut pas se leurrer pour de tel volume il faut une machine puissante.

[maccormick]

Oui oui, effectivement, à la base (c'est le cas de le dire ) j'ai un problème de conception, mais je sens quand même que d'avoir laisser tomber les bases de données me facilite le travail, et que je n'ai qu'à trouver un autre algo de classification ...
et en plus les stored procedures ne vont ps m'aider je pense, car les calculs sont trop compliqués ...

[NeptuS]

Qu'est-ce que tu entend par "trop compliqués" ? Peux-tu donner un exemple de
Tu veux dire par là que tu n'arriverai pas à faire la requête ou bien que le SGBD n'en est pas capable ?

Autre info importante : Tes stats devront-elles être calculées en temps réel ? Seront-elles historisées ?

Si tu stocke tes données sur le filesystem, tes temps de recherche vont augmenter de façon exponentielle avec le volume, alors que si tu utilise un SGBD, le temps de recherche augmentera à peu près linéairement grâce aux index.
Dans les 2 cas, la recherche multi-critères augmente grandement le temps de réponse.

[lunatix]

mais si faut tout charger en mémoire (si tu veux des grosses perfs), faut juste le faire proprement.

plusieurs choix : memcache (un demon unix que tu peux sharder sur plusieurs machines). ça fait du clé valeur, c'est limitant en terme de modele. mais après, tu peux tout parcourir comme un bourrin, et comme c'est pas de la mémoire java, pas de probleme de GC

autre solution : Grid computing + mapReduce pour le requetage.
voir http://fr.wikipedia.org/wiki/Hadoop hadoop par exemple.

(bon, c'est pas du petit projet pour rigoler par contre, mais une vraie solution industrielle de traitement de données en masse)