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.

[[page]]

Dans une autre session qui s'est tenue lors de la conférence NoSQL Now, le consultant Dan McCreary a expliqué que les lacunes présentes dans les bases de données relationnelles ont stimulé le travail des développeurs afin de créer des systèmes NoSQL. Les bases traditionnelles ne sont pas très flexibles, a-t-il dit. Leur architecture de base a été conçue à l'époque des cartes perforées, et reflète une approche rigide dans la modélisation des données. Si un utilisateur a besoin d'ajouter une autre colonne de données, il doit modifier le schéma de base ce qui peut être très délicat à faire. Le processus de modélisation pour créer des tables relationnelles, appelées modélisation entité-relation, ne reflète pas toujours exactement la façon dont les données existent dans le monde réel. « Beaucoup de choses ne rentrent pas bien dans les tables », a-t-il dit. « C'est beaucoup trop restrictif. » 

Un des autres problèmes avec les bases de données SQL, c'est qu'elles ne s'adaptent pas très bien à la répartition de la charge de travail sur plusieurs serveurs, souligne Dan McCreary. Si les données se développent au-delà des capacités de traitement d'un seul serveur, la base doit être fragmentée, ou dispersée, sur plusieurs serveurs, ce qui est également un processus compliqué. En outre, l'exécution de certaines opérations sur plusieurs serveurs, telles que les requêtes sur plusieurs tables, dans lesquelles les données ont été dispersées, peut devenir problématique.

Les limites du NoSQL

Alors que les bases de données NoSQL offrent plus d'évolutivité et plus de flexibilité, elles ont également leurs propres limites, souligne Michael Stonebraker. En n'utilisant pas SQL, les systèmes de base de données NoSQL perdent la capacité de faire des requêtes très structurées avec une certitude mathématique. Reposant sur l'algèbre et le calcul relationnel, SQL propose un modèle mathématique assurant que la requête est structurée de telle sorte qu'elle ramène toutes les données à capturer, même si la requête elle-même est très complexe. 

Autres problèmes: NoSQL ne peut pas fournir d'opérations au niveau ACID (Atomicity, Consistency, Isolation and Durability) un ensemble de métriques largement utilisées pour assurer qu'une base de données réalisant des transactions en ligne restera toujours précise même si le système est interrompu. Assurer la conformité ACID peut être gravé dans les couches basses de l'application, même si l'écriture du code nécessaire à ces opérations « est un travail pire que la mort », a-t-il ajouté. Enfin, chaque base de données NoSQL vient avec son propre langage de requête, rendant difficile la standardisation des interfaces entre les applications. 

En revanche, NewSQL peut fournir la qualité et l'assurance des systèmes SQL, tout en apportant l'évolutivité des systèmes NoSQL, fait valoir le directeur technique de VoltDB. L'approche NewSQL implique l'utilisation d'un certain nombre de nouveaux modèles d'architecture, a-t-il noté. Il élimine par exemple le pool de mémoire tampon qui monopolise excessivement les ressources en exécutant entièrement  la base de données dans la mémoire principale. Il supprime la nécessité du verrouillage en exécutant qu'une seule thread sur le serveur (bien que certains processus puissent être exécutés pour d'autres opérations bloquées). Et les gourmandes opérations de récupération peuvent être éliminées grâce à l'utilisation de serveurs supplémentaires pour réaliser la réplication et la bascule. 

[[page]]

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.