Comme tout le monde, je suis la mode et je m'intéresse aux bases de données NoSQL. Celle que je connais le mieux pour l'avoir déjà utilisée est CouchDB. Je ne vais pas te présenter cette solution, mais je peux te donner un petit retour de ce que j'ai vu, et de ce que j'aime:
REST
L'interface par défaut de CouchDB, c'est tout simplement du HTTP utilisée REST tout proprement. Pour déposer un document, un simple PUT suffit; pour en obtenir un autre, GET.
CouchDB fait l'effort de marcher avec du HTTP de base, sans ajouter de surcouche qu'il serait le seul à comprendre. Du coup, n'importe quel langage sait parler à CouchDB si il sait parler le standard. En fait, tout ce que tu fais, c'est du CRUD standard, le fameux Web 2.0 (enfin c'est l'explication la plus rationnelle que je vois à cette appellation)
Oh, bien sûr, ce n'est pas la seule base de données à le faire, mais puisque c'est son interface par défaut, j'ai tendance à penser que c'est lui qui le fait le mieux (Note : je n'ai testé aucune alternative, donc ce que je viens de dire peut très bien être pris à la légère). Le corollaire de ça, c'est :
Futon, l'interface d'administration
Elle est directement dans la base de données, et accessible avec un simple navigateur Web. Et quand je dis administration, c'est autant administration du serveur qu'administration des différentes bases de données. En fait, si tu veux te servir de couchDB pour stocker tes données personnelles (Ce qui était le but de desktopcouch), tu peux même aller directement les éditer à la main dans cette interface, ou en ajouter de nouvelles. Ceci avec la version de base de CouchDB, sans rien installer de plus.
Les CouchApps
Un site web, finalement c'est quoi ? C'est juste une ou plusieurs pages HTML avec quelques N'images. Et pour récupérer des documents dans CouchDB, tu fais un GET sur une base de données, c'est à dire exactement la même chose que quand tu vas sur DLFP pour troller dans la joie et la bonne humeur.
Partant de là, les couchapps sont une collection de fichiers placés dans une base de données, avec quelques subtilités (vraiment, rien de compliqué), et qui te font un vrai site web tout plein en 2 coups de cuillères à pot ! Et une fois que t'as bien prototypé ton site, tu le répliques sur une instance de chez iriscouch, et tu distribues au monde entier le plus simplement du monde.
Map/Reduce
Le principe est assez connu aujourd'hui, et je ne vais pas te faire l'affront de t'expliquer ce que c'est; je rappelle juste au futur lecteur qu'il s'agit d'un moyen de distribuer le travail sur des agents de travail indépendants, qui mettent ensuite tout leur travail en commun de manière distribuée pour retourner les informations. Bon en pratique ya un machine qui fait tourner CouchDB, mais cette distribution des tâches dans la VM Erlang peut te monter ton CPU à 100% et donc l'utiliser à fond.
Et bien CouchDB repose grandement là-dessus: l'un des intérêts quand on construit une base de données avec est d'utiliser les vues pour avoir une information qui sera souvent demandée (comme l'âge moyen des utilisateurs par exemple). Une vue dans CouchDB est en fait un processus de MapReduce mis en cache (enfin, c'est le résultat qui est mis en cache) que CouchDB va mettre à jour automatiquement à chaque modif.
Replication
Très clairement, LE point fort de CouchDB, bien que je ne l'ai que peu utilisé. Pour faire simple, CouchDB est construit depuis le début pour être répliqué le plus simplement (un appel HTTP) et le plus efficacement (résolution primitive des conflits) possible.
Ca, c'est l'approche statique; là où ça devient intéressant, c'est quand on GET la ressource _changes, qui stocke séquentiellement TOUS les changements faits dans la DB, et permet de synchroniser efficacement 2 db qui se suivent l'une l'autre, par exemple.
Performances
Aha ! Tu as cru que les performances étaient un point fort de CouchDB ? Raté ! En général on constate plutôt que les perfs sont pas nécessairement meilleurs que le SQL. Plusieurs raisons à ça, les deux que je vois le plus sont la (dé)sérialisation en JSON et l'overhead du HTTP par dessus. Mais disons que pour les points forts du dessus, "ça suffit"
Espace disque
Qu'on se le dise tout de suite : CouchDB est extrêmement vorace. Il prend des Giga et des Giga octets de ton pauvre disque. A mon avis, le postulat de base c'est storage is cheap. Malheureusement, c'est pas aussi cheap que ça (Je pense par exemple aux téléphones).
Conclusion
J'aime bien CouchDB, mais c'est peut-être parce que je ne m'en sers pas encore sérieusement (ie en prod).
# Top !
Posté par rakoo (site web personnel) . En réponse au journal NoSQL ou pas ?. Évalué à 8.
Comme tout le monde, je suis la mode et je m'intéresse aux bases de données NoSQL. Celle que je connais le mieux pour l'avoir déjà utilisée est CouchDB. Je ne vais pas te présenter cette solution, mais je peux te donner un petit retour de ce que j'ai vu, et de ce que j'aime:
REST
L'interface par défaut de CouchDB, c'est tout simplement du HTTP utilisée REST tout proprement. Pour déposer un document, un simple PUT suffit; pour en obtenir un autre, GET.
CouchDB fait l'effort de marcher avec du HTTP de base, sans ajouter de surcouche qu'il serait le seul à comprendre. Du coup, n'importe quel langage sait parler à CouchDB si il sait parler le standard. En fait, tout ce que tu fais, c'est du CRUD standard, le fameux Web 2.0 (enfin c'est l'explication la plus rationnelle que je vois à cette appellation)
Oh, bien sûr, ce n'est pas la seule base de données à le faire, mais puisque c'est son interface par défaut, j'ai tendance à penser que c'est lui qui le fait le mieux (Note : je n'ai testé aucune alternative, donc ce que je viens de dire peut très bien être pris à la légère). Le corollaire de ça, c'est :
Futon, l'interface d'administration
Elle est directement dans la base de données, et accessible avec un simple navigateur Web. Et quand je dis administration, c'est autant administration du serveur qu'administration des différentes bases de données. En fait, si tu veux te servir de couchDB pour stocker tes données personnelles (Ce qui était le but de desktopcouch), tu peux même aller directement les éditer à la main dans cette interface, ou en ajouter de nouvelles. Ceci avec la version de base de CouchDB, sans rien installer de plus.
Les CouchApps
Un site web, finalement c'est quoi ? C'est juste une ou plusieurs pages HTML avec quelques N'images. Et pour récupérer des documents dans CouchDB, tu fais un GET sur une base de données, c'est à dire exactement la même chose que quand tu vas sur DLFP pour troller dans la joie et la bonne humeur.
Partant de là, les couchapps sont une collection de fichiers placés dans une base de données, avec quelques subtilités (vraiment, rien de compliqué), et qui te font un vrai site web tout plein en 2 coups de cuillères à pot ! Et une fois que t'as bien prototypé ton site, tu le répliques sur une instance de chez iriscouch, et tu distribues au monde entier le plus simplement du monde.
Map/Reduce
Le principe est assez connu aujourd'hui, et je ne vais pas te faire l'affront de t'expliquer ce que c'est; je rappelle juste au futur lecteur qu'il s'agit d'un moyen de distribuer le travail sur des agents de travail indépendants, qui mettent ensuite tout leur travail en commun de manière distribuée pour retourner les informations. Bon en pratique ya un machine qui fait tourner CouchDB, mais cette distribution des tâches dans la VM Erlang peut te monter ton CPU à 100% et donc l'utiliser à fond.
Et bien CouchDB repose grandement là-dessus: l'un des intérêts quand on construit une base de données avec est d'utiliser les vues pour avoir une information qui sera souvent demandée (comme l'âge moyen des utilisateurs par exemple). Une vue dans CouchDB est en fait un processus de MapReduce mis en cache (enfin, c'est le résultat qui est mis en cache) que CouchDB va mettre à jour automatiquement à chaque modif.
Replication
Très clairement, LE point fort de CouchDB, bien que je ne l'ai que peu utilisé. Pour faire simple, CouchDB est construit depuis le début pour être répliqué le plus simplement (un appel HTTP) et le plus efficacement (résolution primitive des conflits) possible.
Ca, c'est l'approche statique; là où ça devient intéressant, c'est quand on GET la ressource _changes, qui stocke séquentiellement TOUS les changements faits dans la DB, et permet de synchroniser efficacement 2 db qui se suivent l'une l'autre, par exemple.
Performances
Aha ! Tu as cru que les performances étaient un point fort de CouchDB ? Raté ! En général on constate plutôt que les perfs sont pas nécessairement meilleurs que le SQL. Plusieurs raisons à ça, les deux que je vois le plus sont la (dé)sérialisation en JSON et l'overhead du HTTP par dessus. Mais disons que pour les points forts du dessus, "ça suffit"
Espace disque
Qu'on se le dise tout de suite : CouchDB est extrêmement vorace. Il prend des Giga et des Giga octets de ton pauvre disque. A mon avis, le postulat de base c'est storage is cheap. Malheureusement, c'est pas aussi cheap que ça (Je pense par exemple aux téléphones).
Conclusion
J'aime bien CouchDB, mais c'est peut-être parce que je ne m'en sers pas encore sérieusement (ie en prod).
En tout cas, voilà un petit tableau qui m'a évité pas mal de recherches :
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis