Big Data : l’analyse de données et le NoSQL pour les nuls
Nous continuons notre tour de table du Big Data avec la démystification de l’article Numeriblog qui présente le NoSQL et de l’analyse de données. La semaine dernière, nous avons fait la même chose avec un […]
Ce que vous allez découvrir
- Qu’est-ce qu’une base de données NoSQL ?
- Le problème du NoSQL pour l’analyse de données
- Définition des termes
Big Data : l’analyse de données et le NoSQL pour les nuls
Nous continuons notre tour de table du Big Data avec la démystification de l’article Numeriblog qui présente le NoSQL et de l’analyse de données. La semaine dernière, nous avons fait la même chose avec un article sur le cloud. À la lecture de l’article , vous vous êtes peut-être sentis quelque peu perdus. NoSQL, analyse de données, Big Data, tant de termes qui peuvent paraître compliqués quand on ne baigne pas dans ce milieu. Avec cet article, vous allez y voir plus clair. Pensez à lire jusqu’au bout, nous donnerons une définition de chaque terme complexe en fin d’article.
Commençons par le point le plus évident : le titre. Le titre de l’article original est le suivant : « Pourquoi les bases de données NoSQL ne sont pas adaptées à l’analyse de données ?”. Il est évident que si on ne comprend pas les termes, la réponse à la question n’a pas une grande utilité.
Qu’est-ce qu’une base de données NoSQL ?
Il existe deux moyens principaux pour stocker des données. Le SQL (Structured Query Language) et le NoSQL (Not only SQL). Le SQL est un langage informatique utilisé pour ranger des données avec un schéma et un ordre précis. Il permet de retrouver les données et de les organiser assez rapidement. Le NoSQL, comme son nom l’indique, permet de stocker des données sans schéma précis, donc de manière aléatoire, plus souple. On dit que le NoSQL est “non relationnel”. Il est à privilégier pour des grandes bases de données (le fameux Big Data).
Pour faire simple, voyez le SQL comme une bibliothèque de livres très organisée. Les livres sont tous rangés sans laisser de place au hasard (ordre alphabétique, par auteur, par thématique, etc). Cette bibliothèque dispose aussi de membres qui ont la possibilité de louer des livres. En fonction de leur âge par exemple, ils n’auront pas accès à la section adulte de la bibliothèque. Aussi, un livre ne peut pas être loué en même temps par deux membres, etc. Cela implique un certain nombre de contraintes de rangement et de location des livres qui disparaissent avec le NoSQL.
En effet, ce langage beaucoup plus récent fonctionne sans contraintes de rangement. Dans ma bibliothèque NoSQL, je peux directement ranger un livre sans me soucier de l’intégrer sur la bonne étagère, d’indiquer un thème, ou de lui attribuer un auteur. En d’autre termes, je le balance dans une pile de livres sans me soucier de les différencier les uns des autres si ce n’est par leur titre (la clé de répartition*). Si un membre de la bibliothèque vient à louer un livre, je vais ajouter un post-it sur le livre en indiquant qu’il est loué et par qui.
L’article de Xavier cherche à démontrer que le NoSQL n’est pas vraiment adapté à l’analyse de données. Pourquoi pense-t-il cela ? Nous allons tenter de vous expliquer pourquoi le plus simplement possible. L’idée n’est pas de faire de vous des experts du Big Data, mais de vous introduire cet univers passionnant.
Le problème du NoSQL pour l’analyse de données
Tout d’abord, il y a une différence entre stocker des données et analyser des données. Il faut bien mettre en évidence que pour le stockage, l’utilité du NoSQL n’est pas remise en cause. C’est d’ailleurs beaucoup plus rapide de stocker un livre en le balançant dans une pile (NoSQL) plutôt que chercher la bonne étagère, puis indiquer le thème, l’auteur, le nombre de pages etc(SQL). De plus, la dénormalisation* dans notre exemple consiste à séparer physiquement notre unique pile de livres en plusieurs plus petites piles de livres. En effet, il est d’autant plus rapide de ranger ses livres dans plusieurs plus petites piles de livres avec une personne en charge par pile (NoSQL) plutôt qu’une seule personne en charge de toute la bibliothèque et de tous les livres (SQL).
Mais lorsque vous voulez analyser toutes vos données, les mettre en relation, tirer des conclusions, c’est là que ça devient compliqué.
Si tous les mois, vous devez réaliser un inventaire de votre bibliothèque, ou réaliser une étude des locations par thématique ou par membre, vous allez très vite vous rendre compte que le type de bibliothèque a une grande importance !
Dans le cas d’une bibliothèque SQL, l’inventaire est très rapide. Les livres sont déjà triés par thématique et par ordre alphabétique. Avant même de démarrer l’analyse, vous avez déjà un grand nombre d’informations. Par exemple, l’étagère du thème sport contient 70 livres, dont 22 ont été loués.
Dans le cas d’une bibliothèque NoSQL vous risquez de vous arracher les cheveux pendant l’inventaire. Vous disposez d’une pile de livres, donc le seul moyen de réaliser l’inventaire est d’analyser chaque livre, de lire et analyser chaque éventuel post-it que vous avez ajouté auparavant.
Cette différence de temps, à l’échelle de l’informatique, est proportionnellement la même. Quand votre bibliothèque contient des milliards de livres, et que vous devez faire un inventaire tous les jours, voire toutes les heures, la différence de temps et donc de coûts sera loin d’être négligeable.
Définition des termes
Le SQL et le NoSQL ont déjà été largement expliqués dans l’article, mais le premier article comporte encore quelques mots techniques.
Clé de répartition : c’est ce qui garantit la répartition des données au sein des différentes machines (dans notre exemple, les livres)
Dénormalisation : C’est le fait de faire en sorte que chaque ligne de la base de données contienne toutes les données.
N’hésitez pas à nous faire part de vos retours sur ces articles de démystification. Quoi qu’il en soit, nous espérons qu’ils vous aident à comprendre cet univers.
- Articles connexes
- Plus de l'auteur