Geovisio et stockage

Suite à la réunion d’hier soir, voici quelques éléments techniques à propos du stockage actuel et son extension à court terme à TH3:

  • osm32: 6 disques de 3To utilisés pour le stockage du takeout Mapillary donc 18To, soit 15To utilisables (1 disque de redondance) et un peu plus de 12To occupés, reste 2 à 3To de libre
  • osm33 à osm36: 6 baies 2.5" pour chaque lame, toutes libres, donc on peut mettre 6x4 ou 5To, avec 1 disque de redondance ça fait 20 à 25To possibles, un disque 5To coût entre 120 et 140€, donc dans les 720-840€.

Il est aussi envisageable d’upgrader les disques d’osm32 pour le plus gros disques, mais la manip doit se faire disque par disque, avec plusieurs heures/jours entre chaque (donc 6 aller-retour à TH3).

Mettre en place un second serveur de stockage est aussi une possibilité, peut être plus pérenne, surtout si à terme on veut permettre le stockage de nouvelles prises de vues.
Ce n’est bien sûr pas le même coût (compter 1500 à 2000€ pour un rack de 60 baies 3.5" comme le MD3260 de Dell + le coût des disques d’environ 15€/To + dans les 70 kWh/an d’électricité par HDD).

Rappel:

  • actuellement geovisio prépare en avance un tuilage des photos, tuilage qui nécessite 150% de stockage supplémentaire par rapport au stockage des photos brutes
  • on a 12To de photos, il faut donc 18To en plus pour permettre leur consultation par la version actuelle de geovisio (des optimisations sont à étudier, car ça ne me semble pas scalable)

Ah oui, pour mémoire… le stockage dans le « cloud » (l’ordinateur de quelqu’un d’autre)

Exemple de coût chez Scaleway:

  • stockage: 10€/To/mois, 120€/an (prévisible)
  • trafic: 0.01€/Go… et imprévisible

Tarifs similaires chez OVH.

Notre takeout stocké dans le cloud nous aurait coûté 1440€/an.

Avec par exemple un rythme de 64To de plus par an, au bout de 5 ans le stockage cloud couterait dans les 100 k€ (cumulés), et en on-premise on serait à 14,5 k€ (le double si on veut un backup complet)… et je ne compte pas le trafic cloud à ajouter.

Bonjour,

Merci @cquest pour ce récap’ de ce qui est déjà stocké sur les serveurs OSMFR et les contraintes.

Côté Geovisio, le choix du précalcul des versions dérivées des photos était lié au besoin initial de Géovélo, à savoir un volume raisonnable de photos (quelques centaines de Go au plus), et un stockage cloud avec peu de performance en lecture/écriture (donc calcul à la volée pas tenable).

Dans le cas OSMFR, le stockage étant local et/ou sur le même réseau local, le précalcul se justifie moins, on devrait avoir une performance correcte avec un premier calcul à la volée (lors de la 1ère requête) puis mise en cache. À tester quand même voir si ce n’est pas à conditionner en fonction de la résolution de l’image initiale, le besoin de flouter, les ressources machines…

Hormis ce précalcul à éviter, est-ce qu’il y a d’autres idées à creuser pour limiter le stockage autant que possible ?

Je ne connais pas le mode de fonctionnement de la visionneuse mais j’imagine deux pistes:

  • faire faire un max de choses sur le client me parait souhaitable pour que ce soit scalable côté serveur (webgl)
  • sur des images vraiment volumineuses, un stockage au format COG pourrait permettre de réduire le volume à transmettre

Sûr que le dimensionnement initial pour quelques Go d’images coincera quand on envisage plutôt des To voire Po (et ce qu’il y a entre les deux).

Pour le stockage je pense aussi qu’il faut creuser le COG et le webp (quitte à faire une conversion à la volé si le client ne le supporte pas (5% du web)).

Pour les photo d’origine, ce que j’évoquais hier, était ce type d’offre : Amazon Glacier — Wikipédia

Si on arrive à éviter le précalcul pour les images non-floutés, est-ce qu’on pourrait estimer la taille nécessaire, vu qu’il nous faudra toujours générer les miniatures ?

À mon avis, l’approche d’ajouter des disques de quelques To sur osm34 me semble le mieux à moyen-terme. Pour le moment, on peut continuer les tests avec le SSD déjà présent, qui a ~1 To de disponible.

1 Like

Tarification incompréhensible…

Au mieux le stockage est à 0.05$/Go/mois, soit 2 fois moins qu’OVH/Scaleway, mais il y a plein de coût annexes difficiles à évaluer.

Donc au mieux, on passe à 50k$ au lieu de 100k€… toujours bien plus cher que du fait maison.

L’équivalent de Amazon Glacier chez Scaleway coûte ~€0.002/Go/mois (Tarifs | Scaleway), soit 2€/To/mois.

Si je reprends les calculs de @cquest, ça reviendrai au même prix que le « on-premise », du moins si utilisé uniquement pour les backups. Du coup, pas sur de l’intérêt pour nous, du moins pour le moment.

Oui, mais le « glacier » n’est pas du tout fait pour qu’on accède à la demande au contenu… c’est orienté sauvegarde.

Pour des sauvegardes de trucs qui n’évoluent pas (notre cas)… je ne connais rien de moins cher que des disques durs rangés dans une armoire !

Au pire c’est 30€/To en one-shot et rien par mois… ou années.

Descendons du cloud, revenons sur terre :wink:

Si on arrive à éviter le précalcul pour les images non-floutés,

@_PanierAvide c’est envisageable de ne stocker que le masque de floutage et pas une copie floutée ? Une image 2bits, voir même en résolution plus faible, ça doit peser quasiment rien.

Normalement oui, de souvenir ça avait implémenté comme ça pour faire du benchmark visuel sur les différents algos de floutage.

N’oubliez pas le problème de la bande passante. Si les images sont tuilées, c’est en partie pour éviter de transférer au client l’intégralité d’une image de plusieurs MB, mais seulement les parties qui sont visualisées, et avec une qualité adaptée au niveau de zoom. C’est le même principe que pour les images aériennes.

D’où la suggestion du format COG… qui permet de ne récupérer que la partie utile de l’image (possible y compris en multi résolution).

Voir… https://geotiffjs.github.io/

1 Like

J’ai ouvert un ticket pour gérer l’implémentation technique dans Geovisio (et essayer de décortiquer le problème) : Change processing behaviour to only generate derivates on-demand (#13) · Issues · Adrien Pavie / GeoVisio · GitLab

Si certains d’entre vous sont motivés pour mettre les mains dans le cambouis… :wink:

D’après toi, qu’est-ce qu’on peut attendre comme gain, à la louche, en passant de tuiles jpg multirésolution, à du COG ?

A minima on élimine la copie à pleine résolution (si j’ai bien compris les dessous de géovisio).

On passerait potentiellement de +150% à +50% et théoriquement on devrait plutôt être à +33% pour les résolutions 1:2 1:4 1:8 1:16… le tout dans un unique fichier (plus facile à manipuler, une seule URL).

Autre piste, webp au lieu de jpg… taille divisée grosso-modo par deux pour la même qualité visuelle.

La partie la moins scalable c’est le stockage et les calculs côté serveur, c’est donc ça qu’il faut optimiser au maximum.

Hmm, je crois qu’on mélange plusieurs sujets. @_PanierAvide tu me corrigeras si je dis des bêtises.

On a la photo originale, disons 10MB.
Celle-ci est traitée pour être floutée (+10MB) et est ensuite découpée en tuiles sur plusieurs niveaux de zoom en fonction de la taille en pixel de l’image originale(+4MB). S’ajoute quelques miniatures pour accélérer l’affichage(+1MB), ce qui transforme les 10MB de la photo floutée en environ 15BM.

Si on ne conservait pas la photo originale, comme le fait maintenant Mapillary, on ne serait pas à +150% d’espace nécessaire, mais 50%.

Donc, Webp, Cog, pourquoi pas si on arrive à rendre la visionneuse compatible avec ces formats, mais pour le moment c’est la conservation de la photo originale qui « coûte » le plus.

1 Like

@StephaneP c’est exactement ça

L’image fullres n’est pas elle même tuilée ? J’imagine que oui et on va quand même garder une version non tuilée pour les usages hors visionneuse parce que les photos ne serviront pas qu’à la visionneuse.

Le floutage c’est un sujet annexe, qui oui, peut faire qu’on conserve l’original + la version floutée et donc potentiellement avoir +100% rien que pour ça.

(j’ai exactement les mêmes cogitations côté Open Food Facts entre les photos telles que reçues, les retraitements basiques, les crop, les preview… et les problèmes de stockages associés)

Piste COG/webp à creuser très sérieusement !

Sur des photos 12MPixels (Gopro) un gdal_translate en COG/webp en qualité par défaut à 75 et AVEC overviews donne:

  • 6.5Mo → 1.3Mo (-80%)
  • 5.7Mo → 1.1Mo
  • 3.4Mo → 343Ko (-90%)

On se retrouve avec un fichier unique sur disque, tuilé en interne (blocksize par défaut de 512 pixels), multi-résolution et au transfert réseau limité aux tuiles/résolution utiles.

La lib javascript partagée un peu plus haut permet de gérer ce format nativement dans le client.

Côté serveur, un nginx ou apache de base sert le COG sans rien faire (le client utilise les byte-range HTTP pour ne charger que le nécessaire).

Qui dit mieux ?