I. Revue de Firebird 2.0▲
Il y a quelque temps, plusieurs de nos utilisateurs ont été étonnés par le nombre de dispositifs libérés dans Firebird 1.5.
Honnêtement, avant de préparer cet article, je n'avais ni comptabilisé les nouvelles fonctionnalités ni aucun indice quant à sa supériorité à la version 1.5. Cependant, l'avantage principal de la version 2.0 ne repose pas sur les fonctionnalités proposées. « Quel est-il alors ? » me demanderez-vous ? Je décrirais Firebird 2.0 comme « version dépassant les limites ennuyeuses ».[…] Je m'explique : aucun doute que Firebird possède une bonne architecture multigénérationnelle et un langage SQL riche, ainsi qu'une bonne intégration et une bonne exécution. Je suis presque sûr que chacun d'entre vous a pu faire l'expérience des quelques limitations internes qui vous ont peut-être inquiété, voire choqué. Pour en citer quelques-unes (sans ordre particulier) :
- la limite non documentée de table environ de 35GB, un débordement peut causer la corruption de données ;
- la libération (garbage collecting) des nœuds d'un index non sélectif est extrêmement lente ;
- une augmentation du cache de pages signifie souvent une exécution plus lente ;
- l'optimiseur ne choisit pas toujours le meilleur plan ;
- le support international est faible, nombreux bugs dans la manipulation d'Unicode/MBCS ;
- absence d'un mécanisme rapide de backup/restore ;
- sécurité faible et nombreuses vulnérabilités connues ;
- condition d'accès aux bases de données en exclusif pour des déclarations référentielles d'intégrité ;
- trop peu de fonctions intégrées ;
- arrêt incertain des bases de données.
Certaines d'entre elles sont d'une priorité critique d'un point de vue métier, d'autres sont simplement ennuyantes. Quoi qu'il en soit, je suis heureux de vous annoncer que Firebird 2.0 élimine la plupart des problèmes mentionnés ci-dessus et réduit de manière significative l'impact des limites encore présentes. J'y accorde, quant à moi, plus d'importance que la déclaration d'un nouveau langage. Cependant, en considération des tonnes de bugs à résoudre et des nouvelles fonctionnalités, Firebird 2.0 représente assurément une évolution déterminante de votre SGBDR favori désormais plus robuste, plus complet, plus rapide et beaucoup plus convivial pour les utilisateurs non ASCII.
Bien sûr, il existe encore des limites et de nombreuses fonctionnalités que nous ne soutenons pas encore. D'ailleurs, il nous faudrait envisager une conférence uniquement consacrée aux améliorations, n'est-ce pas ? Nous aborderons ce sujet un peu plus tard.
Bien, pour ceux qui s'intéressent aux chiffres, lisons les documents WhatsNew et Release Notes et faisons un sommaire totalisant le nombre de changements par version :
- Version 1.0 : 32 améliorations, 55 bugs résolus ;
- Version 1.5 : 58 améliorations, 94 bugs résolus ;
- Version 2.0 : 82 améliorations, 140 bugs résolus.
Note : les statistiques de la version 2.0 représentent son état actuel, c.-à-d. Bêta 1 release. Impressionnante, n'est-ce pas ?
Bien sûr, Firebird 1.5 a été développé sur une période plus importante que Firebird 1.0 et il en va de même pour Firebird 2.0 de toute évidence. Ainsi vous constatez comment le temps d'élaboration a été utilisé.
II. Feuille de route des versions futures▲
À court terme, notre premier objectif est de fusionner, pour la sortie de la version 3.0, deux codebases : Firebird 2.0 et Vulcan. Cette version sera basée sur l'arbre de Vulcan et possèdera une architecture modulaire, ainsi que des nouvelles fonctionnalités, au même titre que toutes les améliorations apportées par Firebird 2.0. Les dispositifs principaux du codebase de Vulcan sont :
- restructuration globale du code ;
- multithreading de bonne qualité ;
- architecture basée sur un provider unique ;
- mécanisme flexible de configuration ;
- niveau d'authentification des bases de données et gestion de la sécurité avancée ;
- exécution interne de DSQL.
Alors que les Releases de Firebird 2.0 et de Firebird Vulcan coexisteront l'année prochaine, vous vous demandez pourquoi la version 3.0 est numérotée en majeur release et ce qu'elle contiendra de plus (excepté des fonctionnalités déjà présentes dans les deux codebases). C'est une bonne question. Bien que nous souhaitons réduire le cycle de développement 3.0 autant que possible, on ne s'attend pas à ce qu'un nouveau développement complet se produise dans cette version. Cependant, nous avons besoin de préserver nos utilisateurs avertis, et, en conséquence, quelque chose de nouveau devrait être présenté. La solution est simple : la release 3.0 va incorporer tout le travail fait par des branches indépendantes internes. Comme vous le savez peut-être, il y a quelques améliorations faites par les divers réalisateurs de Firebird qui ne sont pas entrées dans la release 2.0, dû aux contraintes de temps. Certaines d'entre elles sont incluses et examinées dans Fyracle, d'autres resteront encore dans les arbres privés. En outre, nous avons toujours quelques dispositifs dans Yaffil qui exigent un backporting dans Firebird. Tout ce qui est mentionné ci-dessus est exactement la nouvelle substance que vous verrez dans la version 3.0. voyons ce qui a été déjà fait.
- Les tables d'expressions et requêtes récursives communes (conforme Sql-99)
Développé par : Paul Ruizendaal
État actuel : Accompli - Les tables temporaire globales (conforme Sql-99)
Développé par : Vlad Horsun
État actuel : Accompli - Les procédures/fonctions externes (conforme Sql-99)
Développé par : Eugene Putilin, Roman Rokytskyy, Vlad Horsun
État actuel : Partiellement fait, exige la discussion du rappel de service API - Les nouvelles fonctions intégrées (string, maths, binaire, date/time)
Développé par : Oleg Loa
État actuel : Accompli, mais exige quelques changements
Ces évolutions sont les candidates principales pour Firebird 3.0, mais il y en a d'autres (moins importantes) aussi bien.
Dès que la version 3.0 sera disponible pour l'essai public, le développement de la prochaine version commencera. Nous n'avons pas encore pris de décision au sujet de la numérotation de version, ainsi elle pourrait être 3.5 ou 4,0 ou autre. Sur la durée de cet entretien, je l'appellerai la « version 3.0+ », où le + signifie simplement « la prochaine version ». La version 3.0+ aura des changements majeurs de l'ODS aussi bien que beaucoup d'options d'administration, de traçage (log), de sécurité, de performance et une amélioration du support SQL. Et plus probablement, il contiendra également la mise à jour à distance du protocole. Maintenant c'est un peu tôt pour dire ce qui sera exactement inclus dans cette version, mais vous trouverez quelques informations un peu plus tard.
Si vous me demandiez de décrire les priorités de développement générique, elles seraient :
- Fiabilité et sûreté (résolution de bugs, récupération garantie et améliorations de la sécurité) ;
- Facilité d'administration et monitoring ;
- Compatibilité avec les normes SQL ;
- Performance (algorithmes et optimiseurs améliorés) ;
- Extensions du langage.
Maintenant quelques mots au sujet des versions intermédiaires 2.0. D'abord, notre programme de maintenance couvrira certainement le produit 2.0, et donc les nouvelles versions 2.0.1, 2.0.2, etc.. (contenant des bugfixes) presque tous les mois. Comme toujours, ces versions se composeront de changements backported de la branche active du développement. Ainsi, si vous voyez votre bug « favori » fixé dans la version 3.0, vous êtes libre d'interroger des réalisateurs au sujet de le mettre en application dans la prochaine version de 2.0.x. En second lieu, je m'attendrais à ce que certaines des évolutions programmées de la 3.0 (par exemple implémentation de GTT ou le code WITH [RECURSIVE]) soient portées sur la branche de développement 2.0 HEAD avant de fusionner afin de rendre une version 2.1 mineure possible dans le cas d'un retard avec le développement 3.0.
Rappelant tout ce qui a été dit ci-dessus, le planning devrait ressembler à ça :
2005
- Release 2.0 RC et déviation vers 2.0 HEAD pour créer la branche de développement
- Porter quelques changements aux arbres indépendants à HEAD
- Division du Vulcan HEAD pour créer la branche de développements pour 3.0
2006, 1er trimestre:
- Sortie des versions finales Firebird 2.0 et Firebird Vulcan
2006, 2e trimestre
- Sortie Firebird 3.0 Bêta
- Division de la 3.0 HEAD pour créer la branche de 3.0+ développements
2006, 3e trimestre
- Sortie de la version finale Firebird 3.0
2006, 4e trimestre
- Sortie de Firebird 3.0+ Bêta
Le point clé de cette feuille de route est la mise à disposition des releases Firebird 2.0 et Firebird Vulcan. Et c'est exactement le point où votre aide avec testing/feedback nous permet d'avancer plus rapidement.
III. Quelles sont les fonctionnalités à prévoir ?▲
La présente partie de notre entretien est consacrée aux activités de projet que nous compterions voir dans un avenir proche. Pour suivre la liste plus facilement, elles sont groupées par catégorie, semblable à notre traqueur RFE.
Chaque travail a deux paramètres associés : priorité et complexité. La valeur prioritaire est basée sur des souhaits d'utilisateurs, elle est installée après avoir regardé de divers scrutins et discussions de forum/newsgroup. En d'autres termes, elle montre combien nos utilisateurs veulent des fonctionnalités particulières. En outre, cette valeur dépend de notre analyse des fonctionnalités offertes par nos concurrents. La valeur de complexité est basée sur des évaluations de temps/effort faites par l'équipe de noyau. « Aucune » signifie que tout le travail exigé est déjà effectué (dans une certaine branche de développement) et nous avons juste besoin de backport et de tests. « Implementation » signifie que la fonctionnalité a déjà été discutée et des accords ont été convenus, mais il exige toujours quelques discussions mineures et le codage réel. « Design » signifie que nous avons un accord de base et quelques visions des choses, mais que le travail détaillé n'a pas encore été discuté et par conséquent nous n'avons aucun planning de réalisation. « Recherche » signifie que le travail exige une analyse sérieuse avant de discuter des caractéristiques de conception et d'exécution.
III-A. Administration/Tracer/Surveillant▲
- Monitoring via l'API et/ou des tables spéciales
Exécuter un « snapshot » de monitoring (c.-à-d. à un moment donné) des activités internes à l'intérieur du moteur. Les objets évidents d'une telle surveillance sont : les bases de données, les attachements, les transactions, les requêtes actives, l'utilisation de ressource (mémoire, CPU), etc.
priorité = haut
complexité = design/implementation - Rapport asynchrone d'Annulation/time out
Forcer n'importe laquelle des actions suivantes : annuler un statement courant, rollback d'une transaction, tuer une dépendance. Permettre un time out pour des statements SQL. Devrait être disponible au moins au niveau de l'API.
priorité = haut
complexité = Implementation - Logging/audit détaillé
Permettre le log de quelques événements se produisant sur le serveur. Ceux-ci peuvent être : l'authentification acceptée/rejetée (contenant l'information du client), préparer/exécuter des statements SQL, de committed/rolled back des transactions, etc. Nous avons besoin d'API pour installer les événements requis et pour rechercher la notation d'audit.
priorité = moyenne
complexité = design - SQL détaillé tracing/profiling
Montrer les détails du chemin d'accès (au niveau de l'arbre RSB) pour chaque récupération, le nombre de lignes (profil TEMPS CPU, etc.) pour chaque nœud. Les statistiques d'exécution disponibles devraient être étendues.
priorité = moyenne
complexité = design/implementation - Niveau DDL et triggers globaux.
Permettre des triggers ON CREATE/ALTER/DROP. Implémente les dépendances de triggers et le niveau de transaction des triggers en fonctionnement dans des transactions autonomes.
priorité = moyenne
complexité = design - PSQL debugging extentions/hooks
Permettre le débogage PSQL via introduction : looper breakpoints, handler callbacks, récupération du contexte de données, etc.
priorité = basse
complexité = Recherche
III-B. Sécurité▲
- Gestion des users/SQL users
Permettre la gestion des utilisateurs dans la base de données
priorité = haut
complexité = Aucune (fait dans Vulcan) - Droits d'utilisateur pour les métadata
Protéger toutes les métadata avec des classes de sécurité. Mettre en application les permissions au niveau metadata. Ajouter les permissions au niveau base de données comme BACKUP, DROP, etc.
priorité = haut
complexité = design - Modules d'authentification pluggable
Activer l'utilisation de mécanismes d'authentification adaptés (par exemple ceux de l'OS)
priorité = moyenne
complexité = Design - Groupes de sécurité
Concevoir une sécurité basée sur les groupes comme alternative à celle basée sur les rôles.
priorité = moyenne
complexité = Recherche - Cryptage de la base de données
Permettre le cryptage des enregistrements de la base de données. La gestion de clefs reste une question en suspens ici.
priorité = moyenne
complexité = Recherche
III-C. Extension du langage▲
- Schemas/espace dans les noms
D'abord, il réduit de manière significative un coût de l'issue avec des noms courts de métadata. En second lieu, il simplifie l'administration, car un certain nombre de différentes bases de données pourraient être unies dans un fichier simple. Troisièmement, il nous permet finalement d'être entièrement conforme Sql-92 (niveau d'entrée).
priorité = haut
complexité = Recherche - Type de données numériques long d'origine
Mettre en application le type de données long numérique exact (avec une précision jusqu'à plus de 30 chiffres décimaux) et l'arithmétique BCD appropriée.
priorité = haut
complexité = Recherche - Plus de fonctions intégrées
Les fonctions intégrées Sql-99 (celles d'importance majeure pour nous) doivent être implémentées d'abord. Puis nous aurons besoin des feedbacks d'utilisateurs sur d'autres fonctions.
priorité = haut
complexité = Design/Implementation - Tables temporaires/datasets
Permettre les schémas d'objets et/ou datasets temporaires. La conformité Sql-99 est exigée, des extensions sont les bienvenues.
priorité = haut
complexité = Design/Implementation (partiellement fait dans Fyracle) - De plus longs noms de métadata
Jusqu'à 128 caractères d'Unicode.
priorité = moyenne
complexité = Design - Fonctions SQL
fonctions CREATE/ALTER/DROP selon Sql-99.
priorité = moyenne
complexité = Implementation - Domaines partout
Permettre l'utilisation des domaines dans les paramètres et les variables de PSQL, aussi bien que dans la fonction de CAST.
priorité = moyenne
complexité = Design - Requêtes récursives
L'utilisation du SQL pour des récupérations récursives. Rendre conforme aux spécifications de SQL.
priorité = moyenne
complexité = Aucune (fait dans Fyracle) - Expressions régulières
Permettre l'utilisation des expressions régulières en condition de recherche. Ajouter une certaine syntaxe spéciale (un nouvel attribut).
priorité = moyenne
complexité = Design/Implementation - TEXT BLOB compatible avec [VAR]CHAR
Permettre au BLOB SUB_TYPE TEXT d'être compatible/interchangeable avec des types de données chaine de caractères. Permettre les TEXT BLOB dans toutes les fonctions intégrées.
priorité = moyenne
complexité = Design/Implementation - Contraintes reportées
Mettre en application la contrainte de commit-time vérifiant les spécifications de SQL.
priorité = basse
complexité = Design
III-D. Extensions/Optimiseurs▲
- Jointures externes plus rapides
Implémenter l'algorithme de fusion pour les jointures externes.
priorité = haute
complexité = Implementation - Améliorations d'optimiseur
Fixer bugs/limitations connus, de meilleures décisions d'optimiseur, plus de statistiques de données
priorité = moyenne
complexité = Design/Implementation - Plus de chemins d'accès
Implémenter de hash join / hash aggregate et d'autres algorithmes de récupération utilisés dans les concurrents SGBDR.
priorité = moyenne
complexité = Recherche - Tris plus efficaces
Implémenter un tri partiel pour accélérer les récupérations limitées (FIRST). Trier les RecNo au lieu des enregistrements entiers (rows).
priorité = moyenne
complexité = Design - Protocole de réseau optimisé
Éviter d'envoyer beaucoup de données inutiles (buffer tails). Implémenter des groupes de protocole (par exemple préparation + information). Comprimer les espaces plus efficacement.
priorité = moyenne
complexité = Recherche
III-E. Maintenance/Récupération▲
- Protection logique fiable
Le seul cas de la protection inrestaurable devrait être une protection physiquement corrompue. Les objets primitifs (générateurs, UDF, etc.) doivent être reconstitués dans le commencement. Des colonnes calculées et les contraintes de validation doivent être reconstituées à l'extrémité. Le moteur devrait rejeter des données contradictoires au lieu de les transformer en indiquant (par exemple aucune valeur - > NULLE). GBAK devrait permettre la restauration partielle, conduite par des commutateurs ou interactivement.
priorité = haute
complexité = Design - Récupération Point-dans-temps
Le moteur doit avoir une capacité facultative de maintenir un log de « à refaire » (redo) pour passer au-dessus de la dernière protection logique. Aucune perte de données n'est acceptable.
priorité = haute
complexité = Recherche
III-F. Générique/Architecture▲
- Appui de SMP dans le SuperServer
Supporter de manière efficace le multithreading dans l'architecture du SuperServer.
priorité = haute
complexité = Aucune (fait dans Vulcan) - Mise en cache des « statements » compilés
Supporter la mise en cache et la réutilisation des « statements » compilés.
priorité = haute
complexité = Implementation (partiellement faite dans Vulcan) - Contenu des statements/transactions
Résoudre les contradictions connues dans les verbes/transactions. La plupart du temps, ceci couvre le comportement de blr_for dans des rapports d'insert/update/delete. Rendre les transactions read-committed conformes avec les spécifications SQL.
priorité = haute
complexité = Design - Source de données externe/liens de base de données/base de données SQL croisée
Permettre la récupération depuis des sources de données externes. Fournir quelques drivers (FB natif, JDBC, ODBC) dans les distributions. Ajouter DDL pour déclarer et DML pour employer de telles sources. Implémenter l'optimisation des récupérations pour les sources de données natives.
priorité = haute
complexité = Recherche - Fonctions/procédures externes
Permettre de créer des procédures/functions écrites en langues non PSQL. Fournir quelques drivers (cdecl, Java, NET) dans les distributions.
priorité = haute
complexité = Design/Implementation (partiellement fait dans Fyracle) - Recherche intégrale de texte
Implémenter les fonctionnalités FTS à l'intérieur du moteur ou ajouter l'API pour brancher les moteurs externes FTS. FB semble être le seul SGBDR qui n'a pas cette fonctionnalité actuellement.
priorité = moyenne
complexité = Recherche - Clustering
MySQL soutient les clusters (AFAIK, seulement mémoire partagée jusqu'ici), il en est de même pour PostgreSQL avec les disques partagés. Cette fonctionnalité fait de plus en plus parler d'elle. Nous devrions être plus concurrentiels.
priorité = moyenne
complexité = Recherche - Index bidirectionnels
Permettre la navigation renversée d'index pour l'utilisation des ASC-index pour les tris DESC et vice versa.
priorité = moyenne
complexité = Implementation - Intégrité référentielle sans index
Permettre (sur option) les clefs étrangères qui ne sont pas imposées par des index. Fournir en outre une capacité de réutiliser l'index existant pour une contrainte.
priorité = moyenne
complexité = Design - Le volume load/import
Permettre des capacités de charge massive plus efficaces. Fournir les utilitaires et la syntaxe pour l'emploi de différents formats d'entrée (csv, schéma de xml, etc.) pour l'importation.
priorité = moyenne
complexité = Design - Curseurs bidirectionnels
Implémentation des curseurs scrollable à l'intérieur du moteur ou fournir une couche mince au-dessus de la hiérarchie RSB pour mettre en application la fonctionnalité par l'intermédiaire du cache.
priorité = basse
complexité = Recherche - Intégration de XML
Passer du dernier fetch au XML et permettre les insertions depuis le XML. Permettre le BLOB SUB_TYPE XML et mettre en application des requêtes XPath.
priorité = basse
complexité = Recherche
III-G. Les évolutions par versions futures▲
Évidemment, la liste mentionnée ci-dessus n'est pas complète, elle inclut uniquement les changements que nous considérons la plupart du temps comme importants. Si dans cette liste manque votre souhait, parlez-en maintenant !
Créons à présent une matrice où les fonctionnalités les plus souhaitables et réalisables sont placées dans le coin supérieur gauche et les plus difficilement réalisables et/ou les moins nécessaires sont dans le coin inférieur droit. Si vous vous déplacez d'un coin à l'autre, vous verrez les fonctionnalités probables de la feuille de route. Rappelant ce qui a été dit avant, nous pourrions imaginer une carte routière plus détaillée :
Firebird 3.0 (la version fusionnée)
- Monitoring
- Annulation asynchrone des statements
- Gestion des users/SQL users
- Plus de fonctions intégrées
- Tables temporaires
- Fonctions SQL
- Requêtes récursives
- Jointures externes plus rapides
- Supporter SMP dans le SuperServer
- Mise en cache de statements compilés
- Fonctions/procédures externes
Comme vous pouvez voir (et comme énoncé plus tôt), on s'attend à ce que la version 3.0 inclue le travail déjà effectué et quelques fonctionnalités qui sont fortement souhaitées et relativement faciles à mettre en application. Le reste tend à ralentir le développement et par conséquent est exclu de la liste ci-dessus.
Firebird 3.0+ (la prochaine version principale)
- Logging/audit détaillé
- Permissions de SQL tracing/profilingUser pour le metadata
- Modules d'authentification pluggable
- Groupes de sécurité
- Type de données numériques long d'origine
- Domaines omniprésents
- Expressions régulières
- BLOB TEXT compatible avec [VAR]CHAR
- Protection logique fiable
- Améliorations d'optimiseur
- Contenu statement/transaction, compatible read-commited
- Protocole de réseau optimisé
- Index bidirectionnels
- Intégrité référentielle sans index
- Le volume load/import
Il serait également intéressant de pouvoir concevoir des schemas/nom avec espaces et plus longs noms de métadata pour 3.0+, mais aucune promesse ne peut être faite dans ce sens, ici. Il en va de même pour les sources de données externes et les contraintes d'intégrité.
Firebird 3.0++ (nous n'avons pas de planning pour l'instant)
- PSQL debugging extentions/hooks
- Cryptage de base de données
- Ajout de chemins d'accès supplémentaire
- Recherche intégrale de texte
- Clustering
- Curseurs bidirectionnels
- Intégration de XML
Naturellement, quelques releases intermédiaires ou mineures peuvent être produites en attendant, car nous essayerons de rendre les cycles de développement plus courts. Bientôt, les détails seront discutés et seront convenus par les administrateurs de projets, vous disposerez d'une feuille de route à court terme réelle et une feuille de route à long terme prévisionnelle sur notre site.
IV. Lien et remerciement▲
Pour de plus ample information : http://firebird.sourceforge.net
Un grand merci à neguib pour son aide à la traduction et la correction orthographique.