Cela fait plusieurs semaines que rien n’a été posté sur le blog et pourtant, malgré les vacances d’été, je n’en suis pas resté à me tourner les pouces…
Pour tenter de reprendre un peu le flambeau, j’ai décidé de réagir par rapport à cet article :
What NoSQL Store Should I Use? The Right Tool for Your Use Case paru sur dzone qui présente une aide au choix de la technologie noSQL qui convient aux propriétés que l’on recherche par rapport à l’application que l’on développe : le guide visuel de Nathan Hurst.
Le noSQL se fait de plus en plus présent ces derniers temps mais encore peu de personnes osent s’y lancer. Pour notre projet de stage de fin d’étude, nous avons tenté de franchir le cap avec l’approche orientée graphe proposée par neo4j, étant donné qu’une approche basée sur une modélisation relationnelle ne convenait plus pour des raisons de performances. Par exemple, nous avions besoin de connaître tous les numéros de téléphone des amis de mes amis et de la famille de ces derniers. En SQL, la façon d’obtenir ce type d’information fait rapidement appel à plusieurs jointures, qui, sur un grand nombre d’entrées peut nécessiter des temps de requêtes allant jusqu’à plusieurs secondes. L’approche de type graphe nous a permis de diminuer les temps d’invocation de notre API d’un facteur 10 sur certains cas critiques.
L’article dont je parlais plus haut évoque une modélisation de quelques approches noSQL selon ce que l’on cherche à avoir comme propriétés sur la persistance de nos données. Les propriétés sur lesquelles la modélisation s’intéresse sont l’accessibilité (si tous les clients peuvent écrire et lire à n’importe quel moment), la consistance (si chaque client a accès aux mêmes données au même moment) et la persistance partagée (si le fonctionnement su SGBD est supporté sur des partitions physiques différentes). A partir des propriétés recherchées, le modèle propose un certain nombre de technologies basées sur les approches relationnelles, clé-valeur, orienté colonne ou orienté document.
[Article] Un guide visuel pour choisir sa technologie noSQL
Cela fait plusieurs semaines que rien n’a été posté sur le blog et pourtant, malgré les vacances d’été, je n’en suis pas resté à me tourner les pouces…
Pour tenter de reprendre un peu le flambeau, j’ai décidé de réagir par rapport à cet article :
What NoSQL Store Should I Use? The Right Tool for Your Use Case paru sur dzone qui présente une aide au choix de la technologie noSQL qui convient aux propriétés que l’on recherche par rapport à l’application que l’on développe : le guide visuel de Nathan Hurst.
Le noSQL se fait de plus en plus présent ces derniers temps mais encore peu de personnes osent s’y lancer. Pour notre projet de stage de fin d’étude, nous avons tenté de franchir le cap avec l’approche orientée graphe proposée par neo4j, étant donné qu’une approche basée sur une modélisation relationnelle ne convenait plus pour des raisons de performances. Par exemple, nous avions besoin de connaître tous les numéros de téléphone des amis de mes amis et de la famille de ces derniers. En SQL, la façon d’obtenir ce type d’information fait rapidement appel à plusieurs jointures, qui, sur un grand nombre d’entrées peut nécessiter des temps de requêtes allant jusqu’à plusieurs secondes. L’approche de type graphe nous a permis de diminuer les temps d’invocation de notre API d’un facteur 10 sur certains cas critiques.
L’article dont je parlais plus haut évoque une modélisation de quelques approches noSQL selon ce que l’on cherche à avoir comme propriétés sur la persistance de nos données. Les propriétés sur lesquelles la modélisation s’intéresse sont l’accessibilité (si tous les clients peuvent écrire et lire à n’importe quel moment), la consistance (si chaque client a accès aux mêmes données au même moment) et la persistance partagée (si le fonctionnement su SGBD est supporté sur des partitions physiques différentes). A partir des propriétés recherchées, le modèle propose un certain nombre de technologies basées sur les approches relationnelles, clé-valeur, orienté colonne ou orienté document.