Discussion :

[fgalves]

Bonjour,

Je travaille sur un projet dans le domaine spatial, dans lequel la problématique principale est la forte volumétrie des données (après estimation, la base de données pourra arriver à atteindre 1 petaoctet!).

Même si le choix d'Oracle pourrait paraître le plus pertinent, il y a l'inconvénient des prix des licences complètement abusifs.
Il faut donc étudier la faisabilité d'utiliser un SGBD Open-Source comme PostgreSQL ou MySQL. L'option "partitioning" et une gestion optimisée des BLOBs semblent nécessaires.

Quel est votre avis là-dessus? Connaissez-vous des VLDB (Very Large Data Bases) dans le marché qui soient gérées avec PostgreSQL ou MySQL?

Merci pour votre rétour d'expérience,
Cordialement,
Fgalves

[al1_24]

Il me semble que GreenPlum est architecturé autour de moteurs PostgreSQL et annonce des couts de licence moindres qu'Oracle.
Toutefois, arrivé à ce niveau de volume de données, c'est surtout le cout du matériel qui est à prendre en compte, plus que celui des licences

[SQLpro]

Compte tenu de la faiblesse de la gestion des espaces de stockage de ces deux SGBDR libres, je préconiserait de ne surtout pas les utiliser pour une telle volumétrie....

Reste les choix suivants que l'on trouve pour les VLDB : Oracle, IBM DB2 et MS SQL Server (pour l'OLTP) et Teradata pour les OLAP.

A +

[Jester]

C'est clair que MySQL sera dans les choux, il y a néanmoins des travaux dans le domaine astronomique. Peut-être utiliser un moteur spécial pour le stockage des blob. Ça ne résoudra pas le problème que c'est trop gros néanmoins je pense.

La seule solution je pense, c'est de faire du sharding. Avec toute la complexité qui va avec.

[fgalves]

Merci à tous pour les réponses!

SQLpro, pour mieux comprendre la problématique de la gestion des espaces de stockage, aurais-tu en tête un article pouvant m'éclaircir sur ce sujet?

Jester, existe-t-il l'équivalent du sharding pour PostgreSQL?

Merci par avance,
Cdt,
Fgalves

[Jester]

Je pensais au niveau applicatif (d'où énormément de complexité). Après il existe des outils et fonctionnalité qui peuvent aider, mais ça demande de bien réfléchir et ça ne sortira jamais la solution directement.

[al1_24]

Compte tenu de la faiblesse de la gestion des espaces de stockage de ces deux SGBDR libres, je préconiserait de ne surtout pas les utiliser pour une telle volumétrie....

eBay utilise une base GreenPlum de 6.5 Po (96 noeuds PostgreSQL), apparemment sans gros problème

[SQLpro]

Oui, mais :
1) l'info est découplée et la plupart des données sont des archives
2) comme beaucoup de site web, c'est 98% de lecture pour 2% de MAJ...

A +

[SQLpro]

SQLpro, pour mieux comprendre la problématique de la gestion des espaces de stockage, aurais-tu en tête un article pouvant m'éclaircir sur ce sujet?

Dans mon blog :
http://blog.developpez.com/sqlpro/p5...fichiers-et-t/

A +

[Jester]

Sur le greenplum de eBay

Metrics on eBay’s Greenplum data warehouse (or, if you like, data mart) include:

* 6 1/2 petabytes of user data
* 17 trillion records
* 150 billion new records/day, which seems to suggest an ingest rate well over 50 terabytes/day
* 96 nodes
* 200 MB/node/sec of I/O (that’s the order of magnitude difference that triggered my post on disk drives)
* 4.5 petabytes of storage
* 70% compression
* A small number of concurrent users

http://www.dbms2.com/2009/04/30/ebay...ta-warehouses/

InnoDB permet me semble de faire des tablespace de taille prévue comme l'indique votre article. Pas sur que ça apporte à MySQL par contre. Reste que la gestion des tablespace est très embryonnaire.