IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Persistance des données Java Discussion :

Stockage en java : JDBC, Fichier ;GC Collector ?


Sujet :

Persistance des données Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    94
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2010
    Messages : 94
    Par défaut Stockage en java : JDBC, Fichier ;GC Collector ?
    Bonjour,

    Je travaille actuellement sur un projet en Java.

    Ce projet a pour objectif de calculer au minimum 1 million de montant individuel pour 50 000 individus.

    J'ai rencontré un problème de stockage en java ''head space memory" après avoir mis en paramètre -xmx le problème a permis d'augmenter le nombre de données à stocker mais pas entièrement..

    On m'avait alors conseillé d'utiliser les randomaccessfile, choses faites, cependant à la sortie le fichier faisait plus de 140 go et les temps de calculs (dû à l'écriture dans le fichier) avaient été rallongés de 12h.

    Je me suis alors mis en tête la mise en place d'une base de données (JDBC) afin de pouvoir stocker l'ensemble des ces montants. N'ayant jamais eu d'expérience opérationnel en base de données sur "un tel volume", je viens vers vous afin de savoir si cette solution en est bien une. Comment connaître la capacité maximale de stockage avec une BD (par rapport aux disques durs et aux données) et surtout comment prévoir la capacité minimale pour stocker ces informations (en fonction du type de variables...)

    J'avais même pensé à faire du grid computing, afin d'améliorer les temps de calculer et stocker sur plusieurs PC en même temps les résultats...

    Etant junior, le point de vue "mise en place" reste flou!!

    Merci d'avance

  2. #2
    Modérateur
    Avatar de dinobogan
    Homme Profil pro
    ingénieur
    Inscrit en
    Juin 2007
    Messages
    4 073
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France

    Informations professionnelles :
    Activité : ingénieur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 4 073
    Par défaut
    Si tu écris dans ton fichier à chaque résultat sans buffer, il est normal de "pourrir" les accès disques.
    Tu devrais faire le test avec un java.io.BufferedOutputStream en ajustant la taille du buffer. Celui n'écrira effectivement sur le disque que lorsque le buffer sera plein, et il écrira un grand bloc d'information. Par contre c'est à toi de spécifier la taille du buffer : tu peux débuter par 8 Mo par exemple.
    La difficulté est de trouver le juste milieu entre demander rarement un accès disque en écriture et écrire rapidement le buffer sur disque.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java
    Que la force de la puissance soit avec le courage de ta sagesse.

  3. #3
    Membre confirmé
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    94
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2010
    Messages : 94
    Par défaut
    Le problème se pose surtout pour la mise en place d'une base de données.

    la solution du fichier étant moins performante que la DB car je dois stocker d'autres informations relatives aux montants (quel individu, etc...) et surtout pouvoir travailler avec (java, ou des DB)

  4. #4
    Membre très actif
    Profil pro
    Inscrit en
    Février 2010
    Messages
    767
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2010
    Messages : 767
    Par défaut
    Il y a fichiers et fichiers, de même qu'une base de donnée sans index donnera des solutions toutes pourries. Mais les fichiers indexés c'est un peu la pré-histoire, mais après tout si le traitement si prette pourquoi pas.

    JDBC n'est qu'une api d'accès a une Datasource. Il te faut utiliser une base de donnée, comme Oracle, Mysql, etc ... correctement indexé.
    Pour optimiser encore plus les accès tu peux avoir recours aussi a un cache comme ehcache par exemple.

    Après il faut aussi réflechir a tes accès, evidement avoir 140Go de donnée en RAM est impossible, mais si tu peux découper un peu ton algorithme.
    Tu peux charger partiellement en RAM par paquet de 1Go par exemple et écrire en un seul coup le résultat. Ca sera plus rapide que de traiter un par un tes enregistrements.

    Bref réflechir a une optimisation est un travail complexe, il n'y a pas toujours des outils tout fait pour ça.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Audio]Java et fichiers Wav
    Par danael dans le forum Multimédia
    Réponses: 3
    Dernier message: 10/10/2005, 20h09
  2. [JAVA/JDBC]pb executeQuery()
    Par david06600 dans le forum JDBC
    Réponses: 4
    Dernier message: 04/07/2005, 16h10
  3. [jdbc] fichier de config
    Par calimero82 dans le forum JDBC
    Réponses: 14
    Dernier message: 21/06/2005, 13h48
  4. [SAX] Passer d'objet java en fichier XML?
    Par spoutyoyo dans le forum Format d'échange (XML, JSON...)
    Réponses: 15
    Dernier message: 05/01/2005, 08h31
  5. [Stockage] Image dans un fichier XML
    Par ovh dans le forum XML/XSL et SOAP
    Réponses: 4
    Dernier message: 30/04/2003, 16h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo