jeu, 27/03/2014 - 14:53
Historiquement, les bases de données NoSQL ont été limitées à des rôles de niche, pour de grands acteurs d’Internet, afin de répondre à des problèmes tels que l’accroissement rapide des volumes de données. Désormais, elles constituent de plus en plus un standard pour la gestion de vastes volumes de données dans les entreprises. Mais bien qu’il soit aujourd’hui entré dans le langage courant, le terme même de « base de données NoSQL » reste vague et manque de cohérence. Les bases de données NoSQL et les concepts NoSQL dans leur ensemble peuvent autant compléter le modèle relationnel que le remplacer.
En 2010, le besoin croissant pour des ordinateurs plus puissants que ceux des années précédentes a conduit au développement des technologies NoSQL. Souvenez-vous : à l’époque, Google devait faire face à un problème de taille, à savoir l’ajout de 100 Go de données d’indexation à sa base de données, quotidiennement. Aucune technologie ne le permettait. Facebook était déjà très populaire et devait pour sa part traiter plus de 13 millions de requêtes par seconde. Les bases de données relationnelles existant alors ne pouvaient gérer plus de 500 000 transactions par seconde. C’est pour cette raison que Facebook a associé différentes bases de données, mais pour seulement atteindre environ un dixième de la capacité requise. Ce qui a souligné le besoin pour des bases de données plus performantes et a vu la naissance de la première base de données NoSQL, Cassandra.
Quatre ans plus tard, en 2014, nous observons des tendances telles que la mobilité et le Cloud computing, qui renforcent les besoins en élasticité et en puissance de calcul. Deux tendances qui montrent les limites et les faiblesses des bases de données relationnelles. Et à celles-ci s’ajoute le Big Data qui transforme également le marché. Le problème n’est pas toujours lié aux volumes de données traitées. Souvent, le défi est lié aux natures différentes des données et à la manière de les traiter : cela concerne les données structurées, non structurées, semi-structurées, et polymorphes. En principe, toutes les applications s’alimentent de données. Pour certaines, toutefois, le modèle de données sous-jacent est déterminant. Par exemple, si un site Web doit être optimisé à la volée, les données doivent pouvoir être changées en seulement quelques clics. Et c’est là que les technologies NoSQL révèlent toute leur puissance.
Qui plus est, le développement agile gagne en importance. Afin de changer une application à moyen terme, les bases de données NoSQL fonctionnent à partir d’un schéma dynamique. Ce qui permet d’accompagner des développeurs qui, lorsque démarre un projet, ne savent pas forcément quelles sources de données seront pertinentes à moyen terme et ce à quoi les applications vont exactement ressembler. Avec un schéma relationnel, rigide, tout est largement prédéterminé. Malheureusement, il n’est pas simple de prévoir tous les changements possibles et d’en tenir compte à l’avance. À l’inverse, le monde NoSQL rend simple l’implémentation de changements.
En outre, les données que nous traitons changent. Forrester parle de l’éloignement du modèle longtemps dominant de « système d’enregistrements ». ERP, bases de données, et infrastructures de centre de calcul où de vastes volumes de données et de transactions sont gérés efficacement, sont majoritairement développés autour du modèle relationnel et répondent bien aux besoins de ce système. Mais l’attention se déplace vers des « systèmes d’engagement » qui portent plus sur l’interaction et la collaboration entre personnes. Souvent, ces systèmes s’appuient sur les technologies NoSQL. Et le développement d’applications change également. Et sur les systèmes d’échange, la rapidité de provisionnement et d’itération est importante. Les développeurs s’attachent ainsi particulièrement aux solutions qui permettent au code applicatif d’être plus rapide et plus facilement mis à disposition.
SQL n’est pas mort, mais NoSQL va devenir le standard de fait
Il ne fait aucun doute que les bases de données relationnelles offrent un vaste éventail d’avantages. Elles embarquent plus de fonctionnalités que les bases de données NoSQL les plus populaires. Toutefois, les bases de données relationnelles ont beaucoup de peine à rivaliser avec les performances des bases de données key/value, ou en colonnes, ou encore celles de documents, et en encore en graph. Les bases de données orientées documents disposent d’environ 80 % des fonctionnalités de celles du modèle relationnel, mais sans jointures ni transactions complexes. Ce qui leur permet d’offrir une plus grande élasticité et de garantir des performances inégalées pour un coût total de possession réduit.
Les projets Web basés sur un traitement opératoire de données en ligne sont parfaits pour les technologies NoSQL et constituent généralement le premier sous-projet NoSQL des entreprises. Avec l’expérience acquise, c’est le point de départ pour l’extension de l’usage de ces technologies et pour en faire le standard pour toutes les applications. Bien sûr, dans certains cas, les bases de données NoSQL ne constituent pas le choix idéal et les technologies relationnelles conservent là toute leur place. Mais les bases de données relationnelles ne sont pas parfaites dans tous les cas pour les applications modernes.
Pour 80 % des applications existantes aujourd’hui dans le monde, une base de données orientée documents telle que MongoDB est tout indiquée. Et cette part va continuer de croître alors que la demande progresse en faveur de solutions qui lient terminaux mobiles et technologies de réseau social, ainsi que celle en faveur de solutions analytiques modernes, le tout sur fond d’extension de l’emprise du Cloud computing. A l’avenir, les technologies NoSQL s’avéreront plus appropriées à la plupart des applications que les bases de données relationnelles. C’est le fruit d’une productivité accrue dans le développement, d’un délai de mise en production réduit, d’économies sur le coût total de possession, ainsi que d’une mise en œuvre plus simple. NoSQL va s’imposer naturellement comme le standard de fait.
A propos de l'auteur