SQL vs NoSQL

Les bases de données évoluent chaque jour

Historique

Inventés dans les années 1960, les bases de données ne datent pas d'hier.

Initialement, l'informations était séparée en deux niveaux hiérarchique : les informations identiques sur plusieurs enregistrements et un niveau étendu pour une hiérarchie en arbre.

Au tout début, nous avons commencé le stockage d'informations sous forme de fichiers pour tendre vers un model relationnel. Cela s'explique par la densité des informations à relier entre elles, le modèle sql qui permettait l'indexation et l'optimisation de performance, mais surtout appuyé par le fait que la vitesse de transfert disque -> mémoire était plafonné à des débits assez lent.

Quid d'une base documents aujourd'hui

L'avènement des SSD, permettant des débit d'entrée/sortie énormes, la baisse des coûts de mémoire RAM et l'augmentation des débits de BUS mémoire permet aisément de repasser sur des modèles documents sans avoir de perte significative de performances jusqu'à un certain volume de donnée.

Une technologie controversée

Les frustrés des bases documents sont souvent des gens qui l'ont connu il y a très longtemps et sont facinés par le passage au SQL qui a été une évolution majeure à cette époque. Soit, il s'agit d'un public qui a fait le choix d'une base document pour de mauvaises raisons. Mais dans tous les cas, il n'y a aucune base mieux que l'autre dans l'absolu ! Tout dépend de ce que vous souhaitez faire.

Pourquoi faire le choix d'une base documents ?

Depuis que l'information vaut son pesant d'or, il convient de stocker tout ce qui pourrait de près ou de loin se monnayer. C'est une triste réalité contre laquelle la CNIL mène un combat sans relache pour protéger les consommateurs. Cependant, imaginez un instant travailler avec une base sql, lorsque chaque information peu devenir importante dans le futur, il convient de stocker tout ce que l'on peut, à partir du moment ou nous avons connaissance de ce besoin. C'est le principe même du big data, c'est à dire tout stocker afin d'avoir une base de connaissance dans laquelle piocher à tout moment.

Par exemple, les réseaux sociaux n'existaient pas il y a 20 ans, aujourd'hui, c'est une information importante pour cibler un consommateur. Nous pouvons donc stocker l'email associé à chaque réseau social dans notre base de données. Mais à la vitesse à laquelle les réseaux se développent, il y aura toujours un nouveau réseau inconnu dans un an. Entre les facebook, puis instagram, puis snapchat, puis tiktok... on le voit bien, c'est sans fin !

Si l'on travaillait en base SQL, il faudra à chaque fois, faire une migration de structure et ajouter la colonne... En base document, niet ! On ajoute ce qu'on veut ajouter à la volée, et c'est parti.

MongoDB pour ne citer que lui, est un parfait exemple de base qui peut grossir à la fois par le nombre d'items sauvegardé mais aussi par item en lui même. Et cela nous donne énormément de souplesse pour faire évoluer les modèles de données.

SQL a dû s'adapter

Face aux transformations du besoin de stockage d'information, SQL a dû aussi s'adapter au format document en intégrant la gestion du JSON (format de donnée imbriqué). Ainsi, il est possible d'ajouter la souplesse du modèle document dans une base SQL. Mais vous imaginez bien que cela n'est pas sans contrepartie. En atteignant une taille critique en volume Octet, vous atteindrez un niveau de ralentissement dû à la quantité des informations à parser (car le champs JSON est aussi indexé pour la recherche).

Mongo aussi évolue

Le bémol pour les bases fichiers c'est qu'au départ le stockage d'items ne permettait pas de modèle relationnel. Le lien entre deux éléments se faisait :

• Soit, en imbriquant directement l'intégralité d'un élément dans un autre (limité à 100 niveau d'imbrications). Ce qui gonfle la taille de l'item, qui reste limité à 16mo (BSON) par défaut sur une base MongoDB, donc limite les possibilités.

• Soit en stockant dans un tableau l'ID unique du document à imbriquer, mais impose l'exécution successive de requêtes afin de récupérer chaque élément.

Aujourd'hui, après plusieurs optimisations, Mongo a accéléré les recherches avec aggregation. Cela permet de processer les résultats côté base de données, afin d'affiner la recherche, pour retirer la charge du serveur de traitement (API, Framework, etc...).

A quel moment passer de l'un à l'autre ? Une base document, que ce soit Mongo, Neo ou encore DynamoDB, est utile lorsque l'on souhaite stocker de la donnée brute à exploiter si besoin. Si on me demandait de faire un wikipédia, je ferai un mix de base document et moteur de recherche (Elaticsearch) car, sur chaque item, on pourra ajouter des clés spécifiques à l'item :

Par exemple :

• pour les animaux et les plantes : l'appellation latine
• pour les plats : un tableau d'ingrédients
• pour la mode (vêtement, chaussures, parfum) : un tableau des dates d'édition, ré-édition

Chaque élément ayant ses spécificités différentes d'un autre élément qui n'est pas de la même "famille".

Je me vois mal faire cela en SQL car on sera rapidement limité par la structure qui se veut commune entre les éléments.

Selon moi, SQL est un choix idéal pour une base qui peut être utilisé pour du calcul ou un maillage relationnel complexe entre les éléments, par exemple :

• des lignes comptables
• un historique d'achat
• un réseau social

Lorsque nous voulons récupérer les amis des amis de mes contacts pour les mettres en suggestion (même si cela est précalculé via une tâche autonome...) SQL est idéal pour le faire. Idem pour faire un calcul côté base de données, des dépenses entre deux périodes sur une table de transaction.

Un système de stockage de données idéal

Comme on peut le voir, les deux modèles ont leur forces et leur faiblesses. Je pense qu'idéalement, il faudrait mixer les deux afin de tirer le meilleur de chacun. Je reste persuadé qu'il y a toujours un cas ou l'un est meilleur que l'autre.

Une base document : pour stocker le plus d'information possible

Une base SQL : pour du calcul ou des relations complexes

Aujourd'hui, nous sommes malheureusement confrontés à d'autres problématiques au niveau de l'infrastructure. Faire le choix de plusieurs technologies, c'est aussi, maintenir les deux, les faire évoluer pour éviter les exploits et toujours maintenir une cohérences entre les échanges inter-bases. Cela est très complexe et demande un minimum de personnes pour y parvenir. Je pense que, dès qu'une équipe est suffisamment grosse pour gérer les deux, il ne faut pas hésiter à le faire. En revanche, à taille humaine, le travail est colossal et promet une lourde charge quotidienne rien qu'au maintient de l'infrastructure.