La feuille de route Firebird

Conférence sur le futur de Firebird par Dimitry Yemanov, membre de la team Firebird Development.
Traduit en Français par yobenzen.

Article lu   fois.

L'auteur

Site personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

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:

  1. fiabilité et sûreté (résolution de bugs, récupération garantie et améliorations de la sécurité)
  2. facilité d'administration et monitoring
  3. compatibilité avec les normes SQL
  4. performance (algorithmes et optimiseurs améliorés)
  5. 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.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Liste de mes articles :
Importation et exportation massives de données sous IB 6.0 / FB 1.5.x
L'avenir de Firebird : La RoadMap 2005-2006



Rubrique InterBase/Firebird (Accueil, FAQ, Tutoriels et Outils)
Rubrique SGBD (Accueil, FAQ, Tutoriels et Outils)
  

Copyright © 2005 yobenzen. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.