Après des décennies de règne, les bases de données relationnelles et le langage SQL sont tancées par un nouveau mouvement : le NoSQL, porté notamment par MongoDB, Cassandra ou encore ElasticSearch. Qu’appelle-t-on NoSQL ? Quelle différence avec les bases de données traditionnelles ? Est-ce adapter pour votre activité ? VeryFrog vous éclaire sur ce phénomène qui révolutionne le Web et le Cloud.

Les bases de données relationnelles

Les bases de données relationnelles (parfois nommées bases de données SQL) sont des programmes informatiques dédiés aux stockage et au requêtages de données ayant des relations entre elles. Par exemple, si vous menez une activité de ventes, vous avez des clients, des commandes et des produits. Ces entités sont liées entre elles comme suit : les clients effectuent des commandes qui contiennent des produits. Une base SQL va alors stocker ces entités dans des tables et maintenir des relations entre ces dernières.

Grâce à cela, les bases relationnelles sont idéales pour fournir des données consistantes. Ces liens entre les données permettent également de requêter les bases de manière structurée et efficace. Mais cela vient à un certain prix: les relations entres les données sont compliquées à mettre à l’échelle. Aussi, maintenir la consistance des données, notamment face à des volumes importants, est gourmand en ressources.

Les prémices du NoSQL : la mise à l’échelle horizontale

Face à ces contraintes, la mise à l’échelle des bases SQL passe la plupart du temps par une stratégie scale-up : on augmente les ressources des serveurs (CPU, mémoire, capacité et vitesse des disques). On parle aussi de mise à l’échelle verticale. En prenant une analogie du bâtiment, cela revient à rajouter des étages à un immeuble pour loger plus de personnes.

Bien que cette stratégie fonctionne pour la plupart des entreprises, elle montre ces limites pour les activités manipulant de gros volumes de données. Il convient alors d’utiliser une autre stratégie : le scale-out ou mise à l’échelle verticale. Pour reprendre l’analogie précédente, cette approche revient à construire plusieurs petits immeubles pour loger notre population. Cependant, cette approche fonctionne mal avec les bases traditionnelles. En effet, les relations entre les tables sont complexes à maintenir si on distribue la base sur une multitude de serveurs. Arrive alors le mouvement NoSQL.

Les bases NoSQL

On le voit, le principe de “relations” empêche la montée en charge des bases traditionnelles. De ce fait, de nouvelles bases sont apparues en supprimant purement et simplement la notion de relation entre les données. Ce sont les fameuses bases NoSQL. Plutôt que d’utiliser des tables avec des colonnes, elles stockent les données sous forme de clé/valeur.

Par exemple, un produit peut avoir comme clé son numéro de série et comme valeur son nom. Cela peut paraître restrictif comparé à une table qui contiendrait la nom, le prix, la quantité du produit. En réalité, la valeur d’une clé peut être autre chose qu’une seule données. Cela peut être un objet JSON qui contiendrait toutes les informations de notre produit.

Comment ces bases se mettent à l’échelle ?

Grâce à cette organisation de la donnée, on peut partitionner facilement la base. L’idée est de découper l’ensemble des clés en sous ensembles. Par exemple, si je stocke le dictionnaire de la langue française dans une base NoSQL, je peux choisir d’avoir les mots comme clé et leur définition comme valeur. Je peux alors découper mon ensemble de clé en 26 ensembles, selon la première lettres des mots. Je peux alors distribuer mes 26 ensembles sur autant de serveurs. Ainsi, en comparaison avec une base SQL, on obtient une base possédant 26 fois plus de stockage, de bande passante et pouvant traiter 26 fois plus de requêtes !

Aussi, le fait de ne pas avoir à maintenir de relations permet aux bases NoSQL de se répliquer facilement. Ainsi, une base NoSQL peut facilement avoir plusieurs réplicas. La stratégie habituelle est d’avoir un seul serveur qui reçoit les modifications puis qui les transmets aux autres serveurs. Ces derniers agissent alors comme des miroirs en lecture seule. Ce mécanisme de réplications participe lui aussi à la mise à l’échelle horizontale. En effet, les réplicas peuvent répondre à toute les requêtes en lecture. On peut même coupler le partitionnement des données avec cette réplication. Ainsi, en reprenant l’exemple du dictionnaire, je peux répliquer mes partitions sur 3 serveurs chacune et obtenir ainsi une base de dictionnaire distribuée sur 78 serveurs !

Les limites des base NoSQL

Bien entendu, les bases NoSQL ne sont pas des outils magiques pouvant remplacer les bases traditionnelles dans tous les cas. Tout d’abord, comme il n’y a pas de relation entre les données, le requêtage des données est plus limité. En effet, on ne peut retrouver des données dans une bases NoSQL qu’à travers la fameuses clé de l’entité “clé/valeur”. Si on reprend notre exemple des produits, il est facile de retrouver tous les produits de la base selon leur numéro de série. En revanche, retrouver tous les produits dont le prix est supérieur à 100€ sera beaucoup plus compliqué – et donc gourmand en ressources. Alors que sur ce point, les bases SQL excellent du fait des relations entre les entités et leur mise en forme tabulaire.

Autre point, les bases NoSQL sont soumises au théorème CAP. Ce dernier stipule qu’un système distribué ne peut garantir en même temps:

• Consistency (Cohérence des données) : toutes les entités possèdent les même données
• Availibility (Disponibilité des données) : toutes les requêtes auront une réponse
• Partition (Partionnement du réseau de serveurs) : en cas de coupure entre les serveurs, ceux-ci doivent continuer de fonctionner en autonomie

La majeure partie des bases SQL sacrifie la cohérence des données au profit de la disponibilité et du partitionnement. Cela signifie que lorsque vous faîtes une requête sur un serveur, vous n’avez aucune garantie que la valeurs retournée soit effectivement celle à jour. Cette particularité vient principalement du mécanisme de réplication vu précédemment, qui n’est pas synchrone chez les bases NoSQL. On comprend aisément que pour implémenter un service de comptabilité, les bases NoSQL ne sont probablement pas le choix idéal.

On le voit, les bases NoSQL sont idéales si votre activité nécessite soit de gros volumes soit une haute disponibilité (ou les 2 !). Cependant, leur absence de relation et leur cohérence éventuelle doivent vous pousser à mener une réflexion sur les données que vous y stockerez. N’hésitez pas à nous contacter pour vous aider dans cette réflexion et mener à bien vos projets Big Data.