NoSQL - Hadoop - CouchDb -MongoDb

EDIT: Il faut lire SGBDR à la première proposition

Bonjour,

Est ce que certains d'entre vous utilisent des bases de données NoSQL ?

N'ayant pas encore eu le temps de faire le tour des fonctionnalités de chacune, Quelles sont les différences notables entre Hadoop, CouchDb et MongoDb ?
Modifié par rs459 (08 Jun 2012 - 20:53)

http://fr.wikipedia.org/wiki/NoSQL

http://www.mongodb.org/

http://couchdb.apache.org/

http://hadoop.apache.org/

Un SGBD NoSQL c'est quand même un SGBD, donc le sondage est faux.

a écrit :
Un SGBD NoSQL c'est quand même un SGBD, donc le sondage est faux.

Merci j'ai corrigé comme j'ai pu.

Bon je vais quand même répondre rapidement. SQL (et en particulier MySQL) est capable de gérer plusieurs millions d'enregistrements sans problème. Avec des moteurs comme InnoDB c'est plusieurs millions d'enregistrement avec un forte concurrence (thcat, forum, etc). NoSQL c'est pour des sites de top classe mondiale comme facebook ou Google, pas pour des sites de secondes zone comme ceux qu'on gère tous les jours.

Le choix sgdb traditionnels/Nosql n'est pas vraiment une affaire de taille de site ou de scalabilité mais d'usage.
Un avantage des bases Nosql telles que couch, c'est de ne pas avoir de structure fixe et de pouvoir évoluer facilement. Les données sont structurées de manière moins rigide, sous la forme de 'documents'.
Une autre sb, Redis, permet de stocker facilement et aisément des données sous la forme clef:valeur.
C'est très pratique et efficace comme moteur de cache, ou comme task queue.

La distinction est plus floue qu'il n'y paraît: postgresql comprend un moteur de stockage clef:valeur (hstore), alors qu'elle est clairement catégorisée en db relationelle.

Quant à la scalabilité, toutes ces bases sont utilisées sur des sites volumineux. A partir d'un certain volume/trafic, un seul serveur de db ne suffit plus, il faut faire appel à d'autres solutions/stratégies (sharding etc) (cf ce blog (en))

Le choix d'une techno (node) ne permet pas de scaler magiquement. C'est un peu plus compliqué

paolo a écrit :

[...]
Un avantage des bases Nosql telles que couch, c'est de ne pas avoir de structure fixe et de pouvoir évoluer facilement. Les données sont structurées de manière moins rigide, sous la forme de 'documents' [...]

C'est là ou je vois l'intérêt du système NoSQL, un site de E-commerce par exemple, présentant ces fiches produits en lecture seule (dans la grande majorité des cas). Avec une transactionnelle pour gérer les rollback des transactions, et les accés concurrentiels au stock.
C'est flexible, le master peut répliquer trés vite dans la mesure ou il n'a pas besoin de créer de nouveau champs sur toute la table.

a écrit :
Le choix d'une techno (node) ne permet pas de scaler magiquement. C'est un peu plus compliqué

Oui ca, j'en suis conscient qu'il y a d'autres mécanismes à mettre en place pour garantir la scalabilité et la haute disponibilité (load-balacing, multipathing, sharding, et j'en passe selon les besoins de l'applicatif)

Mon interrogation se porte surtout sur les grandes différences entre ces bases NoSQL. Mon besoin n'est pas défini, il s'agit surtout de me preparer à la transition du tout SQL encore très fréquent, vers des modèles hybrides ou totalement NoSQL.

Par exemple quelle base NoSQL, semble le plus convenir pour un système de partage de session et d'un champs anti-CSRF.

Si Redis est orienté clef:valeur par exemple, ce n'est pas approprié pour un stockage type document par exemple (enfin j'imagine que stocker un objet JSON dans la valeur d'une clef n'est pas des plus optimisé). MongoDb semble plus approprié dans ce cas

Enfin voila, j'aimerais connaitre un peu les subtilités de cet ordre, pour ne pas avoir à me farcir toutes les docs, de toutes les SGBD NoSQL, puis d'en faire un comparatif.
D'ou l'appel à témoin si je puis dire.

Ben va falloir essayer, ça dépend vraiment de ton use-case.
J'ai a peine joué avec, donc pas trop de conseils bien éclairés.

Visiblement avec mongo, il y a régulièrement des utilisateurs qui se plaignent de pertes de données (et d'autres pour les contredire).

Mais avant de mettre ça en prod, assure toi que tu y gagnes vraiment quelque chose.
Faut différencier les technos à la mode du besoin réel.
On peut faire pas mal de choses avec postgres et mysql.

J'étais tombé sur cet article il y a quelques mois quand je me suis intéressé au sujet. Il détaille les caractéristiques techniques et donne des exemples d'usage pour les principales solutions NoSQL :

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

On y remarques que certaines solutions sont plus orienté lecture alors que d'autre favorisent l'écriture (point de vue performances).
Modifié par moust (09 Jun 2012 - 12:14)

À mon avis c'est clairement intéressant de s'intéresser à ces sgbd. Surtout dans un contexte site-web. Des systèmes comme mongoDb, orientés document, correspondent beaucoup plus à ce qu'on souhaite stocker que le SQL. Cependant, le désavantage pour l'instant, c'est qu'il y a beaucoup de systèmes, on ne sait trop lesquels vont survivre, et on trouve moins de compétences. C'est un peu pour cette raison que surtout les "gros" les utilisent pour l'instant.

@Moust

Merci pour l'article de synthèse, effectivement chacune à un usage plus spécifique qu'une autre.

Ca paraît être un choix qui doit s'opérer avec l'admin sys et l'admin hardware, en fonction de l'applicatif naissant ou existant, et bien sur du cas d'utilisation. Avec les benchs qui vont avec, les tests, ca oblige une nouvelle compétences pour l'intégrateur.

Dans le contexte de node, ca parrait vraiment intéressant, je pense que je vais me concocter un cluster et/ou des grappes de test avec des RaspberryPi.

Et Tenter d'apprendre un peu le concept de sharding, de réplication, master/slave pour quelques-une de ces SGBD.

Redis que je ne connaissais pas du tout, que de nom et pour l'avoir vu dans quelque tuto node, qui parrait bien se prêter à un accés en ecriture/lecture rapide, pour du contenu volatile. Un Suppléant pour MemCache dans certaines conditions type Key : Value

MongoDb qui parait être plus adapter pour de la gestion type TREE, et qui dans un contexte node permet de mutualiser, à de multiple point. Tout deux écrits en C++ permettent d'avoir des dev C++, pour booster les perfs des middleware, et de l'autre coté l'aspect BSON permet de mutualisé les compétences en javascript.

Tester la tolérance aux pannes, reste à trouver l'equipement réseau que je vais mettre en tête. Je pourrais tester en virtualisant quelques quelques NetBSD, mais les latences ne sont pas les mêmes, et ne permet pas de tester les cas physiques de panne.

Ca ne m'empêchera pas non plus de tester MysqlCluster , ou d'autres SGBD(R xor T).

Vivement la disponibilité, des raspberryPi , peut être que je ferais mon prochain blog sur ces expérimentations.