Firebird VS Postgresql, quels arguments?

[onet]

Hello,

Éternel débat, souvent soumis aux lois du trolling, je le sais... Néanmoins, je suis dans un cas bien épineux...

On est en plein développement d'une application qui sera embarquée dans une machine d'immuno-hematologie. Pour celle-ci, nous avons besoin d'une base de données. Cette base tournera sur un ATOM N510 (dual core => 4 vrai thread, 1,66Ghz) avec 1Go de RAM, sur disque Sata. Le tout fonctionnant sous Debian Squeeze. Mais cette machine sert aussi à faire de l'analyse d'image bas niveau. Voila pour le côté performances.

Coté schéma DB, on a une base avec environ une 60aine de tables, avec des clés secondaires et donc relationnelle. Ainsi que des procédures stockées assez importantes, des triggers, etc... Bref, toute la panoplie du parfait petit chimiste en DB.

Pour attaquer cette base de données, 2 logiciels principaux. L'un en .NET, qui gère tout ce qui est gestion de patient, récupération de données, analyse, etc... Et le second en C++ qui gère toute la partie résultat, etc... Et le problème arrive... 2 teams différents s'occupent des développements.

Le team A, qui s'occupe du logiciel en .NET, ne jure que par Firebird.
Le team B (dont je fais partie) qui s'occupe de l'administration du serveur et du dev en C++ veut du postgreSql.

Je dois donc maintenant faire un comparatif des 2 SGBD afin de trancher sur lequel est le plus adapté... Et je sèche... Auriez-vous des pistes ou des expériences à me fournir sur des comparatifs entre les 2 ?

Quelques infos en vrac:
- le team A pense que parce que Firebird stocke l'intégralité des données dans 1 seul fichier, c'est le must du must (corruption, etc...)
- il faut prévoir plusieurs milliers/millions de données... Je dirais dans les 1-2 Go de données/années, à vue de nez
- Une très haute sécurité est nécessaire, tant en terme de corruption, stabilité, fiabilité, etc...
- J'ai un backup sous la forme d'un dump effectué à intervalles très réguliers (1-5min).

Merci de vos retours (et désolé pour le pavé!).

Onet

[SQLpro]

Bonjour,

Envoyé par onet

Hello,

Éternel débat, souvent soumis aux lois du trolling, je le sais... Néanmoins, je suis dans un cas bien épineux...

On est en plein développement d'une application qui sera embarquée dans une machine d'immuno-hematologie. Pour celle-ci, nous avons besoin d'une base de données. Cette base tournera sur un ATOM N510 (dual core => 4 vrai thread, 1,66Ghz) avec 1Go de RAM, sur disque Sata. Le tout fonctionnant sous Debian Squeeze. Mais cette machine sert aussi à faire de l'analyse d'image bas niveau. Voila pour le côté performances.

Vous faites les choses complétement à l'envers et êtes donc en dehors de la plaque !!!!

En effet on ne commence pas par définir une machine, encore moins l'OS alors que l'on ne sait pas encore :
1) quel SGBDR choisir
2) quelle est la volumétrie des données.
Par exemple avec une RAM de 1 GO ce sera catastrophique quelque soit le SGBDR !!!!

C'est comme si vous disiez : je veut faire une balade sur des sentiers de montage... Je dois prendre des patins à glace !!!!

D'autant plus que vous voulez des performances !!! On rêve..........

Coté schéma DB, on a une base avec environ une 60aine de tables, avec des clés secondaires et donc relationnelle. Ainsi que des procédures stockées assez importantes, des triggers, etc... Bref, toute la panoplie du parfait petit chimiste en DB.

Pour attaquer cette base de données, 2 logiciels principaux. L'un en .NET, qui gère tout ce qui est gestion de patient, récupération de données, analyse, etc... Et le second en C++ qui gère toute la partie résultat, etc... Et le problème arrive... 2 teams différents s'occupent des développements.

Le team A, qui s'occupe du logiciel en .NET, ne jure que par Firebird.
Le team B (dont je fais partie) qui s'occupe de l'administration du serveur et du dev en C++ veut du postgreSql.

Pour avoir eu certains clients avec du FireBird, la comparaison est immédiate : du fait de son mode transactionnel et donc du verrouillage qui en résulte, FireBird est incapable de monter correctement en charge avec une forte concurrence. Par exemple à plus de 10 requêtes simultanées, c'est la cata !
De nombreux éditeurs ont été confrontés à cela et sont généralement passé à SQL Server (plus qu'à PostGreSQL... question de responsabilité, même si PG reste un bon choix dans votre cas...).

En sus il y a très peu de ressources sur FB (site web, informaticiens compétents...) et beaucoup plus sur PG.
En d'autres termes, hélas pour FB, c'est sur la pente finale !!!! (j'ai pourtant été un ardent défenseur de Borland....)

Je dois donc maintenant faire un comparatif des 2 SGBD afin de trancher sur lequel est le plus adapté... Et je sèche... Auriez-vous des pistes ou des expériences à me fournir sur des comparatifs entre les 2 ?

Quelques infos en vrac:
- le team A pense que parce que Firebird stocke l'intégralité des données dans 1 seul fichier, c'est le must du must (corruption, etc...)
- il faut prévoir plusieurs milliers/millions de données... Je dirais dans les 1-2 Go de données/années, à vue de nez

ça c'est du pipi de chat.
Petites bases : tient dans la RAM d'un serveur => moins de 30 Go
Moyenne bases : tiennent sur un seul disque de serveur : => moins de 150 Go
Grosses bases : moins de 1 To
Très grosses bases : plus de 1 To

Il ne sert STRICTEMENT A rien de découper une base en plusieurs fichiers si c'est pour les mettre sur un seul disque. Au contraire les performances chuterons !

- Une très haute sécurité est nécessaire, tant en terme de corruption, stabilité, fiabilité, etc...

Dans ce cas il faut mettre en œuvre des dispositifs de haute dispos, et malheureusement ni FB ni PG ne savent faire ceci actuellement.
Moi je m'orienterais donc vers SQL Server, voire même en version gratuite dans une premier temps (limite des bases : 10 Go).
Pour la haute dispos voir : http://sqlpro.developpez.com/cours/s...disponibilite/

- J'ai un backup sous la forme d'un dump effectué à intervalles très réguliers (1-5min).

Backup et dump sont deux choses différentes :
http://blog.developpez.com/sqlpro/p7...-et-log-ne-so/

Merci de vos retours (et désolé pour le pavé!).

Onet

Je pense qu'il est avant tout nécessaire que vous vous formiez à ce qu'est un SGBDR avant tout, sinon, vous courrez à la catastrophe, et moi je gagne un client potentiel !
Lisez cet article que j'ai fait paraître il y a quelques années :
http://img1.lemondeinformatique.fr/f...s-epaisses.pdf

A +

[onet]

hello,

Oula, je crois qu'il faut remettre l'église au milieu du village... Quelques précisions sont nécessaire...

Envoyé par SQLpro

Bonjour,


Vous faites les choses complétement à l'envers et êtes donc en dehors de la plaque !!!!

On dt a coté de la plaque... Et je n'aime pas le ton de cette réplique, sans avoir eu plus d'information...

Envoyé par SQLpro

En effet on ne commence pas par définir une machine, encore moins l'OS alors que l'on ne sait pas encore :
1) quel SGBDR choisir
2) quelle est la volumétrie des données.
Par exemple avec une RAM de 1 GO ce sera catastrophique quelque soit le SGBDR !!!!

On se trouve dans un environnement embarqué, en milieu industriel, avec des budgets, et des objectifs. Il se trouve que:
- l'intégralité du développement se fait en C/C++ sous Debian Squeeze (Choix effectué il y a plusieurs mois, après analyse des besoins)
- La volumétrie des données est connue, pour le pire des cas, et est largement supportée par la SGBD que j'ai choisi

Je sais parfaitement qu'en fonction de certains besoin, 1GO de ram est catastrophique, dans des conditions "normales". Ici on parle de base de donnée dans une machine, qui est "attaqueé" par un programme développé en interne pour la partie instrument (C/C++) et en externe (C#) pour la partie résultat analyse. Et parmis les produits existant, c'est la seule solution qui conviennent aux besoin (j'attends l'évolution des cartes pour pouvoir passer sur du D525 avec de la DDR3 (oui oui, on est en DDR2 pour l'instant!), et avoir plus de RAM, pour autant qu'on en aie besoin.

Quand on développe de l'embarquer, on apprends a optimiser son code et sa base de donnée, et avec l'ingénierie on arrive a réduire le cout du matériel (quand on ne parle que de 1-2 machine, ca ne change rien de devoir mettre 4Go de RAM au lieu de 2... Mais la, on parle de minimum 600 machines par année... Donc 50 euros d'économiser c'est important, meme si ca demande 2 semaines de développements suplémentaire!)

Envoyé par SQLpro

C'est comme si vous disiez : je veut faire une balade sur des sentiers de montage... Je dois prendre des patins à glace !!!!

D'autant plus que vous voulez des performances !!! On rêve..........

Et pourtant j'y arrive... pour quelqu'un qui ne connait rien aux SGBD a vous lire, je dois pas trop mal me débrouiller...

Envoyé par SQLpro

Pour avoir eu certains clients avec du FireBird, la comparaison est immédiate : du fait de son mode transactionnel et donc du verrouillage qui en résulte, FireBird est incapable de monter correctement en charge avec une forte concurrence. Par exemple à plus de 10 requêtes simultanées, c'est la cata !
De nombreux éditeurs ont été confrontés à cela et sont généralement passé à SQL Server (plus qu'à PostGreSQL... question de responsabilité, même si PG reste un bon choix dans votre cas...).

En sus il y a très peu de ressources sur FB (site web, informaticiens compétents...) et beaucoup plus sur PG.
En d'autres termes, hélas pour FB, c'est sur la pente finale !!!! (j'ai pourtant été un ardent défenseur de Borland....)

Ah, enfin quelque chose en rapport avec la question initiale. Merci pour l'avis, c'est ce genre d'avis que j'attendais.

Envoyé par SQLpro

ça c'est du pipi de chat.
Petites bases : tient dans la RAM d'un serveur => moins de 30 Go
Moyenne bases : tiennent sur un seul disque de serveur : => moins de 150 Go
Grosses bases : moins de 1 To
Très grosses bases : plus de 1 To

Il ne sert STRICTEMENT A rien de découper une base en plusieurs fichiers si c'est pour les mettre sur un seul disque. Au contraire les performances chuterons !

Euh, ou j'ai dit que je voulais découper la base en plusieurs fichiers? J'ai juste dit que Firebird utilise un fichier unique pour stocker toutes les données d'une base. Et que la team A utilisait ce critère pour dire que c'est the best, car on a pas de risque de corruption de la table a cause d'un seul fichier (alors que je serais plutot a dire que l'important est la facon dont le filesystem gère pour éviter qu'il y aie le moindre souci, qu'on aie 1 ou 200 fichiers par base!)

Envoyé par SQLpro

Dans ce cas il faut mettre en œuvre des dispositifs de haute dispos, et malheureusement ni FB ni PG ne savent faire ceci actuellement.
Moi je m'orienterais donc vers SQL Server, voire même en version gratuite dans une premier temps (limite des bases : 10 Go).
Pour la haute dispos voir : http://sqlpro.developpez.com/cours/s...disponibilite/

Hors sujet. Je n'ai pas demandé de haute disponibilité, je sais pertinemment que ce n'est pas possible. Quand a SQL server, hors sujet aussi. L'environnement est une DEbian Squeeze et ne peut pas etre modifiée.

Envoyé par SQLpro

Backup et dump sont deux choses différentes :
http://blog.developpez.com/sqlpro/p7...-et-log-ne-so/

Merci, j'en suis conscient. Abus de langage qui m'arrive parfois. Dans notre cas, actuellement je ne suis pas sur de pouvoir effectuer de vrai backup. me contentant de faire des dumps a intervalles fixes, compléter par un journal de transaction pour la restauration. Mais ce point n'est pas encore défini, d'autant que le SGBD en lui meme ne l'est pas...

Envoyé par SQLpro

Je pense qu'il est avant tout nécessaire que vous vous formiez à ce qu'est un SGBDR avant tout, sinon, vous courrez à la catastrophe, et moi je gagne un client potentiel !

Que c'est prétentieux...

Envoyé par SQLpro

Lisez cet article que j'ai fait paraître il y a quelques années :
http://img1.lemondeinformatique.fr/f...s-epaisses.pdf

A +

Merci quand meme pour les quelques informations dont je pourrais tirer de cette réponse (approximativement 8 lignes sur la totalité de la réponse...)

Olivier

[SQLpro]

Envoyé par onet

On se trouve dans un environnement embarqué, en milieu industriel, avec des budgets, et des objectifs. Il se trouve que:
- l'intégralité du développement se fait en C/C++ sous Debian Squeeze (Choix effectué il y a plusieurs mois, après analyse des besoins)

Donc vous voulez que programme et SGBDR soient sur la même machine ?
C'est ce qu'il ne faut JAMAIS faire....

Les SGBDR sont tous préemptif au niveau des ressources du fait de leur OS interne. En gros, ils accaparent toutes les ressources au détriment même de l'OS causant la famine des autres processus.
Ils ont été conçus spécialement pour cela afin de maintenir les performances.

Donc, soit vous abandonnez l'idée d'avoir :

• de bonnes performances
• qu'un seul serveur physique
• un SGBDR Client/serveur

et dans le dernier cas, vous vous rabattez vers un SGBDR à base de fichiers genre Access ou SQL lite !

Compte tenue de la volumétrie, et s'il n'y a qu'un seul utilisateur simultané, SQL Lite devrait faire l'affaire !

A +

[onet]

Envoyé par SQLpro

Donc vous voulez que programme et SGBDR soient sur la même machine ?
C'est ce qu'il ne faut JAMAIS faire....

Ca tombe bien, il y a 2 pc industriels. Un qui s'occupe de l'application principale, et l'autre qui gère la base de donnée + un script d'analyse d'image.

Envoyé par SQLpro

Les SGBDR sont tous préemptif au niveau des ressources du fait de leur OS interne. En gros, ils accaparent toutes les ressources au détriment même de l'OS causant la famine des autres processus.
Ils ont été conçus spécialement pour cela afin de maintenir les performances.

Donc, soit vous abandonnez l'idée d'avoir :

• de bonnes performances
• qu'un seul serveur physique
• un SGBDR Client/serveur

et dans le dernier cas, vous vous rabattez vers un SGBDR à base de fichiers genre Access ou SQL lite !

Bienvenu dans la vie réel, ou les couts sont a mettre en relation avec l'infrastructure! Surtout que lire qu'il faut mettre du Access alors que je parle d'une environnement purement Linux, c'est faire preuve d'une très grande connaissance des SGBD... Sans parler de parler des performances d'une base de donnée Acces Oo

Après, SQL lite serait une solution... mais actuellement le choix est entre Postgresql et Firebird. Si on pouvait revenir à la question initiale...

Envoyé par SQLpro

Compte tenue de la volumétrie, et s'il n'y a qu'un seul utilisateur simultané, SQL Lite devrait faire l'affaire !

A +

Et non, il n'y a pas qu'un seul utilisateur (il serait bien de lire l'entier des posts, et pas entre les lignes...), étant donné qu'il y a déja 2 softs qui doivent se connecter sur la base de donnée, l'un depuis un programme en C++ basé sur le second pc industriel, et l'autre depuis un programme en C# tournant sur un environnement windows externe a la machine. De plus le soft en C# peut etre exécuter sur plusieurs postes, ce qui augmente le nombre possible d'utilisateur.

J'espère que cette fois le tour de la question a été effectué, et on peut revenir a la question initiale... Les éléments pouvant choisir le SGBD le plus adapté, c'est à dire connaitre les avantages / désavantages de chacun d'eux, en ayant les meilleures performance possible (encore une fois, je ne vis pas dans le monde de Candy... On a fait des choix, le but maintenant est de confirmer que, selon moi, le choix le plus adapté concernant le SGBD est postgresql.

merci.
Olivier

[ZerosCool]

C'est pas tout neuf... Mais c'est déjà une bonne base :-)
http://www.amsoftwaredesign.com/pg_vs_fb

[Jester]

Vu que la problématique est la mémoire, peut se concentrer sur les configuration possibles à ce niveau. Je sais que Postgres, alloue des buffers séparés (sort buffer, cache, ... donc la plupart ne sont pas utilisés tout le temps au top niveau mais non réinvestissable pour d'autres buffers), ce qui n'est pas très efficient. Peut-être que FB n'alloue qu'un espace unique.

[onet]

Hello,

Merci de ta réponse. En fait, actuellement, je n'ai pas le moindre souci de performance. Je suis en train de faire des test de perf, sur de grosse tables (enfin, sur le max de ce que j'ai besoin en terme de table!). Une recherche sur un string dans une table d'1 millions de donnée est instantané. Je suis en train de passer à 10 millions qui est le max que je vise.

Et je suis plutot tenter par partir sur Postgresql, de mon coté. Je n'aime pas du tout l'intégration de Firebird dans Debian. C'est galère à installer, configurer, maintenir (on en est installation automatisée sous forme de script).

Olivier

[kedare]

Je te conseille PostgreSQL, il est bien plus comlplet, configurable et mieux documenté que Firebird

Je le trouve aussi plus simple même si généralement les personnes disent l'inverse..

[ddaime]

Bonjour, j'ajoute ma petite contribution, a prendre pour ce quelle est. PG est sans doute un des meilleurs SGBDR du moment mais il est "lourd" (installation longue, administration), en revanche FB a plein d'avantage (leger, install rapide, administration simplifiée) de plus il existe une version "embedded".
Par contre l'intégration de FB dans une Debian n'est pas compliqué, ou est le pb ?

[kedare]

Heu je vois pas en quoi il est plus long a installé, PostgreSQL en 30 secondes il est installé....
L'administration c'est pareil, il y a quasiment rien d'obligatoire a faire une fois qu'il est installé si on veut l'utiliser

[_loki_]

il faudrait simplement faire des tests, j'ai une appli pour faire des benchmark de FB / Mysql / Sqlite ... si le coeur t'en dit tu peux rajouter postgreSQL dedans pour verifier ... je suis certain que firebird tiendrait largement la route

[makowski]

Franchement au vu de ce qui est dit, les deux feront l'affaire
prenez celui sur lequel vous avez le plus de compétences internes.

Peut être un plus pour Firebird, le choix possible entre les trois architectures Classic, SuperServer et SuperClassic

quand aux paquet Debian de Firebird, ils sont bien fait et bien maintenus

[epsilon68]

si je comprends bien, le BD sera sur une carte embarquée avec 1GO de RAM et un linux comme OS?
et 2 clients communiqueront avec cette carte embarquée...

c'est bien ca?

et c'est quoi comme communication entre la BD et les clients?
de l'HTTP ou le protocole de la BD?

[TryExceptEnd]

Envoyé par SQLpro

Pour avoir eu certains clients avec du FireBird, la comparaison est immédiate : du fait de son mode transactionnel et donc du verrouillage qui en résulte, FireBird est incapable de monter correctement en charge avec une forte concurrence. Par exemple à plus de 10 requêtes simultanées, c'est la cata !
De nombreux éditeurs ont été confrontés à cela et sont généralement passé à SQL Server (plus qu'à PostGreSQL... question de responsabilité, même si PG reste un bon choix dans votre cas...).

En sus il y a très peu de ressources sur FB (site web, informaticiens compétents...) et beaucoup plus sur PG.
En d'autres termes, hélas pour FB, c'est sur la pente finale !!!! (j'ai pourtant été un ardent défenseur de Borland....)

Question de responsabilité : on ne porte de jugement que sur ce qu'on maîtrise et apparemment c'est pas votre cas sur Firebird.

[makowski]

Envoyé par SQLpro

En sus il y a très peu de ressources sur FB (site web, informaticiens compétents...) et beaucoup plus sur PG.
En d'autres termes, hélas pour FB, c'est sur la pente finale !!!! (j'ai pourtant été un ardent défenseur de Borland....)

que vient faire Borland (qui n'existe plus) la dedans
Firebird n'a rien à voir avec Borland depuis 10 ans !
quand au support pro il existe comme pour Postgresql, le site web est en cours de refonte, la doc à bien progressée et progresse encore, la core team de Firebird est à peu près de la même taille et qualité que celle de Posgresql, Postresql à par contre grace à sa plus grosse base d'utilisateur sous Linux plus de contribution externe pour Linux, alors que les utilisateurs de Firebird sont majoritairement sous Windows, et donc culturellement participent moins.

Vous avez 10 ans de retard mon cher monsieur, parlez de ce que vous connaissez, cad Windows et SQLServeur, mais de grace évitez le reste.

mais arrêtons là cet apparté.

[SQLpro]

Le moteur de stockage utilisé par FB est toujours celui d'Interbase et son mode de verrouillage comme sa façon de gérer les transactions en est à peu près resté à ce que faisait IB dans sa dernière version.
Malheureusement ceci gène considérablement la montée en charge concurrentielle, alors que le moteur PostGreSQL hérité d'Ingres et qui a été à l'origine notamment de Sybase et SQL Server fonctionne de manière très différente ce qui assure une meilleurs montée en charge transactionelle.
Pour avoir été auditer différentes applications utilisant FB et IB (pour ces dernières il y a longtemps) je ne peut que recommander de passer sous PG si le nombre d'utilisateurs simultanés et les transactions sont nombreuses.
J'entends par là plus de 50 users simultanés et plus de 250 TPM (en pointe).

A +

[makowski]

Envoyé par SQLpro

.. le moteur PostGreSQL hérité d'Ingres et qui a été à l'origine notamment de Sybase et SQL Server fonctionne de manière très différente ce qui assure une meilleurs montée en charge transactionelle.

trop fort
résussir encore à faire de la "pub" pour MsSQL dans un débat sur le choix sous Linux de PG ou FB

impressionnant !

sans parler de la signature publicitaire

vraiment bravo !

quand à

J'entends par là plus de 50 users simultanés et plus de 250 TPM (en pointe).

c'est bien cela fait sérieux, mais on se demande d'où sortent ces chiffres

je me demande comment font MICEX et Distributelpar exemple sans parler de SAS (http://firebirdsql.org/devel/doc/pap...who-uses-sampl) pour ne pas exploser, mais bon passons

encore une fois, les deux conviennent, prenez celui que vous maitrisez le mieux
et restez loin des logiciels privateurs

[SQLpro]

L'exemple que vous donnez date apparemment de 2006... N'y a t-il personne qui utilise FB depuis ? ;-)

Environ 500 utilisateurs ne signifie pas 500 utilisateurs simultanés !

2 millions de transaction / jour cela ne fait que 1 400 transactions par minute là ou Oracle est capable d'en faire 4 million par minute et SQL Server 2,5 million par minute (source tpc.org).
Enfin, il semble que ces transactions et utilisateurs soient réparties sur 16 serveurs à raison de 2 bases par serveur....

Bref, j'ai l'impression que cela confirme plutôt mes propos que les vôtres....

Quand à ma signature elle vaut autant que la votre... La seule différence que j'y voit c'est que vous êtes sans doute un spécialiste FB défendant FB. Moi je suis un spécialiste SQL Server et là je défend PostGreSQL...
Enfin je ne pense pas avoir à rougir de mon travail en générale, et en particulier celui d'enseignant ni des différents livres que j'ai écrit sur SQL et qui comparent les différents SGBDR !!!!

A +

[fabrice_infocob]

Envoyé par SQLpro

... ni des différents livres que j'ai écrit sur SQL et qui comparent les différents SGBDR !!!!

Ça doit forcement être d'une impartialité incroyable vu que sur ce fil de discussion, pourtant axé sur Firebird et Postgresql, vous ne pouvez pas vous empêcher d'essayer de nous vendre du SQL Server à chaque réponse. Et je ne parle pas de la confusion entre Firebird et (défunt) Borland.

Utilisant Firebird depuis sa naissance je ne comprends pas non plus l'argument sur le fait que se fussent le nombre de ses experts qui font la viabilité d'un SGBD. C'est encore un argument pour vendre des services sponsorisés ?
Car l'avantage énorme de Firebird c'est justement de ne pas avoir besoin d'expert pour s'en servir pleinement.