CouchDB : la base de données NoSql arrive sur Windows

Je comprends bien que tu ne comprends pas

CouchDB est un concept assez diffèrent des bases de données relationnelles classiques. Ce n'est pas un «*concurrent*» mais simplement un concept diffèrent.

L'idée de base consiste à résoudre la problématique de la gestion de volumes de données importantes dans un environnement pleinement distribué.

Ceci inclut la répartition des calculs et la réplication des données sur N noeuds, problématiques incontournables lorsqu'on est dans un environnement virtualisé/clusterisé/cloudé ou tout simplement lorsqu'on souhaite faire une féderation de données sur plusieurs serveurs.

CouchDB intègre la notion de réplication de données au coeur même du modèle de stockage en proposant un système de révision interne. Cela facilite la réplication, qu'elle soit simple (maitre/esclave) ou bien répartie (fully meshed).

Avec CouchDB tu peux sereinement et facilement construire des clusters de données alors que c'est une vrai galère avec les moteurs traditionnels.

D'ailleurs si les moteurs type MySQL sont performants en stand-alone, leur performances frisent le tragique dès lors qu'on est dans un cas de réplication (même simple) avec un volume important en écriture.

CouchDB a aussi ses «*mauvais côtés*». En effet les bases de données relationnelles reposent sur le fait que les données sont structurées et complexes (relations, règles d’intégrité), alors que CouchDB n'est prévu que pour gérer des données simples ( en fait ce sont des couples clé/valeur, des simples hash-map ).

Donc CouchDB n'est peut-être pas plus performant qu'un moteur relationnel dans certains cas et lorsqu'on utlise des données complèxes (les relations sont impléméntables, mais engendrent un surcroit de temps de calcul), mais lorsqu'on traite des données simples, ou alors qu'on peut se permettre de dupliquer une partie de celles ci, alors ses performances sont vraiement mises en valeurs.

Pour revenir à ton interrogation, «*on veut autre chose*» que les moteurs relationnels quand il s'agit de gérer un énorme volume de données, repartis sur N noeuds, et avec un temps d'accès quasi constant et scalable et qu'on ne dispose pas d'une infrastructure hardware ultra performante ni d'une équipe de DBA avec 10 ans d’expérience dans le clustering .

Par contre «*on veut*» du relationnel quand on fait une «*appi de gestion*» (au sens large), et qu'on est prêt à faire des concessions sur la distribution des traitements et des données.

D'ailleurs, fort heureusement, les deux peuvent cohabiter sans aucun souci

De plus les deux mondes vont aussi évoluer dans les années à venir. Il n'est pas dit que l'arrivée des bases NoSQL ne secouent pas un peu les concepts internes des moteurs classique. Et il est fort probable que les bases NoSQL évoluent aussi pour gérer de manière plus efficace des données complexes, tout en restant distribuables.

Pour ceux que ça intéresse, il y a un livre "on line" qui explique les concepts de CouchDB et présente un use case classique sur http://books.couchdb.org/relax/

Suite au succès de CouchDB dans le monde libre, les créateurs et principaux contributeurs ont crée Couch IO (http://www.couch.io), une société de conseil axée sur CouchDB, voir. Ceci est plutôt une très bonne nouvelle, car cela permettra de proposer des solutions commerciales autour de couch.

Enfin une alternative à SQLite ?

et enfin une implémentation de NoSql en windows, c'est bien pour remplacer l'ancien langage SQL

Tout dépend de l'utilisation que tu en fais J'utilise certains types d'applications qui utilisent une base SQLite et pour lesquelles je pense que NoSQL aurait un peu plus d'intérêt, par contre d'autres pour lesquelles MySQL (que j'utilise) reste imbattable.

-> http://refcardz.dzone.com/refcardz/g...nosql-and-data

c 'est moi ou on mélange tout ici ? ( réf à : Enfin un remplaçant de SQLite ? , c'est bien pour remplacer l'ancien langage SQL)

parce que nosql est juste un base de donnée non relationnelle tandis que le sql est un language d'interrogation de base de données relationnelles.
Bref ceux qui ont besoin de stoker des données de façon relationnelle le feront avec un bdd rel comme SQLite, et les autres pourront utiliser Nosql. Les premiers pourront utiliser le sql pour interroger leur bdd les autres un autre language (peut-on vraiment parler de language dans le cas de bdd non relationnel ?)

Non, j'ai certaines applis qui utilisent SQLite alors que NoSQL suffirait simplement, seulement à l'époque où ça a été conçu, NoSQL n'existait pas ou était totalement inconnu

hummm...

Ça pourrait être intéressant dans le cadre de projet nécessitant le stockage d'information totalement paramétrable...

NoSQL permet les transactions?