Donc en fait je travaille comme Technical Evangelist. Mon rôle est de rencontrer les développeurs, les sysadmins, donc l'ensemble de la communauté technique pour expliquer ce qu'est le NoSQL parce qu’il y a encore beaucoup d'évangélisation à faire autour du NoSQL. Et de façon particulière après de descendre sur CouchBase en tant que produit, la façon dont on l'utilise, quels sont ces bénéfices.
Déjà je vais commencer par CouchBase en tant que produit. Couchbase est une base de données NoSQL orientée document, qui a comme caractéristique d'être hautement scalable, c'est à dire que l'on va pouvoir faire un cluster de plusieurs noeuds très facilement et en termes d'architecture c'est une base de données qui utilise MemCache comme cache par défaut et qui va stocker sur disque les informations et tu peux stocker du document JSON qui va pouvoir être indexé par MapReduce et n'importe quel type de valeur binaire ou textuelle jusqu'à 20 Mo. Par rapport à l'historique CouchDB/CouchBase, le point très important, Couchbase et CouchDB sont deux projets différents. Par contre effectivement il y a un historique qui est que le créateur de CouchDB, Damien Katz, et plusieurs personnes très actives sur le projet CouchDB comme Chris Anderson ou Volker qui travaille sur la partie Geo, Phil qui s'occupe des views, sont maintenant chez CouchBase. Ce qui s'est passé c'est que l'idée était de pouvoir faire scaler CouchDB et de tirer parti d'un projet qui s'appelait à l'époque MemBase qui était une base de données, de la persistance et de la distribution en dessous de MemCache. Donc l'idée était de faire une nouvelle base de données qui s'appellerait CouchBase avec le lien MemCache - CouchDB. Mais pour des raisons techniques, des raisons de performance, la persistance a été complètement réécrite. C’est-à-dire que ce n'est plus du CouchDB en dessous, c'est purement CouchBase, écrit en C à la place de Erlang. Donc juste la partie Erlang pour le cluster est restée, la partie persistance est écrite en C maintenant.
Donc les grandes parties ça va être Clé/Valeur, la première, entre guillemets, vue NoSQL. Documents, orienté colonne et graphe. Selon les besoins, selon les applications on va travailler avec du clé/valeur quand c'est très simple et que l'on n’a pas besoin de faire de recherches sur la valeur elle-même. Du document va être très approprié, car c'est souvent du JSON, c'est le cas de Mongo, c'est le cas de CouchBase, de CouchDB. Orienté colonne du type Cassandra, HBase. Et orienté graphe qui va avoir différentes approches. Et donc CouchBase c'est orienté document, mais également de part son historique avec MemBase, clé/valeur. Dans tous les cas de toute façon la clé est très importante, on va avoir une clé pour accéder à l'information, pour tous ces types-là, la clé est la façon la plus simple d'accéder à l'information.
On va en trouver deux. Celui qui va être un cache clé/valeur distribué de type MemCache, un accès très rapide à l'information qui va être distribuée sur un cluster et la grosse différence par rapport à MemCache c'est le fait d'avoir cette scalabilité et le partitionnement des données. L'autre cas d'utilisation qui est arrivé avec CouchBase 2, la base orientée document. Typiquement vous avez des documents et vous avez l'intention de faire des requêtes sur le contenu des valeurs que vous stockez parce que vous voulez écrire une gestion de produits par exemple, une gestion de catalogue, ça va très bien s'y prêter. Et le cas d'utilisation c'est n'importe quel type de donnée qui va être structuré et structurable en JSON, peut être un bon cas d'utilisation.
5. InfoQ : Quelles sont les nouveautés qui vont arriver prochainement dans CouchBase ?
La nouveauté qui va arriver le plus rapidement, c'est ce qu'on appelle CouchBase Mobile, qui est en cours de développement, en projet dans nos Labs, avec des premières versions Beta qui sont disponibles maintenant. Le cluster CouchBase est capable de synchroniser des données avec la base de données locale pour le mobile, Android, iOS, ou le stockage HTML5 que vous avez dans vos navigateurs. L'idée c'est de s'abonner à des "Channels" qui viennent du serveur pour synchroniser localement. Et le principe c'est que ça se fasse de manière transparente, dès que vous avez de la connectivité il va aller synchroniser les données entre le mobile et la base de données. Donc ça c'est la grosse nouveauté qui est actuellement en cours, et après c'est plein de petites améliorations au niveau de la façon de requêter les données, l'information, la façon de stocker l'information en mémoire de façon à ce qu'elle soit de plus en plus petite pour pouvoir scaler de mieux en mieux.
Si on regarde effectivement ces deux bases de données qui sont les leaders dans le côté orienté document, CouchBase va se situer autour de la scalabilité et de la performance. Cette capacité d'avoir un cluster qui grossit très rapidement. On prend l'exemple souvent d'OMGPOP's Draw Something qui est passé de 6 noeuds à 80 noeuds en quelques semaines, pour évoluer ; et vitesse d'accès à l'information par MemCache là où Mongo va plutôt se situer sur la facilité de requêtage de l'information et être un peu plus complexe dans sa scalabilité, avec un impact plus fort sur les performances. Donc si vous avez besoin de quelque chose qui est très rapide et d'une évolution de votre cluster en faisant grossir ou réduire le nombre de noeuds, Couchbase va être beaucoup plus facile à utiliser.
Alors là j'ai envie de réagir et de corriger cette partie-là. Je pense que le mot "migrer" de SQL vers NoSQL n'est pas nécessairement la meilleure approche. C'est le meilleur moyen de se mettre à dos les DBA. C'est plutôt, et là c'est intéressant de rappeler de nouveau le mot NoSQL, qui était plutôt initialement comme n'étant PAS du SQL, mais plutôt l'acronyme qu'on utilise tous maintenant "Not Only SQL" et qui vient bien dire, les bases NoSQL viennent en complément des bases existantes, du SQL, etc. La façon la plus simple d'approcher un projet c'est que sur certains projets, on arrive aux limites des bases relationnelles, vous avez beaucoup d'information, les requêtes que vous écrivez sont de plus en plus lentes et ça devient de plus en plus compliqué de traiter de l'information, parce que vous avez un volume d'information trop gros, trop de requêtes sur la base de données, donc là c'est le moment de se poser la question. Est-ce qu'il n'est pas intéressant de trouver une alternative avant de commencer à complètement torturer la base de données relationnelle. Une autre approche qui est intéressante est que si votre application doit stocker des informations qui viennent de droite et de gauche, de plus en plus de systèmes vont chercher de l'information sur Twitter, sur Facebook, dans vos logs, tout ça ce sont des données qui sont semi-structurées, c'est à dire qu'elles sont structurées mais ce n'est pas vous qui contrôlez la structure, on ne peut pas insérer ça dans la base relationnelle, en tout cas on ne peut pas le faire simplement, et plutôt que d'utiliser la base relationnelle comme une base clé/valeur, autant utiliser directement une base qui sait bien travailler avec ça