CouchDB se présente comme une base de données documentaire. Cette phrase est réductrice par rapport aux concepts mis en pratique par couchDB. C'est en effet un concentré de technologies et de bonnes idées.
Je vais détailler 5 idées de base et aborder des concepts généraux..
CouchDB est une base de données orientée document. Elle stocke des documents et leurs pièces jointes comme les images par exemple.
CouchDB est capable d'exécuter des procédures stockées, ecrites en javascript.
Enfin coucheDB est ecrit en Erlang afin d'optimiser les performances. Il possède une interface de communication HTTP de type REST qui délivre ses réponses en JSON.
Principes
1) Les bases de données relationnelles ne sont pas toujours adaptées à notre 'vrai' univers.
Exemple : comment stocker des cartes de visites dans une BDDR ? : il faut créer une table pour les noms , prénoms , une autre table pour les téléphones une autre pour les mails. Une base de données relationnelle doit au moins respecter les trois formes normales (
voir les rappels ici) . On se retroucve parfois avec des tables avec des champs vides.
2) On utilise de plus en plus souvent comme index un champ numérique autoincrémenté.
Cette solution permet d'avoir un identifiant technique non significatif. Mais cela rend très difficile le partitionnement des données. En fusionnant plusieurs sources de même nature, il va y avoir forcement des doublons dans les identifiants.
3) Les techniques d'historisation dans une BDDR coûtent chères et sont complexes. Pourtant, il existe une solution simple dans le monde du développement : le versionning (Subversion , GIT)
4) Les applications qui ont besoin de performance doivent êtres simples : Architecture REST, pas de verrous bloquants.
Avec REST , le client et non pas le serveur est chargé de conserver l'état des transaction. Cette opération est très limitée car les transactions sont atomiques et auto-suffisantes.
Un document qui est en cours de modification ne doit pas empêcher les services de délivrer sa version la plus récente à d'autres clients.
5) Il doit être possible de réaliser des opérations de masse sur les éléments stockés dans la base : c'est l'utilisation du Map and Reduce comme procédures stockées par le serveur.
Concepts généraux : le diagramme de CAP.Ainsi couchDB se veut comme un système de base de données 'documentaires' évolutif et performant.
Le positionnement de couchDB peut se faire par rapport au diagramme de 'CAP'
C = Consistance des données , A = disponibilité des données (availability) et P = tolérance au Partitionnement des données. Chaque notion est un cercle, chaque cercle possède 2 points d'intersection avec les autres cercles (comme une rosace)
A l'intersection du cercle de la disponibilité et de la consistance des données on trouvera un protocole comme
'paxos' qui est utilisé dans le projet
Chubby de Google : Les données sont disponibles et consistantes mais centralisées.
Les BDDR se placeront à l'intersection du cercle 'consistance' et 'partitionnement' : les données sont intègres , partageables sur des nœuds de cluster mais la disponibilité reste un problème. Exemple : il est facile de faire une base de données 'maitre' et des replicats, mais l'opération d'écriture ne pourra se faire que sur l'instance Maitre.
CouchDB se place à l'intersection de consistance et de disponibilité. Les données d'une base ne peuvent pas être nativement partitionnées sur plusieurs serveurs. Cette dernière contraintes est mineure par rapport aux deux autres facteurs. Cela ne vaut pas dire qu'il n'y ait pas un système de réplique, bien au contraire , couchDB est multi-maitre.
Les versions de document.CouchDB utilise le MVCC (multi Version concurrency control) : gestion des versions multiples concurrentes. Cela veut dire qu'il n'utilise pas de verrou. Le client peut toujours obtenir la version la plus récente de l'entrée. Dès que le changement sera 'propagé' , c'est cette version qui sera disponible. Un client désirant envoyer une modification doit toujours indiquer sur quelle version il travaille.
L'identifiant des documentsCouchDB utilise des Universally Unique Identifiers (UUID) qui sont déterminés soit par le client soit par le serveur.
Un exemple d'entrée:
{
_id:”234567BCD4621D373CADE4E832627B345”,
_rev: 413123,
“Corps”: “ceci est le texte du document“,
"date" :"unbe_date"
}
Exemples de manipulations
curl http://localhost:5984/_all_dbs
Curl est un client HTTP en ligne de commande
La réponse du serveur :
["essaidb"]
La réponse est en JSON.
Interrogation de tous les documents :
curl http://localhost:5984/essaidb/_all_docs
{"total_rows":5,"offset":0,"rows":[
{"id":"7a1f52b2a0a7c74de7cba2f35b314ce9","key":"7a1f52b2a0a7c74de7cba2f35b314ce9","value": {"rev":"425879379"}},
{"id":"cbc79bccbc338e05abfb2932cf67a888","key":"cbc79bccbc338e05abfb2932cf67a888","value": {"rev":"707723218"}},
{"id":"encoreunessai","key":"encoreunessai","value":{"rev":"517881535"}},
{"id":"essaieric","key":"essaieric","value":{"rev":"12590446"}},
{"id":"essaisuite","key":"essaisuite","value":{"rev":"3012959012"}}
Mais aussi
CouchDB permet de redéfinir le mode de sortie, en remplaçant le JSON par du HTML. De même, il permet de programmer ses propres vues. Ainsi ,il est possible de réaliser des véritables apllications sans rien d'autre que couchDB
Utilisation d'une vue sans formatage particulier :
