Bichon, mon beau petit bichon, dis moi qui est le plus beau, le plus fort, … NoSQL ou SQL ?

NoSQL, les origines ?

Initialement les bases noSQL ont été inventées pour répondre à une problématique de scalabilité horizontale, c’est à dire avoir une base de données répliquées dans un cluster de serveurs.

Les bases de données relationnelles (que l’on interroge avec SQL) ont été pensée uniquement pour une scalabilité verticale, ajout de ressources telles que mémoire RAM, disque, CPU. Lorsque sont apparus ces dernières années des appli telles que facebook, google, et autres grosses application manipulant des volumes importants de données, le besoin de scalabilité horizontale est devenu nécessaire pour 2 raisons :

  • maintenir des performances linéaires (on rajoute des serveurs de même configuration et on réparti les charges, tandis que dans la scalabilité verticale on rajoute des ressources au seul serveur qui devient donc plus performant d’un seul coup, et sa performance varie en fonction de la charge qu’il reçoit)
  • géolocaliser les données : on peut ainsi s’assurer que les utilisateur américains de facebook se connectent uniquement à des serveurs américains, les utilisateurs français à des serveurs français, les utilisateurs belges à des serveurs belges, et ceci en garantissant une réplication des données entre tous les serveurs

Des solutions de scalabilité horizontale sont alors apparues pour les systèmes de gestion de BDD relationnelles (SGBDR) telles que MySQL.

MySQL peut faire de la réplication de données et de la géolocalisation mais cela est plus lourd à mettre en place, et nettement moins performant.

Nettement moins performant et beaucoup plus compliqué dans le cas de requêtes en lectures et écritures, mais lorsqu’il s’agit de faire uniquement de la lecture c’est peut être aussi performant (lors de l’écriture MySQL verrouille la ligne de la table ou la table entière selon la configuration. Donc ça diminue un peu les temps de réponses, c’est bien mieux géré dans le cas des bases NoSQL).

Il est donc nettement très fortement conseillé de miser sur NoSQL lorsque l’on manipule de très gros volumes de données nécessitant une scalabilité horizontale.

Pour résumer, l’apport majeur des bases NoSQL et leur but initial, est d’améliorer les temps de réponses pour les applications “internationales” et gérant de gros volumes de données.

Avantages et Inconvénients de NoSQL

Avantages

  • hautement scallable (très bonne scallabilité horizontale à la différence des SGBDR) : réplication des données sur plusieurs serveurs (clusters),
  • géolocalisation des données facilitée,
  • pas de jointures ⇒ 20 fois plus rapide
  • schéma moins strict, on peut facilement le faire évoluer en fonction des changements des fonctionnalités métiers
  • moins coûteux en serveurs dans le cas de millions d’utilisateurs (car plus performant et mieux adapté au clustering, donc moins de serveurs, moins de puissance nécessaire et moins de configuration serveur)

Inconvénients

  • demande une montée en compétences pour un développeur habitué aux bases de données relationnelles classiques
  • 20% de fonctionnalités en moins que les bdd relationnelles qui sont donc à gérer par le développeur : par exemple consistence et intégrité des données
  • les requêtes complexe SQL peuvent être beaucoup plus difficile à écrire en NoSQL
  • difficultés à choisir la bonne base NoSQL, NoSQL basé document (MongoDB, CouchDB) vs NoSQL type Graph (Neo4j) vs …
  • un type de base NoSQL ne convient pas forcément à toutes les parties d’une application

NoSQL : adapté ou non à mon projet ?

D’une manière générale les bases NoSQL ne sont pas adaptées à toutes les applications, par exemple un article à ce sujet concernant une base noSQL de type document (MongoDB) http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

On peut y lire qu’une équipe de développeurs avait lancé Diaspora un concurrent de facebook mais avec le volume de données croissant MongoDB s’est avéré inefficace car mal adapté dans leur cas.

Globalement, pour répondre de manière optimale à toutes les contraintes d’une applications (temps de réponse, structuration des données (hiérarchisation), différents types de données, …), l’idéal c’est d’utiliser plusieurs technologies comme le fait facebook https://www.gangboard.com/blog/what-database-does-facebook-use/ (“What database does Facebook use 2019?”) avec MySQL, puis Cassandra (base noSQL utilisée uniquement pour la recherche dans la messagerie de Facebook, permettant de gérer de très gros volume de données), Hbase (SGBD non relationnelle distribué), s’ajoute à cela différents outils pour augmenter les performances memcached, haysatack, scribe, varnish, hip hop.

Quelques questions que vous devez vous poser :

  • ai-je déjà une expertise dans ma société ? si non, alors il faut savoir qu’il sera difficile de faire le bon choix de base NoSQL (quelle est la mieux adaptée à mon application ou bien à une partie de mon application), et il y aura des erreurs de débutant à écumer, …
  • suis-je prêt à payer le coût d’entrée dans la technologie pour ce projet ?
  • est-ce que l’application développée hébergera un jour un très gros volume de données justifiant la mise en place de cette technologie ?
  • les données que je vais traiter permettent-elles d’utiliser cette technologie sur tout ou partie de l’application ?

Partager sur les réseaux