Qu’est ce que le NoSQL

Avant d’attaquer une série d’articles sur MongoDB, nous allons commencer par une brève présentation du NoSQL (Not Only SQL).

Depuis quelques décennies, les bases de données relationnelle (SGBDR) ont été la solution la plus adaptée pour stocker des données. il a souvent été nécessaire de faire un effort de structuration/modélisation des données pour pouvoir représenter la logiques métier en modèles manipulables dans une base de donnée relationnelle (UML, merise, etc…).

aujourd’hui, Il reste souvent nécessaire de prendre en considération l’évolution des applications sur plusieurs plans:

  • la structuration de l’information
  • les performances attendue ou visée
  • le ration lectures/écritures
  • la scallabilité horisontale
  • les évolutions fonctionnelles
  • la répartition géographique
  • la haute disponibilité et la qualité de service
  • nature des données à stocker : (donnée textuelles, media de type images/video/autre , données larges ? , etc…
  • l’évolution de la volumetrie des données stockées, et à quelle vitesses

Les limites des SGBDR pour répondre à certaines contraintes se font vite sentir quand une application grandit trop vite. Des problèmes peuvent vite apparaitre quand l’application subit beaucoup de changements ou gère des données de structures qui varient beaucoup.

c’est ainsi que les bases de données NoSQL apportent des solution à plusieurs problèmes difficile à implémenter via un SGBDR sans une modélisation complexe et du développement spécifique.

Le mouvement NoSQL est né au début du besoin de manipuler des bases de données géantes et distribuées de sites à fort trafic comme google ou facebook. l’usage du Nosql a ensuite commencé à se généraliser comme alternative possible aux SGBDR pour le web et plusieurs familles de NoSQL ont vu le jours:

  • les bases clé/valeur : memcached, redis, Couchbase (remplaçant de membase, master-master + persistance,compatible memcache ),  Accumulo (développée par la NSA )
  • les bases orientées colones : BigTable (Google), HBase (Apache Hadoop, utilisée par facebook), Cassandra (Apache foundation, développée par facebook), Hypertable ,
  • les bases orientées document : CouchDB, riak, MongoDB (utilisé par github) , ArangoDB, ElasticSearch
  • les bases orientées graph : Neo4j, FlockDB (twitter pour ses social graphs)
  • d’autres NoSQL : les bases hiérarchiques (pour la cartographie par exemple), les bases de données objects (plusieurs SGBDR intègrent aussi de plus en plus le stockage d’objets ou instances d’objets et certains permettent même d’executer des methodes d’objets stockés. voici quelques DB Objets : wakanda , gemstone/S , Objectivity/DB , objectstore … )

Il est important de choisir un NoSQL selon le besoin de l’application à développer, car chaque NoSQL a ses avantages/inconvénients. par exemple redis pourrait être utilisé comme solution très performante, pour stocker des sessions utilisateurs dans le cas d’une architecture web distribuée sur plusieurs serveur d’applications web LAMP load balancés, (ainsi si un serveur apache tombe, la session d’un utilisateur sera récupérée depuis un autre serveur Apache sur le NoSQL redis (qui est très rapide pour du stockage clé/valaur).

les NoSQL étant différents, certaines de leurs fonctionnalités peuvent justifier le choix de l’un plutôt qu’un autre (comme example parlant, certains ne gèrent pas les transactions, (ou pas encore ) ce qui suffit pour les éliminer si les transactions sont une éxigence pour l’application à développer).

d’autre part, certaines de ces bases de donnée peuvent  implémenter des fonctionnalités leur permettant de jouer dans la cours d’une famille différente de NoSQL: par exemple les DB orientés documents sont assez proche des DB orienté graph du fait que les deux permettent d’utiliser des liens vers d’autre document ou nodes.  les DB orientés graph sont mieux optimisé aujourd’hui pour les manipulation de liens de type graphes (entre nodes),alors que MongoDB permet d’utiliser des liens simples ou des DBREF qui permettent, eux, de créer des liens vers un document x dans une collection y et optionnellement dans une db z (on pour ainsi implémenter des liens entre documents) . les nodes des DB orienté graph sont très proches des documents dans les DB orientés document comme MongoDB. chacun a son terrains où il est plus performant, et puissant, simplifiant ainsi un certains nombres de use-cases complexes en relationnel, à chacun de choisir selon ses besoins le NoSQL adéquat .

Pour mes développements personnels, et les articles à venir, je m’orienterai plus vers MongoDB et ArangoDB, pour leurs coté NoSQL généraliste car je pense que la philosophie orientée document est adaptée à la majorité  des besoins et le style de manipulation des donnée se faisant via requêtes sous forme de document codés en JSON (ou “Array-Style” équivalent dans les autres languages )  ce qui est très intuitif. par ailleurs l’administration de mongoDB est très facile (comparée aux casse tête d’optimisation de HBase qui demandent souvent un niveau avancé pour administrer une grappe de serveur. je dirai que HBase est très performant mais impose des tâches d’administration récurentes qui peuvent être problématiques si on ne maitrise pas tous les paramètres (et il est orienté colone). de par ma petite expérience avec MongoDB, il peut être aisément installé sur Hadoop pour tirer les avantages d’une architecture distribuée avancée et d’un Map-Reduce très performant.

parmis les raison qui m’ont poussé à migrer vers le NoSQL, c’est que c’est hautement scallable (MongoDB, par exemple permet d’ajouter des nouveaux serveurs dans un shard sans toucher une ligne de code ni redémarrer une machine). ArangoDb (qui n’est pas encore scallable aujoud’hui), gère les transactions, et sa sécurité est basée sur des acl ( sa syntaxe est semblable à celle de MongoDB). tous deux peuvent être utilisés pour stocker des clé/valeur, des documents, ou des données de type graph.

voilà pour la petite introduction. et comme petit résumé j’ajouterai, que les NoSQL ne sont pas parfait, et il faut savoir quand les utiliser et comment les utiliser (certaines boites mixent les SGBDR et NoSQL pour tirer le meilleur partit de chacun). il ne faut pas oublier que les perfs ne dépendent pas seulement des besoins généraux de l’application web, mais de sa bonne modélisation et surtout des requêtes qui serons les plus utilisées par les utilisateurs du site ou application.
Did you like this? Share it:

Tags :

2 Responses to Qu’est ce que le NoSQL

Open Close