Le Big Data exigera des bases de données NoSQL qu’elles repoussent encore leurs limites

Le Big Data sera un des éléments clé de la transformation numérique des entreprises. Le terme recouvre cependant de nombreuses technologies. Parmi celles-ci on trouve les bases de données NoSQL dont la multitude des offres nécessite de comprendre les principes qui régissent leur conception.

life-of-pix-free-stock-photos-light-sky-silo-windows-lillyphotographer

Face au déferlement de données auquel on a assisté ces dernières années, et à la prise de conscience que ces données pouvaient constituées une valeur sans commune mesure pour l’entreprise, une nouvelle vague de bases de données a vu le jour. Un mouvement amorcé en 2009 par les grands acteurs du web qui ont été les premiers à être confrontés à des volumétries inédites de données, structurées et non structurées, et à un nombre vertigineux de requêtes.

Les bases de données NoSQL adressent des enjeux différents de ceux des bases de données relationnelles historiques

Ces bases de données de type NoSQL viennent compléter (et non pas remplacer) les bases de données relationnelles qui se heurtaient à des limites d’évolutivité et de performances dans des environnements de données massives.

Avec la prolifération annoncée des objets connectés qui vont être autant de sources de nouvelles données, la gestion de bases de données massives se posera de manière accrue.

Les solutions de type NoSQL existent en grand nombre aujourd’hui et la difficulté consiste à choisir la base de données NoSQL adaptée à un contexte précis.

Pas réellement de définition précise d’une base de données NoSQL mais des objectifs communs :

Les bases de données NoSQL se différencient du modèle SQL par une logique de représentation de données non relationnelle qui se caractérise en général par :

  • D’importants volumes de données structurées et non structurées
  • Une multitude de requêtes simultanées
  • Une forte évolutivité de type scale out (évolution horizontale par rajout de serveurs)
  • De hautes performances
  • Pas de schéma (schema less) . La base de données n’impose pas de définition des éléments au sein d’un ensemble de données .

Les objectifs étant globalement partagés par l’ensemble des fournisseurs de bases de données NoSQL, comment dès lors faire la différence parmi une offre abondante ?

Les concepteurs de bases de données NoSQL ont du faire des choix d’architecture pour réaliser leurs objectifs. Les caractéristiques et les fonctionnalités d’une base de données NoSQL sont souvent la résultante de compromis et de combinaisons de choix complétés par des développements spécifiques de fonctionnalités.

Choisir une base de données nécessite de comprendre les choix architecturaux qui ont concouru à sa conception

   Le parti pris par les fournisseurs ne préjuge pas de la qualité d’une base de données NoSQL mais il permet de comprendre son positionnement et son adaptation par rapport à des cas d’usage et des conditions d’exploitation. Sans être exhaustif on peut recenser quelques choix d’architectures déterminants

1. Le choix du modèle de données : On trouve quatre modèles qui présentent chacun des intérêts et des limites. Les limites de chaque modèle pouvant être compensées certaines fois par des fonctions additionnelles

      • Clé/Valeur
      • Orienté colonne
      • Documents
      • Graphe

 2. Le mode de répartition des données : Face à une quantité de données importante et à de nombreux accès simultanés, il est nécessaire de répartir les données et les accès sur différents serveurs. Les moyens d’y arriver sont nombreux et on trouvera des systèmes totalement distribués ou de types master/slave. La topologie choisie et les algorithmes pour implémenter la distribution des données auront une incidence sur

  • L’uniformité de la répartition des données et des accès
  • La quantité maximale de données et de requêtes supportées avec le même niveau de performance.
  • Le maintien des performances en cas d’ajout ou de suppression d’une ressource
  • La simplicité de rajout d’une ressource
  • Le maintien des accès en cas de perte d’une ressource

3. La nature de l’algorithme:  Les algorithmes sont utilisés pour mettre en œuvre l’infrastructure distribuée en fonction du modèle de données choisi. Le choix de l’algorithme et son implémentation sont essentiels. Si on a par exemple choisi un modèle de données clé/valeur, pour des raisons de simplicité et de performances, et un système distribué de type pair à pair (peer to peer), pour un équilibrage de charge homogène, on pourra alors s‘appuyer sur un algorithme de type Table de hashage distribuée DHT (Distributed Hash Table) pour la mise en œuvre de la solution.

Dans cet exemple la combinaison « pair à pair » et l’algorithme « DHT » déterminera la qualité de performance, la souplesse d’évolution du cluster et le niveau de disponibilité selon les réplications permises.

4. La programmation:  Rarement mentionnés dans les documentations techniques, les choix de programmation ne sont pas sans conséquence sur les performances et la frugalité (l’usage minimum des ressources) de la base de données.  Plus la programmation sera proche de l’OS (programmation bas niveau), plus les performances seront optimisées et moins la consommation des ressources sera importante. Cela demande cependant une expertise forte et un investissement supérieur en temps de développement

Une maitrise complète des ressources par le code présente l’avantage de pouvoir assurer que certaines fonctions peuvent s’effectuer sans dégrader les performances. Une consommation minimum de ressource mémoire par exemple permet d’optimiser des fonctions de multithread et d’obtenir une scalabilité au sein d’un nœud d’un cluster sans impact sensible sur les performances.

Attention aux effets de seuils: Par définition lorsque l’on s’intéresse aux bases de données NoSQL on arrive dans des domaines extrêmes, ou qui tendront à le devenir dans l’avenir, en termes de nombre de requêtes et en quantité de données. La question est donc de s’assurer que les performances resteront constantes au fur et à mesures de l’augmentation des ressources.  On pourrait imaginer que le problème est résolu par le simple ajout physique de ressources.

Dans la réalité on constate une effet de seuil. Cet effet de seuil, comme son nom l’indique, se déclenche quand un niveau de requête est dépassé. La performance se dégrade alors sans possibilité d’y remédier par l’ajout de ressources matérielles. La manière dont on a implémenté le code de la base de données prend alors toute son importance . Plus l’effort de développement aura porté sur l’optimisation du code en utilisant de la programmation bas niveau, et plus tard l’effet de seuil se fera ressentir.

En fonction de chaque contexte et des prévisions de croissance l’effet de seuil peut être ou non un problème. Des benchmarks permettent de s’assurer que la solution envisagée supportera les charges prévues dans le temps.

Simplicité opérationnelle

Si les notions de scalabilité, de performances et de disponibilité sont particulièrement sensibles dans un contexte de bases de données NoSQl il ne faut pas pour autant négliger le côté opérationnel de la solution

  • Mise en œuvre : simplicité de l’interface utilisateur, utilisation ou non du format de données d’origine, besoin d’interruption lors d’ajout de ressources.
  • Intégration dans un environnement existant : infrastructures et standards du marché supportés

Pas de recette miracle donc mais des questions à se poser qui pourront nécessiter au final quelques tests pour valider que les niveaux de performances et les capacités d’évolution répondent bien aux cas d’usages concernés.

Documentations:

a lire également : Quartet FS et quasardb s’allient pour repousser les limites de l’analyse Big Data

 

2 réflexions sur “Le Big Data exigera des bases de données NoSQL qu’elles repoussent encore leurs limites

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s