Figure 1. Documents autosuffisants
Apache CouchDB est une nouvelle engeance de système de gestion de base de données. Ce chapitre explique les raisons du besoin de nouveaux systèmes ainsi que les motivations sous-jacentes à la conception de CouchDB.
En tant que développeurs de CouchDB, nous sommes bien entendus très excités à l’idée de pouvoir utiliser CouchDB. Le long de ce chapitre, nous partagerons avec vous les raisons de notre enthousiasme. Nous vous montrerons pourquoi le modèle de document sans squelette de CouchDB est une meilleure solution pour les applications classiques, en quoi le langage de requête qu’il intègre par défaut est un moyen puissant d’utilisation et de traitement de vos données, et en quoi la conception même de CouchDB se prête à la modularisation et au passage à l’échelle.
S’il est un mot pour décrire CouchDB, c’est détendez-vous [NdT : en anglais, relax]. C’est le titre de ce livre, c’est le slogan du logo officiel de CouchDB, et quand vous démarrez CouchDB, vous voyez :
Apache CouchDB has started. Time to relax.
Pourquoi la détente est-elle importante ? La productivité d’un développeur a environ doublé ces cinq dernières années. La principale raison de cette amélioration réside dans la facilité d’utilisation d’outils de plus en plus puissants. Prenez Ruby on rails, par exemple : c’est un framework d’une complexité extrême, mais il est très aisé de faire ses premiers pas avec. Rails est une réussite, car le principe de base de sa conception est la facilité d’usage. C’est une des raisons pour lesquelles CouchDB est reposant : découvrir CouchDB et comprendre ses principes fondamentaux devrait paraître naturel pour la plupart des personnes qui se sont penchées un tant soit peu sur le Web. Et c’est aussi assez simple à expliquer à des profils non techniques.
Ne pas entraver les créateurs quand ils tentent de construire des solutions spécialisées est en soi une fonctionnalité fondamentale et une chose que CouchDB aime à satisfaire. Nous trouvons que les outils existants sont trop encombrants pour s’en accommoder durant les phases de développement et de production. C’est pourquoi nous avons décidé de faire de CouchDB une solution facile, voire plaisante à utiliser. Les chapitres 3 et 4 démontrent l’intuitivité de l’API REST basée sur HTTP.
Le paramètre de production est un autre aspect de la relaxation procurée par CouchDB à ses utilisateurs. Si vous avez une application en production, CouchDB fait en sorte de ne pas vous déranger. Son architecture interne est tolérante aux pannes, les défaillances se produisent dans un environnement contrôlé et sont gérées harmonieusement. Les problèmes unitaires ne se cascadent pas à travers tout le système, mais demeurent isolés dans les requêtes.
Les concepts fondamentaux de CouchDB sont simples, puissants et bien compris. Les équipes d’exploitation (si vous en avez une ; à défaut, c’est vous) n’ont pas à s’inquiéter de comportements aléatoires et d’erreurs impossibles à tracer. Si quelque chose devait aller de travers, vous pourriez facilement trouver le problème ; mais ces situations sont rares.
CouchDB est aussi conçu pour s’adapter aux variations de trafic. Par exemple, si un site web connaît un pic soudain de trafic, CouchDB absorbera généralement un grand nombre de requêtes concurrentes sans s’effondrer. Cela nécessitera peut-être plus de temps pour chaque requête, mais elles seront toutes satisfaites. Quand ce pic retombe, CouchDB recouvrera sa rapidité habituelle.
Le troisième point de détente est relatif à l’attribution et au retrait de ressources matérielles sur lesquelles fonctionne votre application. C’est ce que l’on appelle usuellement le passage à l’échelle. CouchDB impose un ensemble de contraintes au programmeur. De prime abord, CouchDB peut paraître rigide, mais certaines fonctionnalités sont écartées à la conception, car leur inclusion mettrait en péril le passage à l’échelle de l’application qui les utiliserait. Nous détaillerons le passage à l’échelle dans la Partie IV, Déployer CouchDB.
En bref, CouchDB ne vous laisse pas faire ce qui pourrait vous causer des problèmes par la suite. Cela signifie que vous devrez parfois désapprendre les bonnes pratiques que vous avez déduites de vos expériences passées ou présentes. Le Chapitre 24, Recettes donne une liste des tâches courantes et explique comment les réaliser avec CouchDB.
Nous croyons que CouchDB changera profondément la manière dont vous construisez des applications traitant des documents. CouchDB combine un modèle de stockage de document intuitif à un moteur de requêtes puissant et si simple que vous demanderez peut-être pourquoi personne n’y a pensé avant.
Django est peut-être conçu pour le Web, mais CouchDB est conçu par le Web. Je n’ai jamais vu de logiciel embrassant si profondément la philosophie sous-jacente à HTTP. CouchDB fait pâlir Django et le relègue à la « vieille école » de la même manière que Django relègue l’ASP au passé.
— Jacob Kaplan-Moss, développeur de Django
CouchDB s’inspire grandement de l’architecture du Web et des concepts de ressources, de méthodes et de représentations. Il va plus loin en fournissant des moyens efficaces de requête, de sous-division, de fusion et de filtre de vos données. Ajoutez-y la tolérance aux pannes, des capacités extrêmes de passage à l’échelle, des réplications incrémentales et CouchDB devient un nid douillet pour les bases de données orientées documents.
Nous concevons des logiciels pour améliorer notre existence et celle des autres. Typiquement, cela consiste à prendre quelques informations banales (contacts, devis, factures) et à les manipuler à l’aide d’un ordinateur. CouchDB est une réponse adaptée aux applications courantes comme celles-ci, car il inclut aux origines de son modèle de données le concept naturel de documents évoluant et autosuffisants.
Une facture contient toutes les informations décrivant une unique transaction : le vendeur, l’acquéreur, la date et une liste d’objets ou de services cédés. Comme le montre la Figure 1, Documents autosuffisants, il n’y a pas de référence abstraite dans ce document qui pointe vers un autre bout de papier qui contient le nom et l’adresse du vendeur. Les comptables apprécient la simplicité d’avoir tout au même endroit. Et, si le choix leur est donné, les développeurs aussi.
Figure 1. Documents autosuffisants
Et pourtant, recourir aux références est exactement la manière dont nous modélisons les données dans les bases de données relationnelles ! Chaque facture est stockée dans une table sous la forme d’un enregistrement qui référence d’autres enregistrements dans d’autres tables : un pour les informations concernant le vendeur, un pour chaque objet, et encore davantage pour le détail des objets, sans compter les informations du constructeur, et cetera desunt.
Il n’est pas question de détracter le modèle relationnel qui est largement adapté et extrêmement utile pour de nombreuses raisons. Toutefois, cela illustre la problématique des modèles de données qui ne correspondent pas à la manière dont la donnée est traitée dans le monde réel.
Prenons le cas du carnet d’adresses pour illustrer une modélisation différente des données qui se rapproche davantage du monde réel : une pile de cartes de visite. Tout comme l’exemple des factures, une carte de visite contient toutes les informations importantes sur le même bout de carton. Nous appelons cela les données « autosuffisantes » et c’est un concept important pour comprendre les bases de données telles que CouchDB [NdT : en anglais, self-contained data].
La plupart des cartes de visite affichent les mêmes informations : l’identité de quelqu’un, une affiliation et quelques informations de contact. Malgré les divergences de présentation, les informations véhiculées sont les mêmes et nous identifions rapidement le bout de carton comme étant une carte de visite. En ce sens, nous pouvons dire d’une carte de visite qu’elle est un document du monde réel.
La carte de visite de Jan pourrait indiquer un numéro de téléphone, mais pas de numéro de fax, tandis que celle de J. Chris affiche les deux informations. Jan n’a pas à rendre ce manque d’information explicite en écrivant quelque chose de ridicule comme : « Fax : aucun » sur sa carte. Il préfère plutôt ne pas l’inscrire, ce qui signifie qu’il n’en a pas.
Nous pouvons constater que les documents du monde réel de même type, tels que les cartes de visite, ont une sémantique similaire (le type d’informations écrites), mais diverge grandement en syntaxe, c’est-à-dire dans la manière dont elles sont structurées. L’Homme est habitué à gérer facilement ce genre de divergence.
Alors qu’une traditionnelle base de données relationnelle vous oblige à modéliser vos données a priori, le concept de documents sans squelette de CouchDB vous en affranchit en vous fournissant un moyen redoutable d’agréger vos données a posteriori, comme vous le feriez dans le monde réel. Nous détaillerons comment concevoir des applications avec ce paradigme de stockage sous-jacent.
CouchDB est un système de stockage utile en lui-même. Vous pouvez bâtir de nombreuses applications avec les outils que CouchDB met à votre disposition. Mais CouchDB a un plus grand dessein. Ses composants peuvent être utilisés pour construire des îlots qui résolvent les problèmes de stockage de manière un tant soit peu différente pour les systèmes plus grands ou plus complexes.
Que vous ayez besoin d’un système qui soit extrêmement rapide aux dépens de la fiabilité (pensez à la journalisation) ou d’un système qui garantisse le stockage dans deux locaux différents aux dépens de la performance, CouchDB est votre atout.
Il existe de nombreux paramètres que vous pouvez ajuster pour rendre un système plus performant dans un domaine, mais vous allez nécessairement impacter d’autres aspects. Nous décrirons un exemple au prochain chapitre : le théorème CAP (ou CDP ou théorème de Brewer en français). Pour avoir un aperçu des autres aspects qui affectent les systèmes de stockage, consultez les figures 2 et 3.
En réduisant la latence pour un système donné (ce qui ne se limite pas aux systèmes de stockages), vous impactez la parallélisation et la capacité de traitement.
Figure 2. Capacité de traitement, latence ou parallélisation (Throughput, latency, or concurrency)
Figure 3. Passage à l’échelle : requêtes d’écriture, requêtes de lecture, ou données (Scaling: read requests, write requests, or data)
Quand vous voulez passer à l’échelle, il existe trois problématiques à aborder : dimensionner les requêtes de lecture, les requêtes d’écriture et les données. D’autres facteurs, comme la fiabilité ou la simplicité, s’ajoutent orthogonalement aux figures 2 et 3. Vous pouvez tracer de nombreux graphiques comme ceux-ci qui montrent combien les différents facteurs vont dans autant de directions différentes et caractériser ainsi le système auxquels ils s’appliquent.
CouchDB est très flexible et vous permet de bâtir des îlots pour créer un système qui réponde parfaitement à votre problème. Cela ne signifie pas pour autant que CouchDB peut être ajusté pour répondre à tous les problèmes ; ce n’est pas une balle en argent, mais dans le domaine du stockage de données, il peut vous être un compagnon de longue route.
Le mécanisme de réplication de CouchDB est l’un de ces îlots. Son rôle fondamental est de synchroniser au moins deux bases de données CouchDB. Cela peut paraître simple, mais la simplicité est un facteur clé pour permettre à la réplication de résoudre de nombreux problèmes : permettre de manière fiable la redondance des données entre plusieurs machines ; répartir les données dans un cluster de bases CouchDB qui partagent un sous-ensemble du nombre total de requêtes qui sont adressées au cluster (répartition de charge) ; répartir les données sur des sites différents, par exemple à Tokyo et à New York.
Le mécanisme de réplication de CouchDB exploite la même API REST que les clients. HTTP est omniprésent et bien compris. La réplication est incrémentale, ce qui signifie que, si vous perdez la connexion durant le transfert (ou quoi que ce soit qui aille de travers), elle reprendra là où elle s’était arrêtée la dernière fois. En outre, elle transfère uniquement les données nécessaires à la synchronisation des deux bases de données.
Une hypothèse que CouchDB fait toujours est que les choses peuvent aller de travers (comme la connexion réseau) et CouchDB est conçu pour recouvrer harmonieusement de ces erreurs plutôt que de penser que tout ira bien. Le mécanisme de réplication incrémental en est une bonne illustration. Les pensées inhérentes à l’idée que « tout peut aller de travers » est les illusions de l’informatique distribuée :
Les outils existants tâchent souvent de cacher le fait qu’il y a un réseau et que tout ou partie des conditions précitées ne s’appliquent pas à leur application. Cela conduit généralement à des plantages fatidiques quand un élément s’est mis de travers. À l’opposé, CouchDB ne tente pas de masquer le réseau : il réagit harmonieusement aux erreurs et vous fait savoir quand des actions sont nécessaires à votre niveau.
CouchDB tire quelques enseignements du Web, et il est une chose qui pourrait être améliorée dans le Web : la latence. Quand vous devez patienter pour qu’une application réponde ou qu’un site web s’affiche, vous attendez quasiment toujours après un lien réseau trop faible pour votre besoin. Patienter quelques secondes au lieu de quelques millisecondes affecte grandement le ressenti de l’utilisateur.
Que faites-vous quand vous êtes déconnecté ? Cela arrive chaque fois que votre FAI rencontre des problèmes ou que votre iPhone, G1 ou BlackBerry ne capte pas le réseau ; et qui dit pas de connectivité dit aucun moyen de récupérer vos données.
CouchDB peut aussi s’employer dans de tels cas, et c’est là que le passage à l’échelle est de nouveau important. Cette fois, il s’agit de réduction. Imaginez que CouchDB soit installé sur les terminaux mobiles qui peuvent synchroniser leurs données avec des bases CouchDB centrales quand ils sont sur le réseau. La synchronisation ne connaît pas les contraintes d’interface utilisateur qui doivent réagir en moins d’une seconde. D’autre part, il est plus facile d’optimiser les systèmes pour une bande passante importante et une grande latence que pour une bande passante faible et des temps de réponses très rapides. Les applications embarquées peuvent alors exploiter CouchDB localement et, comme aucune connexion réseau n’est nécessaire pour cela, la latence est subséquemment faible.
Reste à savoir si vous pouvez vraiment utiliser CouchDB sur un téléphone. En fait, Erlang, le langage sur lequel repose CouchDB, a été conçu pour des systèmes bien plus petits et bien moins puissants que les téléphones actuels.
Le chapitre suivant explore plus avant le caractère distribué de CouchDB. Nous devrions avoir distillé suffisamment d’informations pour piquer votre curiosité. Allons-y !