NoSQL vs SQL : Comprendre la différence de performance

Cet article traite de l'avantage concurrentiel des bases NoSQL vis à vis des bases SQL relationnelles.

A ce jour, les bases NoSQL sont principalement utilisées pour répondre à deux besoins :

- Le besoin de scalabilité
La scalabilité d'une base de donnée est sa capacité à s'étendre sur plusieurs serveurs au lieu d'être limitée à un seul. Ainsi, il est théoriquement possible, d'augmenter à l'infini, les capacités de stockage et de traitement de la base en rajoutant des serveurs. De cette façon, les capacités de l'outil augmentent proportionnellement au nombre d'utilisateurs et à la quantité de données à traiter.

- Le besoin de performance
La performance d'une base de donnée consiste à améliorer la vitesse à laquelle la base est en mesure de réagir aux différentes requêtes (sélection, insertion, mise à jour et suppression).

Dans cet article, nous allons traiter du besoin de performance et plus particulièrement, de la performance du point de vue de l'architecture de la donnée.
Autrement dit, par quels moyens techniques et dans quelles conditions une base NoSQL parvient-elle à être plus performante qu'une base SQL ?

Cet article n'entre pas dans les détails techniques. Il est principalement destiné à un public de décideurs ou de développeurs en phase de découverte sur les technologies SQL. Si vous recherchez des informations plus approfondies, je vous conseille l'excellent livre de Martin Fowler.

L'origine de la performance des bases NoSQL

Les bases NoSQL sont toutes pensées, pour répondre de manière efficiente, à un besoin spécifique. Pour atteindre cet objectif, elles agissent sur la structure des données qu'elles manipulent, de façon à optimiser leurs traitements futurs.

Afin de vous imager le moyen par lequel les bases NoSQL parviennent, grâce à leur structure de donnée, à gagner en performance, je vais utiliser l'exemple d'une chocolaterie.

NoSQL et le chocolatier

Le chocolatier vend des dragées rouges, verts et bleus qu'il assemble à la convenance du client. Le client peut librement choisir d'associer trois couleurs différentes, comme choisir trois dragées de la même couleur.

SQL et NoSQL version chocolaterie - SQL side

A chaque fois qu'un client demande un sachet de dragée, le chocolatier le confectionne. Pendant ce temps, les clients patientent.

C'est précisément l'approche des bases de données SQL. Les données sont éparpillées dans différentes tables et doivent être rassemblées à chaque requête. L'architecture de la donnée est définie en fonction de la donnée elle-même. Dans notre cas, trois types de dragées revient à avoir trois conteneurs différents.

Cependant, le chocolatier constate que ses clients demandent très souvent le même assemblage de dragées (1 vert, 1 bleu et 1 rouge), il décide donc de commander à son fournisseur des paquets de dragées déjà prêts.

SQL et NoSQL version chocolaterie - NoSQL side

Le lendemain, il augmente considérablement son rendement puisque ses clients n'ont plus besoin d'attendre la préparation du paquet de dragées. Le paquet est déjà prêt, il ne reste plus qu'à le distribuer. La performance de distribution du paquet est considérablement accrue.

C'est exactement l'approche NoSQL. A la différence du SQL, en NoSQL, l'architecture de la donnée est définie en fonction de la demande finale du client, autrement dit, en fonction de l'usage. En agrégeant à l'avance des données en fonction de l'usage on gagne en performance lors de la lecture de ces données.

Pour autant, la solution de notre chocolatier est loin d'être idéale. En effet, lorsqu'un client lui demande un paquet contenant trois dragées verts, le chocolatier est obligé de déballer trois paquets afin d'en extraire trois dragées de mêmes couleurs qu'il doit ensuite ré-empaqueter. Ainsi, dès lors qu'il sort de son cas habituel, il obtient un temps de préparation supérieur à celui qu'il pouvait avoir avec son ancienne méthode.

Pour le NoSQL, la limite est la même. Vous pouvez agréger votre donnée pour répondre rapidement à une requête spécifique. Mais lorsque l'usage vient à changer, il vous faudra redoubler d'effort pour bâtir votre nouvel agrégat.

Ainsi, tandis que le SQL a des performances acceptables (mais pas idéale) dans toutes les situations, la base NoSQL, elle, est imaginée pour exceller dans la réponse à un besoin spécifique. En dehors de ce besoin de prédilection, elle aura des performances en dessous d'une base SQL.

Quel impact sur la modélisation des données en NoSQL ?

En opposition au design d'une base SQL qui se modélise en respectant systématiquement les mêmes règles : les règles de normalisation de la donnée; Chaque base NoSQL suit ses propres règles lors de la modélisation de la donnée.

La structure d'une donnée de base NoSQL est adaptée pour répondre a un usage. Ainsi, on trouve plusieurs grands types de bases NoSQL : Les bases graphes, documents, clés-valeurs, colonnes et index inversés.

Le design d'un modèle de donnée en NoSQL comporte une complexité supplémentaire car il nécessite de connaître l'usage final de la donnée. Savoir que votre application manipulera des Factures et des Clients n'est plus suffisant. Vous devez désormais savoir de quelle façon ces données seront affichées à l'utilisateur final.

La modélisation des données dans une base NoSQL demande donc une véritable expertise technique en plus d'une connaissance approfondie de l'usage client final.