Les utilisateurs qui évitent les bases de données relationnelles traditionnelles en faveur de bases de données émergentes NoSQL pourraient être tentés de « jeter le bébé avec l'eau du bain », a averti un pionnier des SGBD devant une assemblée de défenseurs des solutions NoSQL.
Au lieu de cela, la plateforme SQL (Structured Query Language) peut être adoptée pour les nouveaux systèmes avec quelques ajustements techniques, qui lui donneraient toute la flexibilité des systèmes NoSQL, fait valoir Michael Stonebraker, directeur technique chez l'éditeur de la base de données distribuée VoltDB [comme NimbusDB, voir sujet sur Boston IT]. Michael Stonebraker a défendu sa solution, qu'il baptise NewSQL, à l'occasion de la conférence NoSQL Now qui se déroule cette semaine à San Jose, en Californie.
Sa société propose elle-même une base de données basée sur NewSQL, ce qui donne plus de poids à cette nouvelle architecture que le simple discours commercial d'un revendeur. Michael Stonebraker a été l'architecte en chef des bases de données Ingres et Postgres, et a contribué à de nombreux autres SGBD. Il a également cofondé Vertica, un éditeur de base de données en colonnes acheté par Hewlett-Packard en février dernier.
Les bases de données relationnelles SQL sont moribondes font valoir les défenseurs de NoSQL, avance le directeur technique de VoltDB. « Mais ce n'est pas la faute des revendeurs de SGBD non SQL. Traditionnellement appelés les éléphants, ces fournisseurs de bases ne sont pas devenus lents, car ils supportaient SQL », explique le responsable technique.
Des SGBD peu adaptés aux nouveaux usages
La plupart des logiciels commerciaux de type SGBD ont été mis sur le marché il y a une trentaine d'années, rapporte Michael Stonebraker. Ils n'ont pas été conçus pour les environnements automatisés et sont très gourmands en données utilisées aujourd'hui.
En évoluant pour offrir de nouvelles fonctionnalités, ils sont devenus ballonnés. « Oracle ne grandit pas », poursuit-il. « Si vous n'avez pas besoin de performances, ce n'est pas grave. Mais si vous n'avezpas besoin de performances [un système basé sur une base SQL traditionnelle] ne le permettra pas ».
L'atonie des systèmes SGBD est généralement attribuée à un certain nombre de facteurs, poursuit Michael Stonebraker. Ces systèmes maintiennent un espace réservé à la mémoire tampon, conservent les logs à fin de récupération, et gèrent le verrouillage et le déverrouillage des tables afin elles ne soient pas écrasées par une autre opération. Dans un essai réalisé par VoltDB, 96 % des ressources du système étaient consommées par ces opérations. Voici pourquoi beaucoup trouvent dans les SGBD NoSQL, comme MongoDB et Cassandra, une réponse aux limitations des bases de données traditionnelles.
Illustration principale : Michael Stonebraker, directeur technique chez VoltDB; crédit photo : D.R.
NewSQL pour combiner le meilleur de SQL et NoSQL
1
Réaction
Un pionnier des SGBD soutient que le meilleur de SQL et de NoSQL pourrait être combiné dans un nouveau système de base de données.
Newsletter LMI
Recevez notre newsletter comme plus de 50000 abonnés
Commentaire
Suivre toute l'actualité
Newsletter
Recevez notre newsletter comme plus de 50 000 professionnels de l'IT!
Je m'abonne
Certains grands éditeurs de SGBD Relationnels ont déjà largement commencé d'intégrer des technologies NoSQL dans leurs produits traditionnels. Je citerais le cas de Microsoft avec SQL Server qui intègre :
Signaler un abus- Le concept de bases de données « document » (« Full Text Searching ») depuis la version 7 remontant à 1998...
- Le concept de base de données orienté colonne (ColumnStore) introduit avec la version 2012 de SQL Server, de même que le concept du « In Memory ».
- De la même manière SQL Server 2017 a introduit le concept de tables de nœuds et d’arrêtes avec les mêmes fonctionnalités de manipulation de graphes que Neo4j.
- Enfin il est possible de faire des tables de type paires clef/valeurs depuis l’origine des SGBRD, mais ce n’est qu’avec l’arrivée du « In Memory » et du concept de « ColumnStore » que cela est devenu performant...
Enfin, la plupart des SGBD Relationnels n’ont pas attendu les SGBD NoSQL pour introduire le XML ou du JSON...