Michael Stonebraker a avancé que son propre système VoltDB, qui utilise ces approches NewSQL, exécute des opérations 45 fois plus vite qu'une base de données relationnelle traditionnelle. VoltDB supporte jusqu'à 39 serveurs, et peut traiter jusqu'à 1,6 million de transactions par seconde sur 300 coeurs de processeurs, a-t-il dit. Elle exige également beaucoup moins de serveurs qu'une implémentation de type Hadoop, en réalisant avec 20 noeuds le même travail qui exigerait 1 000 noeuds avec Hadoop.
Alors que le public de la conférence NoSQL Now était composé d'utilisateurs et de développeurs NoSQL, beaucoup semblaient penser que l'analyse de Michael Stonebraker sur SQL avait quelques mérites, même s'ils étaient en désaccord sur des points particuliers. Dwight Merriman, un des fondateurs de la société de publicité en ligne DoubleClick et l'un des créateurs de MongoDB, partageait l'avis de Michael Stonebraker sur SQL au sujet de la faible évolutivité et des performances en retrait. Mais il a soutenu que SQL n'est pas la langue que tout le monde souhaite utiliser dans les années à venir pour analyser et interroger sa base de données.
D'autres langages plus naturelles pour les requêtes
«Je tiens à utiliser quelque chose d'un peu plus proche de la langue naturelle », c'est ainsi que ces applications ont été conçues, précise-t-il. Les procédures basées sur SQL rendent particulièrement difficile le travail avec plusieurs développeurs, a-t-il ajouté.
Michael Stonebraker est confronté à un problème concret, a déclaré le consultant Dan McCreary après la présentation. Les processeurs ne vont pas aller beaucoup plus vite, mais les coeurs vont continuer à se multiplier. Donc, la question de la montée en puissance sur plusieurs processeurs doit être prise en compte, dit-il.
Dan McCreary a également convenu avec Michael Stonebraker que les utilisateurs NoSQL ne partagent pas un langage de requête unifiée, ce qui va ralentir l'adoption de NoSQL. Mais le consultant a suggéré d'autres langages que le SQL comme outil de requêtes, tels que l'XQuery utilisé pour les documents XML.
NewSQL pour combiner le meilleur de SQL et NoSQL
1
Réaction
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...