Discussion :

[Tokenizers]

Bonjour à tous,

Je suis nouveau dans la mouvance NOSQL et je commence tout juste à comprendre un peu les concept de certaines bases dites NOSQLmais j'ai un petit soucis sur la compréhension et notamment pour couchbase.
J'étudie un peu le fonctionnement de couchbase et notamment la réplication multi-maître ainsi que son mode de verrouillage dit "CAS".
Pour moi cette base serait donc PA d’après le théorème de Brewer?
Pourtant il me semble avoir lu que beaucoup de gens pensent que cette base soit CP alors je dois me tromper.
J'ai l'impression de ne pas avoir tout saisi. Alors CP ou PA? Je m'en remet a vous pour plus de compréhension.

[hugo123]

Je ne connais pas assez Couchbase. Mais ne serait-ce pas a cause d'un paramétrage ?

Certaines bases proposent de choisir le mode de réplication de la donnée (Cassandra le fait il me semble).
Quand tu peux jouer sur les 3 paramètres suivants : N (number of replication nodes), R (read quorum), and W (write quorum) alors tu peux choisir ton niveau de cohérence.
Source : http://jimdowney.net/2012/03/01/even...ow-consistent/

Pour donner un exemple, sur Mongo, si tu choisis un w = 1 alors que tu as 3 noeuds, tu n'est pas CP mais tu privilégies AP. Si tu choisis w = majority (donc ici 2 dans un cluster de 3 noeuds) alors tu es CP.

a+

[forrestdg]

Couchbase, contrairement autres systems de type Dynamo (Cassandra, Riak), ne garantit pas vraiment le P. Si un nœud tombe, tous les cles qui sont 'actives' sur ce noeud seront inaccessible, le temps que le failover est declenche (par default 30s).

A partir de la, c'est facile de dire que, dans un cluster donne, tu as une consistence forte (une cle est "active" sur un seul nœud --> consistent) et une très haute disponibilité (difficile de battre memcache en terme de temps d’accès).

Si tu es multi-datacenter, ne parlons même pas du degré de consistence de tes donnes, toute la synchronisation (XDCR) est faite dans ton dos. Il est très difficile d'avoir une visibilité sur ses activités d'un point vue du client.

[hugo123]

Sur Couchbase, on peut jouer sur les paramètres de réplication donc c'est en fonction de son cas d'usage qu'on privilégiera la dispo ou la cohérence.
Par contre Couchbase garantit bien la résistance au partitionnement réseau. Pourquoi dis tu le contraire ? Le fait de ne pas être dispo ca joue sur la disponibilité (A), pas sur la résistance au partitionnement (P).
Bon de plus si on veut privilégier la dispo il faut jouer sur le nombre de replication d'une donnée au sein des noeuds du cluster (un peu comme Cassandra).
Côté client, c'est à celui qui effectue ces requêtes d'exiger un degré de cohérence en précisant le nombre de noeud qui doivent être en mesure de lui confirmer sa lecture, c'est tout à fait maitrisable.

[forrestdg]

Le nombre de replicas ne joue aucun rôle pour la partition tolerence.

Il y a un seul noeud qui est active pour une clé. Si ce noeud tombe ta clé est inaccessible pendant un certain temps (30s) par defaut! Qu'apres le declenchement du failover qu'un autre noeud sera elu pour "remplacer" le noeud perdu.

Couchbase est superbe pour les systemes de cache, persistent en plus, t'as pas à repopuler ton cache apres un redemarrage!!

Qu'apres avoir mis des infos un peu plus critique dans Couchbase qu'on a commence a observer des trucs rigolots (ou pas). :-)

[hugo123]

J'ai confondu entre Couchbase et CouchDB

(CouchDB a bien des options pour faire varier le curseur entre AP et CP. )