Discussion :

[Esil2008]

Bonjour,

En l'absence de compétence en BD dans mon équipe, j'appelle à votre expérience.

Je suis désolé de vous poser une question qui a était surement posée plusieurs fois. J'ai lu le document sur les comparatif qui est très bien, mais je voudrais bien avoir votre avis dans mon cas spécial

On est en phase d'étude sur un projet important. On voudrait pouvoir stocker des informations pour une durée de cinq ans, le nombre d'enregistrement qui sera présent dans notre base variera de quelques millions à plusieurs milliards d'enregistrements.

Pour résumer notre besoin, ci dessous quelques points très important qu'on doit tenir en compte :
- Supporter de grosse base de données (plusieurs milliards d'enregistrements )
- Permet d'avoir de bonne performance en écriture
- Performance en lecture devra être très bonne (la lecture ne devra pas dépasser qlq secondes même avec 1 milliard d'enregistrement derrière )
- Évolue sur Unix, Linux ou Windows
- Une administration facile, on dispose pas d'un DBA (et on disposera pas malheuresement)
- Le nombre de connexion nous importe peu (on doit disposer d'une BD par client)
- La base de données sera hébergé en interne, sur des serveurs assez costaud, Serveur Solaris SunOS 10, 2 x 3.2GHz Intel Xeon X5482 => 8 cores, 32GO de RAM et HDD: 2*250Go (no RAID)
- La base de données sera utilisée via une grosse application web, qui permettra à chaque client d'avoir sa propre base de données. (on pourra avoir une vingtaine de BD a plusieurs milliards d'enregistrements chacune)
- Pour finir des fonctionnalités basiques, on étant rapide et robuste même avec de très gros volume de données.

D'après votre expérience personnelle et professionnelle qu'elle SGBD serait le mieux adapter dans notre cas.
Pour les SGBD payant pourriez vous m'indiquer le prix approximatif de la licence.

Merci infiniment

[Waldar]

Des milliards d'enregistrements sans DBA, avec des performances de premier ordre ?

Ca me paraît relativement improbable.

[Esil2008]

Donc a votre avis, il faudra à tout prix recruter un DBA pour cela.

Le seul soucis, c'est que ca sera la seule tache du DBA. C'est pas trop rentable pour la société je pense. En tous cas ca sera difficile de le justifie.

Sinon pour la base à choisir ?

[Waldar]

Honnêtement avec des personnes compétentes je pense que vous trouverez des solutions avec la plupart des SGBD dont on parle sur ce forum - j'exclue SQL Server si vous êtes en Unix : Oracle, MySQL, PostGreSQL, sûrement d'autres je ne les connais pas tous.

Pour le DBA, vous pouvez demander à une SSII une mission de type deux jours par semaine, ajustable selon les incidents, enfin c'est un poste qui me paraît vraiment indispensable, au même dire que des personnes qui vérifient que vos serveurs ne tombent pas, qui tiennent l'anti-virus à jour, et toutes les tâches quotidiennes d'exploitation !

[Esil2008]

Merci pour votre réponse,

C'est justement sur 4 SGBD qu'on arrive pas encore à décider à savoir : Oracle, Postgres, SyBase ou bien MySQL

Il faudra faire une étude plus approfondie, je compte dailleurs sur vos retours pour m'aider à faire un document motivant mon choix

Merci

[Jester]

Quel sera la taille d'une ligne? Qui va faire les index?

[Esil2008]

C'est exactement la question que je me posais en ce moment combien fait une ligne ???

au fait, une table type contiendra au moins 15 colonnes, la plupart des colonnes sont des VARCHAR(100) + deux colonnes DATE

A votre avis qu'elle taille fera une ligne avec les précisions ci dessus ?

Pour les indexes, c'est des développeurs qui le feront. L'utilisateur doit pouvoir chercher par l'ensemble des colonnes de la table.

Merci bq

[Jester]

Bah 13 colonnes qui peuvent prendre 100 octets chacun, ça nous fait sur 1 milliards de lignes 1.3To, soit plus que votre stockage.

Vous n'avez plus qu'à demander des requêtes du genre where colonne like '%truc%'.

J'administre rarement des tables de plus de 10Go, j'utilise rarement des tables de plus de 100Go donc je ne saurais dire pour 1To.

[Esil2008]

mettons que mes tables font dans les 100Go qu'est ce que vous utilisez pour ça ? qu'est ce que vous conseillez ?

[Jester]

C'est sur du Oracle. Ca marche pas trop mal vu la charge et la structure, mais faut rester sur des requêtes simples et indexées.

Je ne sais pas si c'est dur à administrer.

[gregory.broissard]

Espérer faire fonctionner une grosse base de données de manière optimale sans DBA c'est de l'utopie. Une base de données ca évolue au cours du temps et ca demande donc de l'entretien, sur n'importe quel SGBD.

cette considération faite, je dirai qu'il faut essayer d'etre pragmatique par rapport à l'approche du probleme.
Si vous utilisez dejà Oracle ou DB2 ou Sybase ou un autre gros SGBD dans votre société alors orientez vous vers celui ci.

Si vous souhaitez avoir de bonnes perfs en lecture / ecriture et au vue du volume annoncé, un petit investissement en baie SAN serait intéressant et sécurisante.

concernant le choix du SGBD, au moins sur DB2, Oracle et Sybase ( plus SQLserver mais hors contexte puisque uniquement Windows), il est courant de voir des bases OLTP de plusieurs To donc je suis pas inquiet pour ceux là.

Meme si je connais MySQL et PostGre, je n'ai jamais vu tourner dans mon xp pro personnelle de bases de plusieurs To sur ces SGBD , je laisse donc ceux qui ont une expérience répondre.

[Esil2008]

Merci bq pour vos retours, ca va vraiment m'aider pour justifier nos choix techniques.

Je suis tout a fait daccord avec vous que plusieurs tables de plusieurs To ne peuvent être géré efficassement que par des spécialistes. Moi je vous ai exposer la situation actuelle, que j'espère qu'elle pourra changer. Ca nous déchargera de pas mal de casse tête

Donc on peut affirmer qu'une base de données de type ORACLE/SYBASE/DB2 (ou bien SQL SERVER) nécessitera la présence d'un DBA

Merci

[Esil2008]

Quelqu'un pourrait me donner des benchmarks sur des bases oracle/sybase avec des téraoctets de données ?

[SQLpro]

A partir du moment ou l'on commence à rentrer dans les grosses bases (plus de 100 Go) ou les très grosses (plus de 1 To), il convient de faire très attention au stockage et en particulier :

• du niveau de RAID du sous système disque (le RAID 5/6 étant à éviter dans votre cas)
• du calage des unités logique sur des disques physique si vous prenez un SAN
• de la possibilité de partitionnement des tables et des index
• de la possibilité de créer des vues indexées (ou matérialisées).
• de la capacité à structurer les espaces de stockage
• et enfin des possibilité d'administration fine (défragmentation, vérification d'intégrité, sauvegardes partielles...)

Ceci exclut PosGtreSQL.
Reste donc Oracle, DB2 et Sybase ASE.

Je vous conseille fortement de faire faire une étude d'avant production pour le choix du serveur tant logique (le SGBDR) que physique (la machine).

A +

[kedare]

Le truc c'est que quand la base de données devient vraiment très grosse, on doit commencer a utiliser de la réplication, du sharding, ou autre techniques de disponibilité et de répartition des charges, qui sont souvent complexe a mettre en œuvre, donc sans DBA ca me parais impossible....

A partir du moment ou l'on commence à rentrer dans les grosses bases (plus de 100 Go) ou les très grosses (plus de 1 To), il convient de faire très attention au stockage et en particulier :

* du niveau de RAID du sous système disque (le RAID 5/6 étant à éviter dans votre cas)
* du calage des unités logique sur des disques physique si vous prenez un SAN
* de la possibilité de partitionnement des tables et des index
* de la possibilité de créer des vues indexées (ou matérialisées).
* de la capacité à structurer les espaces de stockage
* et enfin des possibilité d'administration fine (défragmentation, vérification d'intégrité, sauvegardes partielles...)

Ceci exclut PosGtreSQL.
Reste donc Oracle, DB2 et Sybase ASE.

Pourtant Mysql ou Postgresql conviendrais très bien je pense, Yahoo a bien une base postgresql de plus de 2Po (2.000.000Go), et Facebook ou Dailymotion tournent sous Mysql
Personnellement je recommanderais plutôt Mysql grâce a son vrais système de partitionnement (intéressant pour les performances), et a Mysql Cluster (ou tout simplement la réplication master/slave), on a rarement besoin des fonctions spécifiques que fourni Postgresql....

[Oishiiii]

Le truc c'est que quand la base de données devient vraiment très grosse, on doit commencer a utiliser de la réplication, du sharding, ou autre techniques de disponibilité et de répartition des charges, qui sont souvent complexe a mettre en œuvre, donc sans DBA ca me parais impossible....

Pourtant Mysql ou Postgresql conviendrais très bien je pense, Yahoo a bien une base postgresql de plus de 2Po (2.000.000Go), et Facebook ou Dailymotion tournent sous Mysql
Personnellement je recommanderais plutôt Mysql grâce a son vrais système de partitionnement (intéressant pour les performances), et a Mysql Cluster (ou tout simplement la réplication master/slave), on a rarement besoin des fonctions spécifiques que fourni Postgresql....

Les solutions telles que le sharding, le partitionnement, IMHO s'appliquent à des cas extrêmes (Facebook, Flickr, Digg, etc...), des petabytes de données avec un nombre important de transactions par secondes (plus de 5000 TPS pour FB il me semble avoir lu).

Il est préférable de booster au maximum son SGBDR classique si c'est possibe.. (le z10 d'IBM peux monter jusqu'à 1,5To de RAM par exemple).

Tomber dans le sharding c'est dénormaliser, avoir d'énorme difficulté pour effectuer des jointures ou maintenir de l'intégrité réfferentielle entre plusieurs serveurs, difficulté à modifier le schéma de la BDD, sans compter la maintenance, etc..

Mis à par certaines exceptions pour lesquelles il n'est pas encore physiquement possible d'utiliser un SGBDR classique (Facebook, etc..) est-ce que cela vaut vraiment le coup ?