Lors de CloudWorld 2022, Oracle a présenté la prochaine version supportée à long terme (LTR) de sa base de données, Oracle 23c. Outre des fonctionnalités ciblant les développeurs et les data scientists, la nouvelle mouture a déjà des répercussions sur le support d’Oracle 19c.
Disponible en bêta privée, cette version doit permettre – enfin, aux utilisateurs – de manipuler les fonctionnalités développées depuis février 2019. En effet, la précédente version majeure – Oracle 21c, disponible depuis janvier 2021 – a été peu déployée en production par les clients de la firme.
Logiquement, Oracle met donc l’accent sur la sécurité avec l’intégration d’un pare-feu qui doit protéger la base de données contre les injections SQL.
Dans la même veine, deux nouveaux services accompagneront la disponibilité d’Oracle 23c. Database Zero Data Loss Autonomous Recovery Service doit fournir des fonctions de backups automatisés pour les bases de données Oracle Database et Autonomous Database s’exécutant sur OCI. Ce service protégerait les transactions dès leur exécution.
OCI Full Stack Disaster Recovery Service est, comme son nom l’indique, un service de reprise après désastre pour toute la pile technologique qui entoure la base de données, des ressources de calcul et de stockage en passant par le réseau jusqu’aux applications.
« Depuis plus de quarante ans maintenant, nous nous sommes concentrés sur la disponibilité, l’évolutivité, la sécurité, les performances… Les types de capacités sur lesquelles les plus grandes entreprises comptent. Et nous le faisons toujours : c’est un peu notre ADN », avance Jenny Tsai-Smith, Vice-présidente Oracle Database Product Manager chez Oracle.
Cibler les développeurs (et MongoDB)
Oracle insiste toutefois sur quelques ajouts qui, selon lui, dénotent.
« Ce que nous essayons de faire davantage, c’est de cibler les développeurs », rappelle la vice-présidente au MagIT.
« Ce que nous essayons de faire davantage, c'est de cibler les développeurs ».
Jenny Tsai-SmithVice-présidente Oracle Database Product Manager, Oracle
Oracle reconnaît que le modèle relationnel n’est pas le plus facile à manipuler pour les développeurs. Bien qu’il doive assurer intégrité et déduplication des données, il n’est pas totalement adapté aux développeurs, qui doivent manier des données résidant dans plusieurs tables.
Selon Oracle, l’utilisation de frameworks de mapping objet-relationnel oblige à effectuer des allers-retours dans la base de données pour manipuler un seul objet. Aussi, le contrôle de la concurrence n’est pas efficacement géré par défaut. Ces frameworks sont souvent monolingues, ils ne supportent pas efficacement les traitements en lot impliquant de nombreux objets côté application, quand ils ne faussent pas le mappage entre des modules et des microservices.
En ce sens, le fournisseur poursuit ses efforts pour supporter les documents et le type JSON. Avec Oracle 21c, alors que le SGBD supportait déjà depuis années ce type de données, l’éditeur avait introduit un format JSON natif. Oracle avait également présenté une API afin de migrer les données et les applications habituellement stockées et développées avec MongoDB sur la DBaaS Autonomous JSON Database. Bientôt, cette API sera compatible avec les bases de données Oracle sur site.
Avec Oracle 23c, l’éditeur introduit JSON Relational Duality. Selon le fournisseur, il s’agit de combiner « le meilleur des deux mondes » du modèle relationnel et du modèle orienté documents.
« Les développeurs aiment JSON parce qu’ils n’ont pas vraiment à penser au schéma », affirme Jenny Tsai-Smith.
« Les développeurs peuvent commencer à bâtir leurs applications et se concentrer sur les fonctionnalités requises. Ensuite, quand ils persistent les données, ils les mettent dans des documents, essentiellement des collections de paires clé-valeur », poursuit-elle.
Or, ces documents et ces collections peuvent rapidement entraîner une déduplication des données et d’autres difficultés.
« Cela peut fonctionner pendant un moment, mais les développeurs doivent se poser davantage de questions quand ils veulent joindre plusieurs documents pour des besoins analytiques, ou quand leur application se complexifie ».
C’est là que JSON Relational Duality entre en jeu. Il permet de stocker des données JSON dans des tables relationnelles et de fournir une vue JSON nommée Duality View par-dessus ces tables.
Ces vues « duales » peuvent être déclarées à l’aide de la syntaxe GraphQL. Les développeurs continuent d’interagir avec les données comme par le passé en manipulant des documents. Les DBA et les analystes peuvent toujours effectuer des requêtes SQL, même sur les données JSON stockées en colonne, moyennant les bonnes extensions.
Pour Jenny Tsai-Smith, Oracle boucle la boucle débutée avec Oracle 12c1. « Dans cette version, nous avions introduit Data Guide », rappelle-t-elle. « Cela permettait à des DBA de stocker et d’accéder à des données JSON via des tables relationnelles dans Oracle Database. Avec Duality View, nous stockons encore les données au format relationnel, mais nous les rendons visibles sous forme de documents JSON ».
« Avec Duality View, nous stockons encore les données au format relationnel, mais nous les rendons visibles sous forme de documents JSON ».
Jenny Tsai-SmithVice-présidente Oracle Database Product Manager, Oracle
Or les développeurs demeurent plus enclins à s’appuyer sur MongoDB ou PostgreSQL pour construire leurs nouvelles applications. La vice-présidente est au courant de ce phénomène.
« Je sais que dans certains cas il peut être judicieux de commencer par une des bases de données les plus spécialisées. Mais finalement, au fur et à mesure que l’application évolue, que les entreprises se développent, elles ont besoin de plus », vante Jenny Tsai-Smith. « Et c’est là qu’elles se retrouvent à chercher une autre base de données qui pourrait répondre à certaines exigences supplémentaires ».
Et à la responsable de citer les sempiternels benchmarks censés démontrer la supériorité de sa base de données face aux concurrents.
Exécuter des modèles graphes à même les tables relationnelles
C’est avec les mêmes arguments qu’Oracle veut se poser en alternative à Neo4J ou TigerGraph.
Plus précisément, Oracle 23c doit renforcer le support des usages orientés graphes. Là encore, la prise en charge de cette technologie n’est pas une nouveauté chez le fournisseur.
« Auparavant, nous allouions de la mémoire à un environnement pour concevoir les modèles orientés graphes distincts, puis nous ramenions les résultats dans la base de données », explique Jenny Tsai-Smith.
Avec 23c, les utilisateurs peuvent désormais construire des modèles graphes au-dessus des tables de la base de données existantes.
Cela permettrait de réaliser des analyses en temps réel à l’aide de graphes de propriétés sur des données opérationnelles. « Nous pensons que c’est un avantage, parce qu’avec Neo4J vous devez ingérer les données, construire les graphes, puis réaliser les analyses », assure la vice-présidente. Les cas d’usage sont bien connus : cela permettrait la détection de fraude en temps réel, par exemple.
Jusqu’alors, Oracle supportait le langage PGQL (Property Graph Query Language) pour interroger ces graphes. Depuis, l’éditeur participe activement au développement du standard SQL/PGQ. Cette norme ISO « spécifie comment définir des vues graphiques sur un schéma tabulaire SQL et comment exécuter des requêtes en lecture seule sur ces vues ». Bref, une description au mot près de la nouvelle fonction graphe de cette mouture 23c.
Le fournisseur a quelques autres fonctionnalités dans sa besace, dont les procédures stockées JavaScript, le traitement automatisé des transactions distribuées en provenance des microservices, la gestion des plans d’exécutions SQL en temps réel, et d’extractions de données statistiques grâce à l’IA pour optimiser les requêtes SQL. Cette 23c introduit également la possibilité d’exécuter des applications Apache Kafka par-dessus Oracle Database, ou encore un mécanisme natif de répartition des shards de base de données. Sans oublier de mentionner les améliorations apportées aux solutions connexes aux SGBD, dont Autonomous DataWarehouse, GoldenGate, Tuxedo 22c, ou encore APEX 22.2.
Selon Jenny Tsai-Smith, Oracle 23c devrait être lancée en disponibilité générale au cours du deuxième semestre 2023. Cette version Long Term Release sera maintenue cinq ans dans le cadre du « Premier Support », puis trois années supplémentaires dans le cadre du support étendu, avant la mise en route du support « indéfini ».
Une sortie trop rapprochée ?
Même si Oracle mise sur les nouveaux usages de son SGBD – les méthodes de développement, l’analytique et l’IA en temps réel – pour les membres de l’AUFO et du Club JD Edwards, deux associations utilisateurs francophones des solutions d’Oracle, « il ne semble pas qu’Oracle ait l’intention de ne plus investir dans la voie traditionnelle ».
En outre, il est peu probable que les grandes organisations migrent directement vers Oracle 23c. La version 19c demeure dans la fenêtre du Premier Support jusqu’en 2024 (les trois derniers patchs en date ont été publiés le 19 avril, le 19 juillet et le 18 octobre 2022), avant d’entrer en support étendu jusqu’en 2027.
Conscient de la proximité de la disponibilité de la 23c avec la fin de la première phase du support, Oracle a annoncé l’exonération des frais liés à la première année du support étendu d’Oracle 19c, selon Jenny Tsai-Smith.
« Ainsi, les clients qui auraient besoin d’un peu plus de temps pour passer à 23c auront deux ans de chevauchement entre le moment où ils devront commencer à payer le support étendu pour 19c », assure la vice-présidente.
Cette décision s’explique aisément : une des versions intermédiaires de la base de données n’a pas été lancée à cause de la pandémie de COVID-19.
L’effort de migration en vaut-il la chandelle ? Oracle assure que oui, mais les difficultés inhérentes aux migrations freinent les clients qui peuvent aussi se dire que les coûts de migration et d’adaptation des applications ne justifient pas le changement.
Selon Jenny Tsai-Smith, si plus de 50 % des bases de données supportées reposent sur Oracle 19c, certains clients continuent d’utiliser les moutures 12c, 10g, voire 9i parce que les SGBD demeurent opérationnels.
« Le support étendu est cher, car nous voulons que les clients passent d’une version de la base de données à la suivante ».
Jenny Tsai-SmithVice-présidente Oracle Database Product Manager, Oracle
« Le support étendu est cher, car nous voulons que les clients passent d’une version de la base de données à la suivante », lance-t-elle. « Mais nous avons conscience que cela prend du temps. Nous avons des clients qui ont des dizaines de milliers de bases de données Oracle ».
Les migrations progressives vers les services DBaaS d’Oracle ou vers les distributions hybrides et multicloud d’Autonomous Database pourraient apaiser des discussions potentiellement houleuses entre Oracle et certains de ses clients, puisqu’ils impliquent un changement de modèle tarifaire. Plusieurs centaines de clients auraient déjà choisi Autonomous Database, dont Generali, Nec, Sky ou encore Xerox. C’est en tout cas la trajectoire choisie par la firme de Larry Ellison. « Nous voulons offrir du choix aux clients », ont assuré plusieurs porte-parole auprès du MagIT.
