Discussion :

[dormilon]

Bonjour,

Je suis novice dans les SGBD, je voudrais donc savoir si une base peut encaisser entre 2000 et 5000 écritures par seconde d'un couple de valeur 2 fois 64 bits, avec lecture en parallèle?.

Les données seront envoyé en grande partie par plusieurs process (ou programmes) en local et quelques une sur un réseaux Gigabit. Et le tout fonctionnera plusieurs mois.

Si c'est faisable, quel SGBD choisir ?

merci.

[SQLpro]

les limites actuelles sont de l'ordre de 5 millions de transactions complexes par minute ce qui fait 83 333 transactions par seconde. Vous êtes entre 50 et 500 fois moins avec vos 68 bits !. Vous devrez simplement prévoir un SGBDR costaud, capable d'encaisser la charge en terme de disque, donc avec une bonne gestion des espaces de stockage comme IBM DB2, Oracle ou SQL Server.

A +

[dormilon]

Merci,

J'étais plus tôt partie sur une base embarqué comme H2 ou hsqldb.
Je suis entrain de lire la doc de H2 et pour l'instant j'ai pas vu de probleme majeur.
http://www.h2database.com/html/advan...ts_limitations

Sur quelle point je dois faire attention (autre que la taille max) ?

[Jester]

Normalement pas de problème, sauf qu'il faut noter que H2 ne fait pas d'écriture à chaque commit et donc c'est mois sécuritaire (une écriture par seconde seulement).

Cela dit avec 5000 transactions, ça me semble difficile sur du matériel classique d'avoir des commit sans write delay.

http://www.h2database.com/html/advan...ility_problems

[gregory.broissard]

ce type de SGBD ne semble pas du tout adapté à votre besoin.

SQLPro donne je pense les 3 SGBDR qui tiendront la charge sans souci, avec un niveau de support opérationnel de l'éditeur, hormis à mettre une infrastructure de disques derriere un peu serieuse, de type baie SAN.

[dormilon]

Je vais regarder IBM DB2, Oracle et SQL Server, mais je voudrais éviter les grosses installe comme sql server 2005.

[gregory.broissard]

le probleme majeur va etre l'ecriture sur disque. Vous aurez besoin de paralleliser vos écritures sur des disques distincts et à ma connaissance H2 ne propose pas de gestion de séparation des données sur différents fichiers sur différents disques.

Je veux bien que vous souhaitiez éviter les installs de produit imposant mais le choix des produits doit être tiré par votre besoin technique...

[dormilon]

Là j'ai un probleme, car je ne disposerais que d'un seul disque sata à 15000 rpm.

Il faut qu'on adapte le matériel ou qu'on diminue le nombre d'écriture par seconde. Avec un disque sata 15000 rpm combien d'écriture max une base peut gérer (en moyen)?

[gregory.broissard]

une fois encore le besoin doit tirer la solution d'architecture et pas le contraire.

Cependant si la solution technique est imposée alors il faut faire rentrer aux forceps le besoin dans la solution.... Mais il vaut mieux privilégier la premiere solution

en plus comment assurez vous le fonctionnement de la base si votre unique disque crashe?

[SQLpro]

Je vais regarder IBM DB2, Oracle et SQL Server, mais je voudrais éviter les grosses installe comme sql server 2005.

En matière d'installation les plus lourdes et les plus complexes sont IBM DB2, suivi d'Oracle, et finalement SQL Server qui est la plus simple à installer. En matière de lourdeur, tout dépend des modules que vous y mettez, mais SQL Server reste d'un poids raisonnable si vous ne mettez pas les outils client, SSAS, SSIS, SSRS, les BOL, etc....

Là j'ai un probleme, car je ne disposerais que d'un seul disque sata à 15000 rpm.

Ne révez pas, c'est votre architecture qui doit s'adapter et non trouver l'outil que vous allez mettre au bout. Si vous voulez faire atterrir un 747 la piste doit être en conséquence et non celle d'un aéroclub !

En particulier vous devez impérativement multiplexer le journal des transactions sur au moins 2 disques, soit 4 avec la redondance (R10) par exemple. Pour vous données il faut faire un test, mais il faudra au moins un disque séparé + redondance RAID. Il ne faut pas que les fichiers de données et journaux soient situés sur les mêmes axes physiques....
Revoyez complétement votre stratégie ! Parce que là, clairement, vous allez au mur !!!

Il faut qu'on adapte le matériel ou qu'on diminue le nombre d'écriture par seconde. Avec un disque sata 15000 rpm combien d'écriture max une base peut gérer (en moyen)?

Il n'est jamais recommandé avec un SGBDR d'utiliser un seul disque. Soit vous adapté votre architecture, soit vous devez envisager autre chose.

A +

[dormilon]

en plus comment assurez vous le fonctionnement de la base si votre unique disque crashe?

Le système actuel tourne avec un RAID1.

En particulier vous devez impérativement multiplexer le journal des transactions sur au moins 2 disques, soit 4 avec la redondance (R10) par exemple. Pour vous données il faut faire un test, mais il faudra au moins un disque séparé + redondance RAID. Il ne faut pas que les fichiers de données et journaux soient situés sur les mêmes axes physiques....
Revoyez complétement votre stratégie ! Parce que là, clairement, vous allez au mur !!!

Je vas certainement allez droit dans le mur (en béton armé ) car je ne peux modifier le matérielle.

Soit vous adapté votre architecture, soit vous devez envisager autre chose.

comme quoi?

[Bowen]

Si j'ai bien tout compris, le poste servira en plus à faire tourner les programmes qui alimenteront la base, donc consommeront de la ressource.
Ce qui réduit encore la puissance disponible pour le SGBD.

J'ai une question de curiosité, peut-être hors sujet mais qui pourrait remettre en cause les chiffres initiaux : Qu'est-ce que ces programmes sont sensés écrire ? Et qu'est-ce qui vous fait penser que le rythme sera de 2000 à 5000 écritures secondes ?