Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
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. 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 (sans modifications du moteur)?
Sinon, savez vous si dans les 3 ans à venir, PostgreSQL supportera des très fortes volumétries? En effet, notre base de données n'atteindra le petaoctet qu'après 3 ans d'exploitation.
Merci pour votre rétour d'expérience,
Cordialement,
Fgalves
Hors ligne
En France, il y a déjà Météo France avec une base de plusieurs Téra octets: http://www.postgresqlfr.org/temoignages:meteo_france
il y a aussi le moteur de recherche de Orange qui est voila.fr mais qui n'est pas dans le domaine du peta octets
Hors ligne
Yahoo stocke plusieurs peta-octets dans un SGBD dérivé (fork) de Postgres :
http://glinden.blogspot.com/2008/05/yah … resql.html
D'autres systèmes de datawarehouse sont basés sur postgres ( netezza, greenplum )
Je ne connais pas d'exemples de bases PostgreSQL "non modifiées" hébergeant plusieurs Petas. Il me sembla qu'arrivé à ce niveau-là, le problème essentiel est l'infrastructure de stockage.
Quoiqu'il en soit , si pour le moment vous avez "simplement" quelques Teras de données , démarrer avec PostgreSQL est un bon choix. Si jamais vous atteignez les limite de PG d'ici 3 ans, vous pourrez facilement migrer vers des entrepots de données basés sur Postgres.
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Merci pour les réponses.
J'étais déjà au courant de Yahoo et son fork. Par contre, je cherche à trouver des exemples dans le marché sans modification du moteur de PG (s'ils existent). En plus, à ma connaissance Yahoo n'a pas autorisé sa commercialisation.
Voici un récapitulatif de notre problématique:
Il s'agit de traiter 1 milliards d'entités stockées dans une base. Pour chaque entité, on estime le volume de données associées à une source de 15 ko (en début de vie) à 150 ko (en fin de mission).
La base se complètera au cours du projet pour démarrer à 20To en 2012 et finir au bout de 7 ans avec 200To de données utiles (soit une estimation à 1Po de données en comptant les sauvegardes & Cie).
Nous sommes inquiets pour la base de données:
- Sur quelle technologie misée pour la mise en place d'une base de données d'un milliard d'entités ? Pour le moment les pistes pour la mise en place de la base seraient : Oracle (très chère, et liée avec Exadata d'HP), ou Postgre mais incapable pour le moment de gérer 1 milliard d'entités.
Merci pour votre rétour d'expérience,
Cordialement,
Fgalves
Dernière modification par fgalves (17/09/2009 13:30:31)
Hors ligne
Tout dépend de votre applicatif. Un serveur PostgreSQL actuel ne pourra certainement pas gérer autant d'informations. Par contre, un ensemble de serveurs pourrait en être capable. À mon avis, le problème ne se trouve pas au niveau de la base de données, mais au niveau de votre applicatif. Au lieu de tout stocker dans une seule et même base de données (ce qui me paraît illusoire quelque soit le moteur de base de données), il vaudrait mieux mettre les données sur plusieurs (lire « un grand nombre de ») serveurs et utiliser des outils comme dblink ou plproxy pour accéder à tout à partir d'une seule base. Ce que fait Skype avec PL/proxy d'ailleurs. Cet article (http://highscalability.com/skype-plans- … lion-users) peut vous intéresser (si vous ne l'avez pas déjà lu).
Guillaume.
Hors ligne
Et pour un supplément d'info, le développeur du Log Shipping, du Warm Standby (bref, Simon Riggs pour ne pas le nommer) prévoit de travailler sur des fonctionnalités VLDB depuis un/deux ans maintenant. Mais il est trop occupé sur le Hot Standby pour l'instant.
Guillaume.
Hors ligne
Ouais une optimisation pour les star query ça serait déjà un bon début. Avec les index bitmaps qui se laissent désirer depuis un moment 
De toutes façons pour revenir à la problématique initiale, une très grosse base de ce type, c'est plutôt à attaquer sur plusieurs bases en parallèle. Avec un grid SQL par exemple…
Marc.
Hors ligne
Pages : 1
