Découvrez les bases de données NoSQL: Cas de MongoDB & Elasticsearch

Découvrez les bases de données NoSQL: Cas de MongoDB & Elasticsearch

Comment gérer une énorme base de données et comment l'interroger efficacement ? Ces questions, on se les pose dès que le volume devient ingérable et que répondre à de simples requêtes prend des heures.

Dans cet article, vous découvrirez l'univers du NoSQL. Nous ferons un focus sur deux solutions NoSQL extrêmement populaires : MongoDb et ElasticSearch.

C'est quoi le NoSQL ?

Depuis les années 70, la base de données relationnelle était l'incontournable référence pour gérer les données d'un système d'information. Toutefois, face aux 3V (Volume, Velocity, Variety), le relationnel peut difficilement lutter contre cette vague de données. Le NoSQL s'est naturellement imposé dans ce contexte en proposant une nouvelle façon de gérer les données, sans reposer sur le paradigme relationnel, d'où le "Not Only SQL". Cette approche propose de relâcher certaines contraintes lourdes du relationnel pour favoriser la structure des données, le langage d'interrogation ou la cohérence. Ainsi, le NoSQL est à la fois une autre manière d'interroger les données, mais aussi de les stocker.

Les familles NoSQL

Les besoins de stockage et de manipulation dans le cadre d'une base de données sont variables et dépendent principalement de l'application que vous souhaitez intégrer. Pour cela, différentes familles de bases NoSQL existent : Clé/Valeur, colonnes, documents, graphes. Chacune de ces familles répond à des besoins très spécifiques que nous allons développer par la suite, avec pour but in fine, de vous permettre de choisir votre solution NoSQL.

  1. Les clés-valeurs

Le but de la famille clé-valeur est l'efficacité et la simplicité. Un système clé-valeur agit comme une énorme table de hachage distribuée sur le réseau. Tout repose sur le couple Clé/Valeur. La clé identifie la donnée de manière unique et permet de la gérer. La valeur contient n'importe quel type de données. Exemple: Redis, Memcached, Azure Cosmos DB, SimpleDB.

Aucun texte alternatif pour cette image

2. Les colonnes

Traditionnellement, les données sont représentées en ligne, représentant l'ensemble des attributs. Le stockage orienté colonne change ce paradigme en se focalisant sur chaque attribut et en les distribuant. Il est alors possible de focaliser les requêtes sur une ou plusieurs colonnes, sans avoir à traiter les informations inutiles (les autres colonnes).

Cette solution est très adaptée pour effectuer des traitements sur des colonnes comme les agrégats (comptage, moyennes, co-occurences...). D'une manière plus concrète, elle est adaptée à de gros calculs analytiques. Toutefois, cette solution est beaucoup moins appropriée pour la lecture de données spécifiques comme pour les clés/valeurs. Exemple: BigTable, HBase, Spark SQL, Elasticsearch.

Aucun texte alternatif pour cette image

3. Les documents

Les bases orientées documents ressemblent sans doute le plus à ce que l'on peut faire dans une base de données classique pour des requêtes complexes. Le but de ce stockage est de manipuler des documents contenant des informations avec une structure complexe (types, listes, imbrications). Il repose sur le principe du clé/valeur, mais avec une extension sur les champs qui composent ce document.

L'avantage de cette solution est d'avoir une approche structurée de chaque valeur, formant ainsi un document. De fait, ces solutions proposent des langages d'interrogation riches permettant de faire des manipulations complexes sur chaque attribut du document (et sous-documents) comme dans une base de données traditionnelles, tout en passant à l'échelle dans un contexte distribué. Exemple: MongoDB, CouchBase, DynamoDB, Cassandra.

Aucun texte alternatif pour cette image

NB: Cassandra est souvent considérée comme une solution orientée colonnes. C'est une solution orientée documents appelée "wide-column store", dans le sens où le document est structuré comme en relationnel. La confusion vient du fait que l'on y définit des colonnes et des familles de colonnes dans le schéma, ce qui est différent du stockage de "colonnes".

4. Les graphes

Les trois premières familles NoSQL n'adressent pas le problème de corrélations entre les éléments. Prenons l'exemple d'un réseau social : dans certains cas, il devient très complexe de calculer la distance entre deux personnes non directement connectées. Et c'est ce type d'approche que résolvent les bases orientées Graphe.

Dans la base orientée graphe, les données stockées sont : les nœuds, les liens et des propriétés sur ces nœuds et ces liens. Les requêtes que l'on peut exprimer sont basées sur la gestion de chemins, de propagations, d'agrégations, voire de recommandations. Toutefois, contrairement aux solutions précédentes la distribution des nœuds sur le réseau n'est pas triviale. Exemple: Neo4j, OrientDB, FlockDB.

Aucun texte alternatif pour cette image


Découvrez MongoDB

Aucun texte alternatif pour cette image

MongoDB est une base de données NoSQL orientée documents. MongoDB propose à la fois une version communautaire et une version entreprise de la base de données:

  • MongoDB Community est la source gratuite pour l' édition de MongoDB.
  • MongoDB Enterprise est disponible dans le cadre de l'abonnement MongoDB Enterprise Advanced et inclut une prise en charge complète de votre déploiement MongoDB. MongoDB Enterprise ajoute également des fonctionnalités axées sur l'entreprise telles que la prise en charge LDAP et Kerberos, le chiffrement sur disque et l'audit.

Un enregistrement dans MongoDB est un document, qui est une structure de données composée de paires de champs et de valeurs. Les documents MongoDB sont similaires aux objets JSON. Les valeurs des champs peuvent inclure d'autres documents, tableaux et tableaux de documents.

Collections / Vues / Vues matérialisées à la demande 

MongoDB stocke les documents dans des collections . Les collections sont analogues aux tables des bases de données relationnelles.

En plus des collections, MongoDB prend en charge:

  • Les Vues en lecture seule (à partir de MongoDB 3.4)
  • Les Vues matérialisées à la demande (à partir de MongoDB 4.2).

Caractéristiques clés 

Haute performance 

MongoDB fournit une persistance de données hautes performances. En particulier,

  • La prise en charge des modèles de données intégrés réduit l'activité d'E / S sur le système de base de données.
  • Les index prennent en charge des requêtes plus rapides et peuvent inclure des clés de documents et de tableaux intégrés.

Langage de requête riche  

MongoDB prend en charge un langage de requête riche pour prendre en charge les opérations de lecture et d'écriture (CRUD) ainsi que:

  • Agrégation de données
  • Recherche de texte et requêtes géospatiales .

Haute disponibilité 

La fonction de réplication de MongoDB, appelée jeu de réplicas , fournit:

  • basculement automatique
  • redondance des données.

Un jeu de réplicas est un groupe de serveurs MongoDB qui maintiennent le même jeu de données, fournissant une redondance et augmentant la disponibilité des données.

Évolutivité horizontale 

MongoDB fournit une évolutivité horizontale dans le cadre de ses fonctionnalités de base :

  • Sharding distribue les données sur un cluster de machines.
  • À partir de la version 3.4, MongoDB prend en charge la création de zones de données basées sur la clé de partition . Dans un cluster équilibré, MongoDB dirige les lectures et les écritures couvertes par une zone uniquement vers les fragments à l'intérieur de la zone.

Prise en charge de plusieurs moteurs de stockage 

MongoDB prend en charge plusieurs moteurs de stockage :

  • Moteur de stockage WiredTiger (avec prise en charge du chiffrement au repos )
  • Moteur de stockage en mémoire .

En outre, MongoDB fournit une API de moteur de stockage enfichable qui permet à des tiers de développer des moteurs de stockage pour MongoDB.

Découvrez Elasticsearch

Aucun texte alternatif pour cette image

Elasticsearch est une base de données NoSQL dont la particularité est de pouvoir indexer des documents fortement orientés textes. On pourrait le comparer à un moteur de recherche, mais que vous pourriez paramétrer pour qu’il colle exactement à vos besoins de recherche. Elasticsearch, c’est donc un moteur de recherche capable de stocker une grande quantité de documents et que l’on peut interroger en temps réel. De plus, son langage de requête apporte des possibilités d’interrogation intéressantes que l’on pourra exploiter pour extraire des statistiques en temps réel.

Le moteur de recherche Lucene

Les moteurs de recherche reposent sur le domaine de la "Recherche d’information" principalement utilisé dans les moteurs de recherche tels que GoogleBingYahoo!DuckDuckGoQwant… Parmi eux, nous pouvons trouver le moteur de recherche Lucene, un logiciel OpenSource Apache présent dans de nombreux site web pour créer des moteurs de recherche dédiés. L’avantage est de pouvoir le paramétrer et de jouer avec le nombreuses fonctionnalités du moteur. Mais ce qui est encore plus intéressant est de savoir qu’Elasticsearch utilise Lucene pour ses requêtes.

Aucun texte alternatif pour cette image

Le principe est assez simple : tous les mots d’un texte ont leur importance et on peut effectuer des recherches sur ces mots. Mais cela ne repose pas simplement sur le fait que le mot est présent dans un document pour qu’il réponde ; il faut être capable de déterminer sa pertinence, sinon comment ferions-nous pour trouver celui qui nous intéresse le plus ?

Pour cela, nous allons utiliser la fréquence des mots dans le document (de quoi on parle dans ce document), la fréquence des mots dans l’ensemble des documents (est-ce que ce mot est vraiment important), la taille du document (document court vs roman). Au final, on va obtenir pour chaque mot un poids qui va nous servir pour établir un score pour chaque requête avec un modèle mathématique reposant sur des vecteurs et la fonction cosinus.

Elasticsearch : un moteur de texte distribué

Pour fonctionner, Elasticsearch aura donc besoin de savoir quels mots sont employés dans chaque document. Pour cela, Elasticsearch intègre un moteur Lucene qui va s’occuper d’extraire les mots d’une collection de documents et de préparer des colonnes de mots. Car en effet, elasticsearch est une base de données NoSQL orientée colonnes : un mot = une colonne de documents avec pour valeur le poids du mot dans chacun des documents. La couche de distribution effectuée par Elasticsearch permet de router les requêtes, paralléliser les traitements, répliquer les données en cas de panne et augmenter la capacité d’indexation de Lucene.

Aucun texte alternatif pour cette image

Visualisez et prototypez avec Kibana

Aucun texte alternatif pour cette image

Kibana est un client pour ElasticSearch qui fournit à l'utilisateur une interface graphique (UI) accessible par un navigateur web. Cette UI permet à l'utilisateur de réaliser des recherches, de visualiser des documents individuels et d'agréger des résultats dans des graphes et des diagrammes. 

Conclusion

Le choix d'un moteur de base de données se fait à partir des besoins, et certainement pas à partir d'un a priori technologique. Autant que possible, ce choix doit aussi se baser sur des tests réalisés en interne et prenant en compte les contraintes du business. C'est à la fois un choix décisif, car il est difficile de revenir en arrière lorsque toutes vos données sont gérées dans un système, mais c'est aussi un choix qui n'est pas forcément fatal, car il est possible d'adapter son traitement, jusqu'à un certain point, au moteur choisi.

Les axes de choix comportent les fonctionnalités, les performances et la solidité du produit. Il est par exemple possible de faire le choix, pour un système de production, d'un moteur NoSQL encore jeune, mais il faut alors pouvoir contourner les problèmes rencontrés lors de l'utilisation. Nous pensons notamment à des outils, comme Couchbase Server, dont nous n'avons pas parlé dans cet article, parce qu'ils sont trop jeunes, mais qui sont parfois mis en production dans des entreprises qui essuient les plâtres.

Donc, votre choix devra se faire selon les axes que nous avons indiqués dans cet article, mais aussi après des tests aussi sérieux que possible pour vous assurer que le moteur réponde à vos besoins, et qu'il est capable de tenir la charge solidement, comme vous le souhaitez. Souvenez-vous en plus d'une chose : dans le monde NoSQL, un moteur correspond souvent à une application cliente, vous pouvez donc tout à fait mettre en place plusieurs solutions de gestion de données selon vos besoins, et établir des fertilisations croisées entre les SGBDR, les moteurs NoSQL et des outils comme ElasticSearch pour ajouter les fonctionnalités voulues.

Identifiez-vous pour afficher ou ajouter un commentaire

Autres pages consultées

Explorer les sujets