I. Revue de Firebird 2.0▲
Il y a quelques 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érieurité à 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 demanderiez 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
multi-générationelle 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é voir même 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 noeuds 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 ennuyants. 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 language.
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ésente son état actuel, c.-à -d. Beta 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▲
A 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 co-existeront 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 developpement 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 exige 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 important) 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'appelerai la "version 3.0+", où le plus 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 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 demanderiez 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és sur la branche de développement
2.0 HEAD avant de fusionner afin de rendre une version 2.1 mineurs 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, 2ème trimestre:
- Sortie Firebird 3.0 Beta
- Division de la 3.0 HEAD pour créer la branche de 3.0+ développements
2006, 3ème trimestre:
- Sortie de la version finale Firebird 3.0
2006, 4ème trimestre:
- Sortie de Firebird 3.0+ Beta
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. Quels sont les fonctionalitées à 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'utilisateur, 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 offerts 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évelopement) et nous avons juste besoin de backport et de tests.
"Implementation" signifie que la fonctionalité a déjà été discuté 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, tuez 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/rejettée (contenant l'information du client), préparer/éxé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 noeud. 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ébuggage 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 le metadata
Protéger tout les metadata avec des classes de sécurité. Mettez en application les permissions au niveau metadata. Ajoutez 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 cryptages 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 metadata. 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érique 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'arithmetique BCD approprié.
priorité = haut
complexité = Recherche - Plus de fonctions intégrées
Les fonctions intégrées Sql-99 (ceux d'importance majeure pour nous) doivent être implémentées d'abord. Puis nous aurons besoin des feedback d'utilisateurs sur d'autres fonctions.
priorité = haut
complexité = Design/Implementation - Tables temporaire/datasets
Permettre les schémas d'objets et/ou datasets temporaires. La conformité Sql-99 est exigée, des extentions sont les bienvenues.
priorité = haut
complexité = Design/Implementation (partiellement fait dans Fyracle) - De plus longs noms de metadata
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/interchangable 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
Mettez 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
Fixez 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 efficace
Implémenter un tri partiel pour accélérer les récupérations limités (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, UDFs, 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 multi-threading 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. Implementer 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ées 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 concurrenciel.
priorité = moyenne
complexité = Recherche - Index bi-directionnels
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 syntax pour l'emploi de différents formats d'entrée (csv, schéma de xml, etc..) pour l'importation.
priorité = moyenne
complexité = Design - Curseurs bi-directionnels
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 suppé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 qu'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 rapide
- Supporter SMP dans le SuperServer
- Mise en cache de statements compilés
- Fonctions/procedures externes
Comme vous pouvez voir (et comme énoncé plus tôt), on s'attend à ce que la version 3.0 inclus le travail déjà effectué et quelques foncitonnalités qui sont fortement souhaitées et relativement facile à 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érique long d'origine
- Domaines omniprésent
- 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 bi-directionnels
- 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 metadata 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égral de texte
- Clustering
- Curseurs bi-directionnels
- Intégration de XML
Naturellement, quelques releases intermédiaires ou mineurs 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.
V. 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.