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

 PostgreSQL Discussion :

Configuration de Postgres pour des données volumineuses


Sujet :

PostgreSQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Inscrit en
    Décembre 2010
    Messages
    172
    Détails du profil
    Informations forums :
    Inscription : Décembre 2010
    Messages : 172
    Par défaut Configuration de Postgres pour des données volumineuses
    Bonjour,

    j'ai un petit souci dans le stockage des données binaire dans une table de type "BYTEA". je m'explique.

    j'ai crée une table de type "BYTEA" je peux donc aller jusqu'à 1Go par ligne ..mais le problème qui se pose une fois la donnée à stocker dépasse 10Mo je ne peux pas l'insérer dans ma table ?!.. tout les donnée inférieur à 10Mo je les stocke et je les récupère facilement sans aucun problème ...

    l'erreur que j'ai lors du stockage d'une donnée de 700Mo
    le code java pour stocker mes données:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
     
    try {
     
                Class.forName("org.postgresql.Driver");            
                   Connection conn = DriverManager.getConnection("jdbc:postgresql://localhost:5432/NOM_BDD","postgres","MOTDEPASSE");
     
                FileInputStream intput_stream_data = new FileInputStream(new File("C:\\test_donnee\\video.avi"));
                try
                {            
                PreparedStatement ps = conn.prepareStatement("insert into bdd_binaire (nom_bdd_binaire, contenu_bdd_binaire) values (?,?)");
                try
                {
     
                ps.setString(1,"video");
                ps.setBinaryStream(2, intput_stream_data, (int)(new File("C:\\test_donnee\\video.avi")).length());
                ps.executeUpdate();
                }
                finally
                {
                    ps.close();
                }
                }
                finally
                {
                    intput_stream_data.close();
                }
                         conn.close();
                } catch (Exception e)
                  {           
                    e.printStackTrace();
                  }
     
                         }
    le code pour les récuper depuis ma BDD

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
     
     try
                {
     
                PreparedStatement ps = conn.prepareStatement("select contenu_bdd_binaire from bdd_binaire where nom_bdd_binaire=?");
                try
                {
                ps.setString(1,"video");
                ResultSet rs = ps.executeQuery();
                try
                {
                if(rs.next())
                {
                   java.io.InputStream istreamImage = rs.getBinaryStream("contenu_bdd_binaire");
                   byte[] buffer = new byte[1024];
                   int length = 0;
     
                while((length = istreamImage.read(buffer)) != -1)
                {
                    output_data.write(buffer, 0, length);
                }
                }
                }
                finally
                {
                rs.close();
                }
                }
                finally
                {
                ps.close();
                }
                }
                finally
                {
                    output_data.close();
                } 
     
                conn.close();
                } catch (Exception e)
                  {           
                    e.printStackTrace();
                  }
    j'ai essayé de stocker une donnée de 700Mo dans ma table et voici l'erreur que j'ai eu dans mon IDE Eclipse :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    org.postgresql.util.PSQLException: ERREUR: mémoire épuisée
      Détail : Échec d'une requête de taille 734068740.
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2103)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1836)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:512)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:388)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:334)
        at BDD_BINAIRE.main(BDD_BINAIRE.java:29)
    Ma question est simple : il est ou le probleme est-ce que mon code java ou bien la configuration de mon postgres?

    la conficguration de mon Postgres (la mienne est par défaut)est la cause de ce probleme comment je peux ajuster cette dernière pour corriger le coup.

    je note aussi que je utilise une machine dont voici les performance:
    Dual CPU 2.4Ghz, 2.00Go de RAM

    Merci d'avance pour les réponses

    A+

  2. #2
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Par défaut
    Pourquoi vouloir stocker des fichiers aussi volumineux dans PostGreSQL ?
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  3. #3
    Membre confirmé
    Inscrit en
    Décembre 2010
    Messages
    172
    Détails du profil
    Informations forums :
    Inscription : Décembre 2010
    Messages : 172
    Par défaut
    Citation Envoyé par gorgonite Voir le message
    Pourquoi vouloir stocker des fichiers aussi volumineux dans PostGreSQL ?
    parceque j'ai des fichier et des document de tel taille c'est simple en plus 150Mo ce n'est pas vraiment volumeneux!

    A+

  4. #4
    Expert confirmé
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 173
    Par défaut
    bonjour,

    le type BYTEA est fait pour stocker ... des strings.

    Comme sa description l'indique.

    regardez du côté des large object : http://www.postgresql.org/docs/9.2/s...geobjects.html


    Une solutions plus simple serai de stocker vos objets sur un serveur de fichier.

  5. #5
    Membre Expert
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    1 874
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Octobre 2008
    Messages : 1 874
    Par défaut
    Dual CPU 2.4Ghz, 2.00Go de RAM
    Il ne faut pas chercher plus loin, avec 2Go de RAM au total, une application peut difficilement allouer 700Mo consécutifs. Surtout que comme les données sont baladées du client au serveur et éventuellement encodées en texte entre temps, cette taille doit généralement être allouée plusieurs fois simultanément.

    Pour éviter le problème il faudrait morceller le bytea en pièces de 10Mo par exemple.

  6. #6
    Membre confirmé
    Homme Profil pro
    Inscrit en
    Février 2013
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : Février 2013
    Messages : 23
    Par défaut
    Citation Envoyé par zpico Voir le message
    parceque j'ai des fichier et des document de tel taille c'est simple en plus 150Mo ce n'est pas vraiment volumeneux!

    A+
    On peut aussi planter des clous avec un tournevis. Ce n'est pas parce qu'on peut le faire que c'est forcément une bonne idée. Vous n'avez vraiment pas intérêt à stocker des fichiers aussi énormes dans une base de données de ce type. Ce n'est pas fait pour ça. Laissez-les plutôt sur le système de fichiers. Il y a de grandes chances que ça aille plus vite et que ce soit bcp plus simple du coté du codage Java en passant par NIO plutôt que JDBC.

  7. #7
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 995
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 995
    Billets dans le blog
    6
    Par défaut
    Ou utiliser ce que la norme SQL:1999 appelle le DATALINK, c'est à dire un stockage de fichier dont l'intégrité la consistance l’isolation et le transactionnement est assuré sous la responsabilité du SGBDR de manière à garantir la synchronicité de vos données relationnelles et de vos fichiers et ce sauvegarde/restauration comprises (ce qui n'est jamais le cas des systèmes découplés).

    Malheureusement cette technique n'existe pas sous PostGreSQL.

    Cela est par contre implémenté sous MS SQL Server sous le nom générique de FileStream et pour un contrôle globale des arborescence de stockage, SQL Server 2012 y a rajouté le filetable...
    C'est une des raison pour laquelle de nombreuses GED et/ou Knowledge management systemes utilisent SQL Server....

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  8. #8
    Membre éclairé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Janvier 2008
    Messages
    254
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : Janvier 2008
    Messages : 254
    Par défaut
    Pour ma part je stocke des fichiers binaires (max qlq Mo) dans ma base PostgreSQL 9.2 avec le type OID. En Java on manipule ça avec getBlob et setBlob de l'interface JDBC.

    Je viens de tester avec un fichier de 206Mo et cela fonctionne très bien.

Discussions similaires

  1. Securité et fiabilité d'un CMS pour des données sensibles
    Par psyghost dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 4
    Dernier message: 21/01/2011, 14h57
  2. Equivalent à IN pour des données de type point?
    Par Mazike dans le forum PostgreSQL
    Réponses: 0
    Dernier message: 26/09/2010, 10h28
  3. Réponses: 5
    Dernier message: 26/08/2009, 19h43
  4. Réponses: 1
    Dernier message: 21/05/2008, 20h23
  5. Réponses: 1
    Dernier message: 24/10/2006, 00h24

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