Couchbase lag et des vues

Question

je pense que Couchbase peut être en mesure de résoudre beaucoup de problèmes dans mon projet en cours mais il y a quelques choses de base que je dois être sûr de la première:

1) Dire que j'ai cluster avec 10 noeuds, j'ajoute un document au noeud A. Je demande alors le noeud B pour ce document, vais-je définitivement récupérer le document? Y a-t-il un risque que je demande au noeud B et qu'il pense que le document n'existe pas?

2) Dites maintenant que j'écris une vue afin que je puisse voir tous les documents pour un certain auteur. J'ajoute un document au noeud A. Je sais qu'il y a un certain temps de latence pour que ce document apparaisse dans la vue pendant qu'elle est indexée. Ce que je veux savoir, c'est que ce temps de latence sera très minime puisque je ne fais qu'indexer un document? Fondamentalement, j'ai un site Web qui gère quelque chose de l'ordre de 100 millions de documents. Il y a des milliers d'utilisateurs à la fois, il y a environ 10 à 20 serveurs en fonctionnement. Avec l'architecture actuelle, si j'insère un document dans le nœud A, lorsque je cherche ce document, je peux très bien accéder au nœud B pour l'obtenir. Donc ma question générale est:

L'utilisateur insère un document dans le noeud A, je leur montre alors un écran de tous leurs documents. Si j'utilisais Couchbase, cet écran serait le résultat de l'interrogation d'une vue saisie sur Author. Quelle est la probabilité que l'utilisateur ne puisse pas voir le document qu'il vient de publier?

Answer 1

1. Vous pourrez toujours récupérer le document quel que soit le nœud demandé. Si vous utilisez l'un des SDK de Couchbase, ils s'assureront toujours qu'ils demandent au nœud qui a le document. Si vous utilisez moxi, alors il fera de même, donc vous ne devriez pas avoir à vous en soucier.

2. Cela dépend de la charge de votre travail en écriture. Dans l'architecture actuelle (2.0), un document doit être enregistré sur le disque avant d'être indexé. Si vous avez une lourde charge de travail en écriture, le décalage augmentera car il y aura une plus longue ligne d'éléments à écrire sur le disque. Je suggère d'effectuer une analyse comparative en tenant compte des exigences spécifiques de votre application pour ce cas d'utilisation et de signaler tout problème ou problème que vous avez sur les forums Couchbase.

, vous voulez aussi jeter un oeil aux commandes qui ont des exigences de durabilité et de faire des requêtes avec le paramètre de requête rassis défini sur false. Les commandes de durabilité vous permettront d'avoir votre bloc d'application jusqu'à ce qu'un élément frappe le disque et faire une requête avec l'état périmé défini sur faux s'assurera que votre vue est à jour avec les derniers articles mis dans Couchbase. Ce processus garantit à vos utilisateurs de toujours voir les derniers résultats de vous

EDIT: Couchbase 3.0 ne nécessite plus la persistance d'éléments sur le disque avant de pouvoir être interrogés.

Answer 2

Les mises à jour d'affichage sont un paramètre réglable. Par défaut, un thread se réveille toutes les 5 secondes, vérifie les modifications et met à jour l'index s'il les trouve. Vous pouvez soit régler ces paramètres, soit utiliser le paramètre d'affichage stale=false pour les requêtes.

De la documentation sous la rubrique « mises à jour automatiques index »:

En plus d'un intervalle de mise à jour configurable, vous pouvez également mettre à jour tous les index automatiquement en arrière-plan. Vous configurez la mise à jour automatique via deux paramètres, l'intervalle de mise à jour en secondes et le nombre de modifications de document effectuées avant que le moteur de vues ne mette à jour un index.Ces deux paramètres sont updateInterval et updateMinChanges:

• updateInterval: l'intervalle de temps en millisecondes, par défaut est de 5000 millisecondes. À chaque updateInterval, le moteur de vues vérifie si le nombre de mutations de document sur le disque est supérieur à updateMinChanges. Si vrai, il déclenche la mise à jour de la vue. Les documents stockés sur le disque sont potentiellement en retard sur les documents qui sont en mémoire pendant des dizaines de secondes. UpdateMinChanges: le nombre de changements de document qui se produisent avant la réindexation se produit, la valeur par défaut est de 5000 changements.

http://docs.couchbase.com/admin/admin/Views/views-operation.html