Le portail francophone de la géomatique

EmilieCCBE · Mon 04 February 2019 09:55

Bonjour,

dans le cadre de la mise en place d'une base de données au sein d'une collectivité, je me pose aujourd'hui la question de stocker des images sur des serveurs de fichiers ou directement en base de données en "blob" ? Ma principale question repose sur les aspects volumétriques. Notre base de données sera à terme hébergée sur des serveurs extérieurs donc l'aspect volumétrie est financièrement important. Ma question est donc de savoir si quelqu'un à une idée de la façon d'évaluer la volumétrie d'une image/document en base versus la même image/document en fichier.
De la même manière, avez vous des conseils et des bonnes pratiques quant à l'utilisation du type blob?

Bonne journée à tous.
Merci d'avance pour les réponses.

Emilie.

Yves · Mon 04 February 2019 10:19

Bonjour Émilie,

Il n'y a aucun intérêt à stocker des données rester/image dans une base de données. Cela complexifie la gestion pour un intérêt nul.

Il y n'a qu'un seul intérêt : faire des traitements sur ces données (raster) avec des données déjà en base (données vectorielles par exemple).

Y.

Nicolas Ribot · Mon 04 February 2019 10:34

Bonjour,

Je ne serais pas aussi catégorique que toi Yves:
Stocker les rasters: d'accord avec toi et je vais plus loin: postgis est juste trop lent dans le traitement raster. il vaut largement mieux le faire avec GDAL, qui sait sortir des geom de postgis directement: par ex pour calculer l'altitude moyenne de batiments dans Postgis avec un MNT chargé en raster postgis, ca a pris ~ 20 min contre qq sec avec le meme traitement par commande GDAL.

Pour des images "normales", pas des rasters, ca peut avoir son intérêt. Le stockage avec le reste des data de l'application permet d'utiliser un seul outil pour gérer sauvegardes, restaurations, etc. Et PG a de bons outils pour ca.

L'overhead de stocker dans la base est minime par rapport a des fichiers. Je vous conseille de stocker les images en type bytea et pas blob: c'est bcp plus souple et vous trouverez des exemples de code dans tous les langages pour stocker/récupérer les images.

Vous pouvez aussi faire un test rapide en stockant les images dans une table et en calculant la taille de la table (pg_relation_size, pg_total_relation_size).

Nicolas

EmilieCCBE · Mon 04 February 2019 11:31

Bonjour,

Je ne l'avais pas précisé mais il s'agirait effectivement de stocker des images de sites ou de croquis de réseau dans une optique de stockage et de sécurisation des accès (qui mettrait à l'abri du renommage/déplacement par un utilisateur).
Je vais effectivement faire un test de chargement pour évaluer la volumétrie.
N'hésitez pas à compléter ces réponses par le biais de vos expériences diverses.

Merci pour vos réponses qui viennent alimenter ma réflexion.

Belle journée.

Emilie.

tumasgiu · Mon 04 February 2019 11:34

Salut,

l'intérêt de stocker les rasters dans la base de données avec le type raster
est comme l'a dit Yves, de pouvoir les manipuler comme des données vecteurs.

C'est au prix d'une pénalité en terme de performance, comme l'indique Nicolas,
quoiqu'en bricolant un peu, on peut peut-être arriver à des choses plus satisfaisantes
,par exemple comme pour les vecteurs, subdiviser les rasters trop grand,
,changer un peu la configuration postgres, isoler les tables dans un tablespace à part
sur un disque plus performant.
C'est aussi à contrebalancer avec la nature des analyses que vous voulez effectuer,
les pénalités pouvant être acceptables.
GDAL peut charger des rasters depuis Postgres, mais, on peut lui opposer le même
argument que celui de la centralisation des données d'application: stocker les rasters
avec le type postgis permet d'avoir un seul langage de manipulation des données

Cet argument concernant la facilité de sauvegarde se tient,
mais une bonne organisation des rasters dans le FS, couplé à un script pour
effectuer sauvegarde et restauration me semble pas énormément plus complexe.
Sans compter que comme vous hébergerez tout ceci sur un serveur externe,
il est fort à parier que celui ci vous offrira sans doute un système de backup.

Je pense que le principale inconvénient à séparer raster et autre données,
est que vous perdez l'intégrité référentielle, si elle existent, entre elles,
il faut donc un peu plus de précaution dans leur manipulation

Donc, si les rasters sont destinés à de l'affichage,
je pense qu'il vaut mieux les stocker dans le FS,
cela fait moins de machinerie à maintenir.
si ils sont destinés à de l'analyse, çà se discute.

A noter que vous pouvez avoir le "meilleur" des deux mondes, en passant
par des rasters postgis out-db, qui vous permet de les laisser dans le FS,
mais de les utiliser tout de même dans postgis en vue d'un traitement.

P.S: j'ai rédigé la réponse sans voir que le dernier post.

Dernière modification par tumasgiu (Mon 04 February 2019 13:27)

Nicolas Ribot · Mon 04 February 2019 13:33

Un exemple d'insert et select sur une table contenant des images.

La table d'images:

Code:

create table testimg (
  id int primary key ,
  url text,
  img bytea
);

Fonction plpython pour telecharger une liste d'image et la stocker dans une table:

Code:

create or replace function getWebImages(img_url text[])
  RETURNS text as
$$
import psycopg2
import urllib2

# for each url, send a request and stores result in seloger.annonce_img table
i = 0
plan_insert = plpy.prepare("""insert into testimg(id, url, img)
                            values ($1, $2, $3)""",
                           ["int", "text", "bytea"])

for url in img_url:
    plpy.info("fetching image: %s" % str(url))
    try:
      # std url
      opener = urllib2.build_opener()
      opener.addheaders = [('User-Agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36')]
      filedata = opener.open(url).read()
      plpy.execute(plan_insert, [i, url, filedata])
      i = i + 1
    except Exception, e:
        plpy.warning("Error during URL retrieving %s: %s" % (url, str(e)))

return "Inserts done"

$$ language plpythonu VOLATILE;

Ex de select avec des images:

Code:

select * from getWebImages('{"https://images.pexels.com/photos/39896/space-station-moon-landing-apollo-15-james-irwin-39896.jpeg",
"https://images.pexels.com/photos/60132/pexels-photo-60132.jpeg",
"https://images.pexels.com/photos/23763/pexels-photo.jpg",
"https://images.pexels.com/photos/810890/nature-night-sky-milky-way-810890.jpeg",
"https://images.pexels.com/photos/110854/pexels-photo-110854.jpeg",
"https://images.pexels.com/photos/372101/pexels-photo-372101.jpeg",
"https://images.pexels.com/photos/262786/pexels-photo-262786.jpeg",
"https://images.pexels.com/photos/957962/night-photograph-starry-sky-night-sky-star-957962.jpeg"}'::text[]);

Script python qui fait un select sur la table des images et sauve en fichier:

Code:

import os
import sys
import psycopg2
import argparse

db_conn_str = "dbname=nicolas"

conn = psycopg2.connect(db_conn_str)
curs = conn.cursor()

sql = """select id, img from testimg"""

curs.execute(sql)
for row in curs:
    filename = "img_%s.jpg" % row[0]
    f = open(filename,'wb')
    f.write(str(row[1]))
    f.close()

print 'done'

En terme de taille: les image sur disque font 47 Mo, et en base 49 (select pg_size_pretty(pg_table_size('testimg')); )

Nicolas

EmilieCCBE · Mon 04 February 2019 13:37

Merci beaucoup pour tous ces réponses et la rapidité de leur envoi. Cela m'apporte des éléments de réflexions quoiqu'il arrive. Désolée par avance si la question est un peu idiote mais qu'entends ru par 'FP'?
Toujours preneuse d'autres retours d'expériences.
Belle journée.

Emilie.

tumasgiu · Mon 04 February 2019 13:47

Si c'est une typo et que vous demandiez ce que veux dire "FS",
c'est l'acronyme de File System, le système de fichier du disque dur
ou les données sont stockées, en d'autre termes, l'arborescence des dossiers et fichiers.

MathieuB · Mon 04 February 2019 18:08

Bonjour à tous,

Je suis hors sujet par rapport au besoin d’Émilie mais pour ma part je trouve ça très pratique de pouvoir interroger mon raster dans PostGIS pour qualifier des données d'observation avec un MNT par exemple (altitude/pente/exposition).
Ensuite selon le paramétrage du raster dans PostGIS (taille des tuiles notamment) et l'emprise concernée je trouve ça plutôt efficace : 1 minute pour l'altitude moyenne des bâtiments de Montpellier (9178 objets de la bd_topo bati_indifferencier)

Enfin, nous utilisons aussi le stockage d'images classiques en Bytea (photos prises par nos formulaires android avec ODK Collect) et ici une fonction pour écrire dans le Système de fichier une image stockée en Bytea dans la table.
https://github.com/opendatakit/aggregat … -347390280

EmilieCCBE · Thu 07 February 2019 09:45

Bonjour ,
@tumasgiu oui il s'agissait d'une faute de frappe et merci pour la réponse.
@MathieuB
personnellement je ne trouve pas ta réponse complétement hors de propos. Ma demande était assez large et s'inscrit dans une phase de réflexion quant à la pertinence d'intégrer ce type de fichier raster (ortho et mnt) et photos. Donc toute remarque est bonne à prendre. Pour être plus précise, le besoin d'intégrer des photos et documents images concerne un service eau et assainissement. Le besoin quant à l'intégration des photos est de pouvoir disposer des clichés de sites avant intervention ou à terme lors des interventions de terrain.
Cela m'intéresse donc de savoir quelles types d'images vous stockez ? Quelle 'politique' vous avez la-dessus ? J'ai peur, si j'ouvre cette possibilité, de me retrouver avec un trop grand nombre d'éléments à intégrer et une volumétrie de photos très (trop) conséquentes.

Merci pour vos réponses .

Emilie

ChristopheV · Thu 07 February 2019 14:34

Bonjour,

Le besoin quant à l'intégration des photos est de pouvoir disposer des clichés de sites avant intervention ou à terme lors des interventions de terrain.

Pour ce genre d'images je pense que la solution de Tumasgiu permettant d'avoir le meilleur des deux mondes est la plus pertinente. Cela vous permet par exemple de stocker dans la base des infos sur la photo et sur sa localisation (un type POINT par exemple). Celle de MathieuB et la fonction d'écriture est pas mal aussi.
Toute la question réside dans le volume d'images et de sa criticité en terme de sauvegarde. Pour notre part nous gérons un peu plus de deux millions d'images et là pas question de disque dur amovible ou disque système, nous avons une baie de stockage de type SAN (50 To de données), ce qui permet une sécurité et une disponibilité accrue, mais tout cela a un coût financier et un coût en technicité. Coût tel que nous envisageons maintenant de louer de l'espace et des ressources dans un DataCenter, pour pouvoir dormir tranquilles et ne pas subir l’obsolescence programmée des fabricants de baies.

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Sites amis	Agenda Biblio Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Le portail francophone de la géomatique

Annonce

#1 Mon 04 February 2019 09:55

[Postgres/postgis] Espace disque et données de type blob

#2 Mon 04 February 2019 10:19

Re: [Postgres/postgis] Espace disque et données de type blob

#3 Mon 04 February 2019 10:34

Re: [Postgres/postgis] Espace disque et données de type blob

#4 Mon 04 February 2019 11:31

Re: [Postgres/postgis] Espace disque et données de type blob

#5 Mon 04 February 2019 11:34

Re: [Postgres/postgis] Espace disque et données de type blob

#6 Mon 04 February 2019 13:33

Re: [Postgres/postgis] Espace disque et données de type blob

Code:

Code:

Code:

Code:

#7 Mon 04 February 2019 13:37

Re: [Postgres/postgis] Espace disque et données de type blob

#8 Mon 04 February 2019 13:47

Re: [Postgres/postgis] Espace disque et données de type blob

#9 Mon 04 February 2019 18:08

Re: [Postgres/postgis] Espace disque et données de type blob

#10 Thu 07 February 2019 09:45

Re: [Postgres/postgis] Espace disque et données de type blob

#11 Thu 07 February 2019 14:34

Re: [Postgres/postgis] Espace disque et données de type blob

Pied de page des forums