CouchDB : la base de données NoSql arrive sur Windows. Il serait plus rapide et plus simple d'utilisation

CouchDB : la base de données NoSql arrive sur Windows
Ce projet open-source de la Fondation Apache serait plus rapide et plus simple d'utilisation que les SGBD classiques


Le premier système de gestion de base de donnée non relationnel (ou NoSql) stable et prêt pour un usage en production vient d'être lancé. Il s'appelle «CouchDB», a annoncé mercredi la société Couchio, qui sponsorise le projet.

Deux améliorations majeures ont valu à cette version 1.0 le chiffre rond : une nette amélioration des performances, et la compatibilité de la nouvelle version avec les systèmes Windows.

A en croire les tests de benchmarking réalisés par l'entreprise, la nouvelle version serait jusqu'à 300% plus rapide en lecture et écriture, résultat d'un important travail sur l'optimisation du code source.

Il s'agit de la première version de CouchDB entièrement fonctionnelle sous Windows, que ce soit Serveur et Desktop, les versions précédentes ne tournaient que sous Linux.

Une variante développée par Google existe pour Android.

CouchDB stocke les données dans de simples paires clés-valeurs JSON, format de données emprunté au Javascript.

Une base CouchDB pourrait être interrogée via de simples requêtes HTTP.

Cette technologie devrait intéresser les développeurs web, essentiellement pour la sauvegarde hors-ligne des données des applications web qui doivent fonctionner même sans accès internet.

En outre, développer pour CouchDB serait plus facile que pour une base de données relationnelle. Il n'est pas nécessaire par exemple de savoir formuler des requêtes SQL pour insérer ou extraire les données d'une base.

CouchDB repose sur une implémentation de Google MapReduce pour construire ses requêtes.

Le développement de CouchDB a commencé en 2005 dans les laboratoires d'IBM comme projet pour Lotus Notes afin d'aider la réplication hors ligne des données.

En 2008, le projet est devenu open-source et indépendant, avant que Couchio ne commence à assurer son support.

CouchDB est un projet de la Fondation Apache. Le SGBD et son code source sont disponibles en téléchargement sur cette page.


Source : Le site de Couchio



Lire aussi :

:fleche: Des développeurs vous offrent une méthode d'utilisation de NoSQL, cette technologie est-elle un must ou un feu de paille ?

:fleche: Apache Cassandra en version 0.6.0 est disponible : gain de performances de 30 % pour la base de données NoSQL

:fleche: Faut-il en finir avec la mode NoSQL ? Ou est-ce plus qu'une simple mode passagère ?


Les rubriques (actu, forums, tutos) de Développez :

:fleche: SGBD
:fleche: Windows
:fleche: Apache
:fleche: Développement Web
:fleche: Mobile


Et vous ?

:fleche: Allez-vous tester cette version pour vos développement ?
:fleche: Sa sortie aidera-elle l'émergence du NoSql?


En collaboration avec Gordon Fowler

Enfin une alternative à SQLite ?

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

Citation:

---

Envoyé par mitnick2006

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

---

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.

Je serais vivement intéressé par un tutoriel pour expliquer la mise en oeuvre d'une base NoSQL, notamment la construction des requêtes, et qui aborde aussi la théorie afin de comprendre comment ça tourne.

Citation:

---

Envoyé par verbose

Je serais vivement intéressé par un tutoriel pour expliquer la mise en oeuvre d'une base NoSQL, notamment la construction des requêtes, et qui aborde aussi la théorie afin de comprendre comment ça tourne.

---

-> 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 ?)

Citation:

---

Envoyé par zoonel

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)

---

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?

Citation:

---

Envoyé par dtcSearch

hummm...

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

NoSQL permet les transactions?

---

A l'époque où je l'ai testée, Big Table (via google app engine) ne supportait que les single row transactions. C'est surement le prix a payer pour une base très scalable..

Citation:

---

Envoyé par zoonel

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 ?)

---

"Stocker des données de façon relationnelle" ? C'est à dire ?

Parce qu' il est tout a fait possible de stocker un modèle de données contenant des relations dans une base NoSql. Google et Amazon font ca tout le temps. :D

Pour moi, 90% du temps un développeur a juste besoin de stocker des données. Auquel cas, le coté "relationnel" du stockage c'est plus une contrainte technique qu'une nécessité.

noSQL porte mal son nom, on devrait parler de noRelation. La question du langage SQL ne fait qu'en découler.
Le modèle relationnel ne peut pas être implémenté avec un moteur noSQL. L'intérêt de noSQL est dans l'accès hyper-rapide et parallèle de données sans relations entre elles, ce qui est un besoin qui revient souvent dans domaine du web. Mais quand on a le besoin de rapprocher 2 données noSQL, la tentation est forte de réinventer la jointure en la codant.
noSQL ne gère généralement pas les transactions. C'est une technologique jeune sans trop d'outillage. Elle garde son intérêt dans des cas particuliers (pas si particulier que ça dans le domaine du web)

Je trouve l'idée potentiellement intéressante pour des problématiques bien particulières, mais je ne vois pas pour l'instant l'intérêt qu'elle peut avoir au "quotidien".
Je dois admettre que j'ai du mal à concevoir un modèle de données non relationnel ^^' (même pour du web oO )
En même temps, je suis jeune, et la techno aussi :P
Affaire à suivre donc, je testerai peut-être si j'ai le temps, mais je n'en fais pas une priorité.

Le concept de NoSQl ou du moins pour le peu que j'ai compris semble assez interessant en effet si les tables n'ont aucunes relations entre elles. Même si je l'avoue, je n'en perçois pas trop l'intérêt s'il s'agit juste de stocker des données!
Par contre je me demande s'il est possible de connecter deux BdD NoSQL à l'aide de MySQL sans devoir importer les tables de chaque base?
Ou encore, peut-on constituer une BdD NoSQL à partir de tables prises individuellement (et n'ayant 2 à 2 aucunes relations) dans des BdD MySQL déjà existantes?
:aie:

Citation:

---

Envoyé par susanoo

Le concept de NoSQl ou du moins pour le peu que j'ai compris semble assez intéressant en effet si les tables n'ont aucunes relations entre elles. Même si je l'avoue, je n'en perçois pas trop l'intérêt s'il s'agit juste de stocker des données!

:aie:

---

Il ne s'agit pas juste de stocker des données, un facteur très important dans une application est la rapidité hors avec NoSQL il y'a une certaine rapidité dans l'access en lecture comme en écriture.

Citation:

---

Envoyé par susanoo

Par contre je me demande s'il est possible de connecter deux BdD NoSQL à l'aide de MySQL sans devoir importer les tables de chaque base?
Ou encore, peut-on constituer une BdD NoSQL à partir de tables prises individuellement (et n'ayant 2 à 2 aucunes relations) dans des BdD MySQL déjà existantes?

---

J'ose croire que tu demandes plutôt comment transférer les données d'une BD Mysql vers une BD NoSQL. Tu peux toujours faire un script qui transfert tes données de ta BD Mysql vers ta BD NoSQL.

Etant habitué à manipuler des données semi structurées ou pas que je stockais au format XML(que je trouve trop verbeux et lourd des fois), je crois que NoSQL est une bonne alternative pour moi. Je vais sur le champs télécharger et tester le truc :lol:

@++ ;)

Personnellement, je n'en vois pas l'utilité. Même avec un sgbd normal on peut faire des tables non relationnelles. Le SQL est un langage performant et rapide, les SGBDR sont de plus en plus efficaces et sécurisés et leur gestion des données possède des temps de réponse pour des millions d'enregistrements de l'ordre de la seconde en restitution et en ecriture c'est guère plus lent..
Je comprends que l'on puisse vouloir autre chose, mais je n'en vois pas l'intérêt.

Citation:

---

Envoyé par Lyche

Personnellement, je n'en vois pas l'utilité....
Je comprends que l'on puisse vouloir autre chose, mais je n'en vois pas l'intérêt.

---

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.

Merci pour cette explication :)
Par contre, tu me parles de MySQL, mais honnêtement c'est loin d'être une référence pour moi en terme de SGBDR. J'aurais tendance à le déconseiller tant ce système est archaïque et à la masse question sécurité. (Je parle pour mon cas d'exploitation de sgbd, banque, banques d'affaires et de finances, BI et données gérées par Tera Octets)

<<...serait plus facile que pour une base de données relationnelle. Il n'est pas nécessaire par exemple de savoir formuler des requêtes SQL...>>

SQL est facile! Surtout comparé à n'importe quelle technologie moderne web qui ont toutes la particularité d'être complexe!

Si on n'est pas capable de comprendre SQL je ne crois pas que grand chose soit possible.

Mais bon je suppose que ce n'est la raison première de s'intéresser à cette chose et que la comparaison même avec SQL n'a pas de sens.
C'est comme si MS-Word s'appelait MS-noExcel parce que c'est mieux pour faire du traitement de texte ou pas?

Fred

D'ailleurs à quand la section no-sql dans les forums ???