| Firebird Documentation Index → Livre Blanc Firebird en Entreprise → Firebird est il “Prêt pour l'entreprise”? |
|
|
|
Définir l'expression “Prêt pour l'Entreprise” est beaucoup plus difficile que compter le nombre de réponses sur Google. La presse en ligne utilise cette expression comme si elle était clairement définie, comme “nouveau né” ou “détaxé”. On en conclut que cette chose éphémère, quelque chose que tout le monde désire pour un logiciel de bases de données, est, soit présente, soit absente, et ne peut être obtenue que dans des produits commerciaux.
Pour aborder la question de manière constructive, la première chose est de trouver un contexte d' “entreprise” qui corresponde au cas traité. Les deux questions rationnelles à ce poser sont : Quels besoins, présents et futurs, de l'Entreprise X doivent être satisfaits par les fonctionnalités du système de gestion de bases de données ? Le SGBD Y y répond-il?
Ceux d'entre nous qui sommes du côté des utilisateurs plutôt que du côté des critiques de la presse examineront les fonctionnalités nécessaires pour l'entreprise à travers six filtres : stabilité, extensibilité, disponibilité, capacité, interopérabilité et autonomie.
Nous voulons un système de gestion de bases de données qui enregistre les données nécessaires à notre activité et qui les protège contre les dégradations possibles en provenance soit de problèmes liés à notre environnement système soit d'erreurs humaines. Notre système doit être capable de délivrer les données aux applications de manière consistante et flexible, avec certitude et à une vitesse raisonnable et doit être capable de gérer d'éventuels conditions de conflits. Il doit pouvoir faire tout cela en même temps, sans interruptions, dégradations, crashes ni temps d'attente excessif.
Une telle stabilité est évidente pour un SGBD, quelques soient les autres facteurs désirés par l'entreprise. Un ensemble de principes a évolué au cours du temps pour définir quatre points essentiels qui ne doivent pas manquer à un système de gestion de bases de données pour être pris au sérieux. “ACID” est l'acronyme de ces quatre principes : Atomicité, Cohérence, Isolement, Durabilité.
La conception et l'architecture de Firebird respectent complètement la norme “ACID”. Les concepts ACID sont décrits plus bas, dans la section Conformité ACID et Firebird, avec des commentaires sur comment Firebird respecte ces principes.
Tout dans Firebird est fait dans le contexte d'une transaction ACID. Une transaction dans Firebird peut mettre en oeuvre de nombreuses phases, complexes et inter-dépendantes d'une tâche d'entreprise mais ne permettra jamais la violation d'aucun principe ACID.
Ayant en tête la stabilité de notre environnement de production, nous ne choisirons pas forcément un tout nouveau SGBD pour être le coeur de notre système d'information. En général, nous préferons commencer avec un produit qui a prouvé ses capacités et dont les forces et faiblesses sont connues et bien comprises. Si un utilisateur final doit être en charge de répondre aux problèmes qui peuvent arriver, nous devons savoir à qui ils peut demander de l'assistance. Si un distributeur de solution logicielle doit assurer le support technique, est-ce que ce distributeur peut être en mesure d'obtenir le support adéquat ?
La communauté des utilisateurs de Firebird est bien aidée par des développeurs d'outils et d'applications très compétents. En général, ces développeurs sont proches du code source développé depuis six ans. Leur expérience et leur expertise remonte même au delà, au début des outils de développement de Borland, qui ont toujours été livrés avec la version d'InterBase "Développeurs" dans leur version Entreprise.
La communauté de développeurs Firebird est renommée pour ses forums de support, où l'expertise y est constamment partagée.
Des contrats de support pour utilisateur finaux, même s'ils sont offert par plusieures entreprises, sont rarement demandés. Des contrat de support pour les développeurs sont disponibles dans de nombreux pays, y compris la France. Toutefois, il doit être signalé que la demande de support pour les développeurs, mise à part peut être la phase d'installation sur une plate-forme non familière, est faible dans la plus part des pays.
D'un autre coté, parce que l'activité, les demandes et les configurations matérielles évoluent constamment et rapidement, nous voulons aussi savoir si le SGBD est dans une phase active de développement ou s'il est proche de la fin de sa vie. Nous espérons des mises à jour régulières de versions intermédiaires et d'avoir des signes qu'une nouvelle version majeure est en cour de réalisation. Quand nous serons en production, sera t-il facile de faire la mise à jour ? Nos bases de données existantes pourront-elles facilement être intégrées dans une nouvelle version, ou bien ce processus sera t-il pénible, ou long, ou presque impossible ?
Maintenant dans sa sixième année, l'équipe du Projet Firebird continue en toute confiance le développement des versions prévues qui vont amener les améliorations architecturales pour profiter des améliorations matérielles et satisfaire les besoins exprimés de la communauté des développeurs, utilisateurs et supporteurs techniques. La transparence du code et la célèbre volonté de la communauté de partager sa connaissance assure une maîtrise parfaite du code source et des possibilités du logiciel.
L'indépendance du projet vis à vis des entités commerciales assure la continuité du projet et assure que la discipline technique prévaut sur une quelconque volonté marketing de peser sur l'évolution du produit.
Par extensibilité on désigne le fait que le SGBD soit capable non seulement de répondre aux besoins actuels de l'entreprise, mais aussi capable de grandir avec elle, de répondre à des accroissements de charge mais aussi de répondre à des besoins moindres (applications mono utilisateur, modèle déconnecté ou embarqué par exemple).
Les considérations liées à l'extensibilité à prendre en compte sont les nombres minimum et maximum d'utilisateurs actifs, l'effet de la croissance de la taille de la base et du nombre d'utilisateurs sur les performances ou la stabilité, les possibilités de migration des données en cas de changement d'échelle. Pour certaines entreprises, les facteurs d'extensibilité prendront le pas sur toues les autres considérations, comme la disponibilité ou l'interopérabilité.
L'extensibilité quelle que soit sa direction est une des forces de Firebird. Contrairement à beaucoup d'autres systèmes concurrents, Firebird, depuis même ses premiers jours sous le nom d' InterBase, a toujours été un logiciel conçu pour le fonctionnement en réseau, et sa structure de stockage sur disque des bases de données a toujours été gérée indépendamment du système de fichier hôte, par le moteur de base de données lui même.
A la différence de certains systèmes très valorisés sur le marché, supposés être “prêts pour l'entreprise”, qui répondent à la demande d'extensibilité en cas de croissance des besoins par des ajouts logiciels et des mécanismes nombreux et lourds, la question de la croissance avec Firebird est essentiellement seulement une question de modification de l'environnement. Le même moteur gère confortablement toutes les situations depuis un système embarqué avec un seul utilisateur, en passant par le système classique d'une architecture deux tiers client/serveur en réseau avec environ 750 utilisateurs potentiels, jusqu'à son implication dans une solution multi-tiers pour des centaines de clients potentiels. La croissance des bases de données est seulement limitée par la capacité de stockage disque disponible et une base peut être découpée pour être placée sur plusieurs disques durs.
A l'aide d'une réplication intelligente et une bonne gestion des connexions d'accès, la charge d'un système très chargé peut être distribuée sur de multiples serveurs. Par exemple, un serveur central bien dimensionné peut servir les demandes d'accès du réseau, intranet ou extranet (ou les deux ensemble) pendant qu'un serveur répliqué prend en charge les traitements longs qui demandent un cliché isolé des données pendant une longue période.
Le maximum de disponibilité est parfois mesuré par le critère des “cinq neuf” : le serveur est il capable d'offrir une disponibilité à 99.999 pour cent pendant les heurs de service ? Parmis ces utilisateurs, Firebird a la réputation d'être parfaitement disponible.
Certains des systèmes de gestion de données demandent une coûteuse expertise sur site pendant tout le temps de fonctionnement du système de bases de données. Le déploiement typique de Firebird est celui des entreprises qui n'ont pas d'administrateur de bases de données (DBA).
Comme pour tout système complexe, un déploiement de Firebird doit être bien planifié et bien conçu, mais un déploiement de Firebird configuré convenablement dans une infrastructure réseau efficace “fonctionne tout seul”. Il utilise un système de verrous optimiste au niveau des enregistrements, qui réduit considérablement le temps d'attente en comparaison avec d'autres systèmes où des transactions en lecture-écriture verrouillent des ensemble entiers, voire des tables, de manière préventive. Aucun réglage fin n'est requis pour gérer les différences de charge au cours du temps. Une base n'a pas besoin d'être arrêtée pour être sauvegardée. Elle peut être répliquée ou dupliquée pour prévenir les coupures dues à un crash du disque. Firebird est robuste et se remet en route immédiatement après une coupure de courant, sans dommage pour l'intégrité des bases.
Firebird est un choix populaire pour les entreprises ayant besoin d'une continuité de service 24h sur 24. Des outils en ligne de commande sont inclus dans la distribution pour toutes les tâches administratives, permettant d'automatiser la maintenance régulière dans des tâches programmées. Une API de services est aussi disponible pour inclure des tâches d'administrations dans un autre programme.
Les sauvegardes en ligne (gbak) ne créent pas des bases de données mais des fichiers neutres vis à vis de la plate-forme qui contiennent les métadonnées et les données de manière séparée dans un format texte compressé. Firebird 2 dispose d'un outil de sauvegardes incrémentales, qui peut être planifié afin de s'adapter à la charge du serveur.
La plus grande base Firebird que nous connaissons fait environ 11 Teraoctets et continue de grossir. Les tables sont limitées à environ 2.000.000.000 lignes et, jusqu'à la version 1.5.x, à un maximum d'environ 30 Gigaoctets par table. Cette limite maximum de taille de table n'existe plus dans la version 2.0, disponible mi-2006.
Firebird fait partie des SGBD qui respectent le plus les normes internationales (ISO) et U.S. (ANSI) pour le langage SQL, faisant même mieux que son cousin InterBase. Les normes évoluent continuellement et, en parallèle, les développeurs de Firebird font évoluer le produit en concordance.
Les implémentation existantes des fonctionnalités du langage qui font l'objet d'une nouvelle norme sont gardées comme des "options dépréciées" pour garantir la compatibilité descendante.
Firebird est conçu pour l'interopérabilité. Il n'est lié à aucune “solution intégrée” qui lie les bases de données à un environnement spécifique. La décision de déplacer une base de données Firebird depuis Windows vers une machine Linux ou Unix, et vice versa, peut littéralement se mettre en oeuvre du jour au lendemain. Tout ce qu'il faut, c'est une sauvegarde au format transportable sur l'ancienne machine et une restauration sur la nouvelle, et vous voilà de nouveau opérationnel.
Les distributeurs d'applications qui sont conscients de cette facilité de migration sont attentif au fait que les serveurs Firebird peuvent être facilement utilisés par des logiciels clients qui tournent sur un système d'exploitation qui peut être différent de celui sur lequel tourne le serveur et que cette situation peut facilement évoluer.
Firebird est capable de fonctionner dans des environnement réseaux hétérogènes. Une application écrite pour un système d'exploitation peut facilement se connecter à une base tournant sur un autre système d'exploitation, sans modification. Une application peut se connecter à de multiples serveurs sur des hôtes avec des systèmes d'exploitations différents simultanément et peut utiliser des transactions sur des bases multiples sur des serveurs différents.
Il est fréquent, par exemple, pour des sites très utilisés, de faire tourner plusieurs serveurs Firebird, de mettre en place une réplication depuis un serveur principal important vers des serveurs moins coûteux et moins surchargés fonctionnant sous Linux avec des systèmes disques rapides pour mettre en place une solution de délestage (load-balancing) et de prévention des pannes.
Les serveurs Firebird peuvent aussi être intégrés à des solutions hétérogènes de type MTS et Citrix, dans des environnement pass-through et des réseaux privés virtuels (VPN).
Firebird n'a pas besoin de suites ou modules spéciaux pour le lier à une application externe. Toutes les interfaces d'accès dialoguent avec le serveur à l'aide des deux interfaces publiées (APIs), une pour les opérations au niveau des bases de donnée et l'autre pour les opérations serveur comme les sauvegardes et l'authentification des utilisateurs.
Des pilotes sont disponibles pour une grand nombre de langages et d'interfaces, y compris Java/JDBC, ODBC, .NET, Delphi, Python, PHP et Perl.
L'autonomie se mesure par le degré avec lequel une base stocke et gére les données en ayant “sa propre vie”, c'est à dire sa capacité à exister et rester cohérente indépendamment du matériel et du système d'exploitation,des programmes externes, des environnement spécifiques de programmation.
“Les fonctionnalités d'autonomie” comportent des point comme
indépendance du système de fichiers
intégrités référentielles déclaratives
la possibilité de mettre en oeuvre des validation et/ou des règles de gestion à l'aide de déclencheurs et des contraintes CHECK
les procédures stockées, pour intégrer des procédures de gestion et les mettre en action de manière interne, indépendamment du langage des applications ou de l'interface utilisateur
le contrôle d'accès des utilisateurs au niveau de la base
la possibilité d'interroger des données externes comme des structures “virtuelles” sans avoir besoin de stocker des données
la possibilité de gérer des ensembles de données temporaires par programmation sans avoir à matérialiser des tables temporaires
garder des fonctionnalités dépréciées pour assurer la rétro compatibilité
Firebird prend en charge toutes ces fonctionnalités.
Un point supplémentaire d'autonomie qui est devenu un problème pour les utilisateurs de nombreux SGBD évolués dans les temps récents est le degré de transparence avec lequel des anciennes bases de données peuvent être administrées et migrées quand le logiciel serveur est mis à jour ou que les bases sont déplacées vers une nouvelle plate-forme matérielle ou logicielle. Souvent ces problèmes deviennent des opérations très coûteuses en temps et en logistique.
Au contraire d'autres SGDB significatifs, à part le cousin de Firebird, InterBase, la migration de bases est sans heurts. Contrairement aux autres, qui ont une architecture dur disque différente selon les plate-formes, ou qui ne gèrent leurs bases que sur une seule plate-forme, la structure des bases Firebird est stable quelle que soit la plate-forme. Cela veut dire, par exemple, que si le choix d'un système d'exploitation pour le serveur se révèle être une solution sous-optimale, vous pouvez changer pour un autre serveur avec simplement le temps qu'il faut pour faire une sauvegarde et une restauration.
Une nouvelle version de Firebird se connecte à n'importe quelle base de données qui fonctionnait sous une version précédente et une sauvegarde transportable d'une base faite sur une autre plateforme matérielle ou logicielle peut être restaurée, prête à fonctionner, sur n'importe quelle autre plateforme supporté par la nouvelle version.
Quand une mise à jour est faite vers une nouvelle version majeure, il est hautement recommandé, même si ce n'est pas essentiel, de faire passer les bases par le cycle de sauvegarde restauration, afin de mettre à jour la structure de stockage sur disque et rendre les nouvelles fonctionnalités disponibles. La question qui se pose pour savoir s'il faut le faire où non est uniquement liée au fait de savoir si le fournisseur de l'applicatif a déjà mis à jour son application pour utiliser les nouvelles fonctionnalités.
|
| Firebird Documentation Index → Livre Blanc Firebird en Entreprise → Firebird est il “Prêt pour l'entreprise”? |