éviter les conflits

IBM Cloudant est conçu pour traiter les conflits comme un état naturel des données dans un système réparti. Cette fonction est une fonction puissante qui permet à un cluster IBM Cloudant de conserver une haute disponibilité. Toutefois, l'hypothèse est que les conflits sont encore assez rares. Le suivi des conflits dans le cœur de IBM Cloudant a un coût significatif qui lui est associé.

Il est tout à fait possible (mais une mauvaise idée !) d'ignorer les conflits. La base de données est en mesure d'opérer en choisissant une révision aléatoire, mais déterministe des documents en conflit. Cependant, à mesure que le nombre de conflits non résolus augmente, la performance de la base de données descend dans un trou noir, en particulier lorsque vous effectuez une réplication.

En tant que développeur, il est de votre responsabilité de vérifier et de résoudre les conflits, ou encore mieux, d'utiliser des modèles de données qui rendent les conflits impossibles.

Si vous créez régulièrement des conflits, vous devez vraiment prendre en compte les changements de modèle : même si vous résolvez vos conflits avec diligence, les conflits présents dans l'arbre de révision restent sans aucun moyen de les nettoyer. Pour plus d'informations, consultez les sites Web suivants :

• Guide IBM Cloudant sur les conflits
• Guide IBM Cloudant pour les versions et MVCC
• Série de blog en trois parties sur les conflits

La suppression de documents ne les supprime pas

La suppression d'un document d'une base de données IBM Cloudant ne le purge pas. La suppression est implémentée en écrivant une nouvelle révision du document à supprimer, avec une zone ajoutée _deleted: true. Cette révision spéciale est appelée tombstone. Les tombstones prennent encore de l'espace et sont également transmises par le réplicateur.

Les modèles qui reposent sur des suppressions fréquentes de documents ne conviennent pas à IBM Cloudant. Pour plus d'informations, voir IBM Cloudant tombstone Docs.

Soyez prudent avec les mises à jour

Il est plus coûteux au final de muter des documents existants que de créer de nouveaux documents. IBM Cloudant doit toujours conserver l'arborescence des documents. Cette règle s'applique même si les nœuds internes de l'arborescence sont dépouillés de leurs contenus. Si vous trouvez que vous créez des arborescences de révision longue, votre performance de réplication en souffre. De plus, si votre fréquence de mise à jour est plus élevée que, disons, une ou deux fois toutes les quelques secondes, vous êtes plus susceptible de produire des conflits de mise à jour.

Préférez les modèles qui sont immuables.

Lorsque vous lisez les sections suivantes, La suppression de documents ne les supprime pas et Soyez prudent avec les mises à jour, elles provoquent une question évidente. La question est, est-ce que le jeu de données est sans limite si mon modèle est immuable ? Si vous acceptez que les suppressions ne purgent pas complètement les données supprimées et que les mises à jour ne sont pas mises à jour en termes de croissance du volume de données, il n'y a pas beaucoup de différence. La gestion du volume de données au fil du temps nécessite des techniques différentes.

La seule façon de vraiment récupérer l'espace est de supprimer des bases de données plutôt que des documents. Vous pouvez répliquer uniquement les révisions gagnantes dans une nouvelle base de données et supprimer l'ancienne pour supprimer les suppressions et les conflits persistants. Ou peut-être vous pouvez le créer dans votre modèle pour lancer régulièrement de nouvelles bases de données (par exemple " données annuelles ") et archiver (ou supprimer) des données périmées, si votre cas d'utilisation le permet.

La cohérence éventuelle est une de vos tâches principales compliquées (aussi connu comme ne lisez pas vos écritures)

La cohérence éventuelle est une excellente idée sur le papier, et un contributeur clé de la capacité de IBM Cloudant de mettre à l'échelle dans la pratique. Cependant, il est juste de dire que l'état d'esprit requis pour se développer contre un magasin de données finalement cohérent n'est pas naturel pour la plupart des gens.

Vous vous faites souvent piquer la vedette lorsque vous écrivez des tests similaires à ceux qui suivent :

1. Créer une base de données.
2. Remplir la base de données avec quelques données de test.
3. Interrogation de la base de données pour un sous-ensemble de ces données de test.
4. Vérifiez que les données que vous avez données sont les données que vous vous êtes attendu à récupérer.

Rien de problématique avec ce test ? Cela fonctionne avec toutes les autres bases de données que vous avez utilisées, n'est-ce pas?

Pas sous IBM Cloudant.

Ou plutôt, cela fonctionne 99 fois sur 100.

Cette différence s'explique par une fenêtre d'incohérence (généralement) réduite entre l'écriture des données dans la base de données et la mise à disposition de ces données sur tous les nœuds de la grappe. Comme tous les nœuds d'une grappe sont de taille égale, rien ne garantit qu'une écriture et une lecture ultérieure soient effectuées par le même nœud. Ainsi, dans certaines circonstances, la lecture peut atteindre un noeud avant que les données écrites ne le rendent sur le noeud.

Alors pourquoi ne mettez-vous pas simplement un court délai dans votre test entre l'écriture et la lecture ? Ce retard rend le test moins susceptible d'échouer, mais le problème est toujours là.

IBM Cloudant n'a pas de garanties transactionnelles. Bien que les écritures de document soient atomiques (vous êtes certain qu'un document peut être lu dans son intégralité ou pas du tout), il n'existe aucun moyen de fermer la fenêtre d'incohérence. C'est là par la conception.

Une préoccupation sérieuse que chaque développeur doit considérer est que vous ne pouvez pas supposer en toute sécurité que les données que vous écrivez sont à la disposition de quelqu'un d'autre à un moment précis. Ce fait prend du temps à être assimilé si vous venez d'un autre type de tradition de base de données.

Astuce de test: ce que vous pouvez faire pour éviter la fenêtre d'incohérence dans les tests est de tester contre une instance à nœud unique de IBM Cloudant ou CouchDB fonctionnant disons dans Docker (informations de docker ). Un noeud unique supprime le problème de cohérence éventuel, mais attention car vous testez contre un environnement qui se comporte différemment de ce que vous ciblez dans la production. Caveat Emptor.

La réplication n'est pas magique

“So let’s set up three clusters across the world, Dallas, London, Sydney, with bi-directional synchronization between them to provide real-time collaboration between our 100,000 clients.”

Non. Juste ... Non. IBM Cloudant est bon lors de la réplication. Cela peut sembler magique, mais notez qu'il n'y a pas de garantie de latence. En fait, l'ensemble du système est conçu de façon cohérente. Le traitement de la réplication de IBM Cloudant comme système de messagerie en temps réel ne se termine pas dans un endroit heureux. Pour ce cas d'utilisation, mettez un système entre les deux qui a été conçu à cet effet, tel que Apache Kafka.

Il est difficile de mettre un nombre sur le débit de réplication. La réponse est toujours : " Ça dépend. " Les éléments qui ont une incidence sur les performances de réplication incluent, mais ne se limitent pas à :

1. Modifier la fréquence
2. Taille de document
3. Nombre de travaux de réplication simultanés sur l'ensemble du cluster
4. Arbres de document étendus (en conflit)
5. Vos paramètres de capacité de traitement réservé

Pour plus d'informations, consultez les sites Web suivants :

• Post de blog sur la topologie de réplication
• Guide pour la réplication IBM Cloudant

Utiliser l'API en bloc

IBM Cloudant dispose de points d'extrémité API intéressants pour le chargement en masse (et la lecture) de nombreux documents en une seule demande. La lecture de nombreux documents en une seule requête peut être beaucoup plus efficace que la lecture et l'écriture de plusieurs documents à la fois. Le noeud final d'écriture est illustré dans l'exemple suivant:

${database}/_bulk_docs

Son but principal est d'être un élément central de l'algorithme du réplicateur, mais il est aussi disponible pour votre utilisation, et c'est génial.

Avec _bulk_docs, en plus de créer PouchDB, mettez en œuvre la création, la mise à jour et la suppression, même pour les documents uniques de cette façon pour moins de chemins de code.

L'exemple suivant crée un nouveau document, met à jour un second et supprime un troisième document :

curl -XPOST 'https://ACCT.cloudant.com/DB/_bulk_docs' \
     -H "Content-Type: application/json" \
     -d '{"docs":[{"baz":"boo"}, \
         {"_id":"463bd...","foo":"bar"}, \
         {"_id":"ae52d...","_rev":"1-8147...","_deleted": true}]}'

Vous pouvez également récupérer plusieurs documents en une seule demande en envoyant un POST à _all_docs (il existe également un point d'accès relativement nouveau appelé _bulk_get, mais ce point d'accès n'est probablement pas celui que vous souhaitez. C'est là pour un usage interne spécifique).

Pour extraire un ensemble fixe de documents à l'aide de _all_docs, POST avec un corps keys, exécutez la commande suivante:

curl -XPOST 'https://ACCT.cloudant.com/DB/_all_docs' \
     -H "Content-Type: application/json" \
     -d '{"keys":["ab234....","87addef...","76ccad..."]}'

IBM Cloudant (au moment de l'écriture) impose une taille de requête maximale de 11 Mo. Les demandes _bulk_docs qui dépassent cette taille sont rejetées avec un 413: Payload Too Large error.

Pour plus d'informations, consultez les sites Web suivants :

• IBM Cloudant Documents d'opérations en bloc
• Limites de taille de demande et de document IBM Cloudant

Ne vous gâchez pas avec Q, R et N, à moins que vous ne sachiez vraiment ce que vous faites

Ne modifiez pas Q, R et N à moins que vous ne sachiez vraiment ce que vous faites. IBM Cloudant les paramètres de quorum et de partage de la base de données, après que vous les ayez découverts, semblent être des options tentantes pour modifier le comportement de la base de données.

Une cohérence plus forte, je peux certainement définir le quorum d'écriture sur le nombre de répliques ?

Non ! Rappelez-vous qu'il n'existe aucun moyen de fermer la fenêtre d'incohérence dans un cluster.

N'allez pas sur cette voie. Le comportement peut être beaucoup plus difficile à comprendre, en particulier lors des partitions réseau. Si vous utilisez Cloudant-le-service, les valeurs par défaut sont fines pour la plupart des utilisateurs.

Parfois, il est essentiel de modifier le nombre de fragments pour une base de données pour obtenir les meilleures performances possibles. Si vous ne pouvez pas dire pourquoi, vous allez probablement aggraver votre situation.

IBM Cloudant est limité par le taux - laissez cette limite de taux informer votre code

Cloudant-le-service (contrairement à la base de données CouchDB) est vendu sur un modèle de capacité de débit réservé. Cela signifie que vous payez pour le droit d'utiliser jusqu'à un certain débit, plutôt que pour le débit que vous utilisez en fin de compte. La méthode du droit d'utilisation prend un certain temps pour la comprendre. Une comparaison poussée peut être celle d'un contrat de téléphone cellulaire où vous payez un nombre de minutes défini, que vous les utilisiez ou non.

Bien que la comparaison de contrat de téléphone portable ne capture pas l'ensemble de la situation, aucune contrainte n'existe sur la somme des demandes que vous pouvez effectuer sur IBM Cloudant en un mois. La contrainte est la rapidité avec laquelle vous faites les demandes.

C'est vraiment une promesse que vous faites à IBM Cloudant, pas celle que IBM Cloudant vous fait. Vous promettez de ne pas faire plus de demandes par seconde que vous n'en avez accepté au début. Une limite de vitesse maximale, si vous voulez. Si vous transgressez, IBM Cloudant fait échoué vos demandes avec un statut 429: Too Many Requests. Il est de votre responsabilité de rechercher ce dossier et de le traiter, ce qui peut être difficile lorsque plusieurs serveurs d'applications existent. Comment peuvent-ils se coordonner pour s'assurer qu'ils restent collectivement en dessous de la limite de requêtes par seconde?

Les bibliothèques client officielles de IBM Cloudantdisposent d'une mise à disposition intégrée pour ce cas d'utilisation qui peut être activée, à la suite d'une stratégie d'arrêt et de relance.

Cette mise à disposition intégrée est désactivée par défaut pour vous forcer à y réfléchir.

Cependant, si vous vous fiez à cette seule fonctionnalité, vous pourriez être déçu. La stratégie de reprise et de relance n'est utile que dans les cas de transgression temporaire, et non pas en cas de violation persistante des limites de capacité de débit provisionnées.

Votre logique métier doit pouvoir gérer cette condition. Une autre façon de regarder cette problématique est que vous obtenez l'allocation que vous payez. Si cette répartition n'est pas suffisante, la seule solution est de payer une allocation plus élevée.

La capacité de traitement mise à disposition est divisée en trois segments différents: Recherches, Écritures et Requêtes. Une Recherche est une " clé primaire lue, extrayant un document en fonction de son _id. Une Écriture stocke un document ou une pièce jointe sur le disque, et une requête recherche des documents à l'aide d'un index secondaire (tout noeud final d'API ayant une valeur _design ou _find).

Vous obtenez différentes allocations de chacun et les rapports entre eux sont fixes. Ce fait peut être utilisé pour optimiser le coût. Vous obtenez 20 Recherches pour chaque Requête (par seconde). Vous constatez peut-être que vous atteignez principalement la limite Requête, mais vous avez beaucoup de place dans Recherches. Il peut être possible de réduire la dépendance à l'égard des Requêtes en remodelant des données ou en faisant peut-être plus de travail côté client.

Le corollaire ici, c'est que vous ne pouvez pas supposer qu'une bibliothèque ou un cadre tiers optimise les coûts avant la commodité. Les infrastructures côté client qui prennent en charge plusieurs couches de persistance en utilisant des plug-ins sont peu susceptibles d'être au courant de cette situation ou pourraient être incapables de faire de tels compromis.

La vérification de la compatibilité d'une bibliothèque ou d'une infrastructure tiers avant de s'engager sur un outil particulier est une bonne idée.

Il est également utile de comprendre que les taux ne sont pas directement équivalents aux appels de noeud final d'API HTTP. Vous devez vous attendre à ce que, par exemple, une mise à jour globale compte selon son document constitutif écrit.

• Documentation IBM Cloudant sur le cloud public Les plans et la facturation sur IBM

La journalisation vous aide à voir ce qui se passe

IBM Cloudant les journaux de l'API indiquant chaque appel à l'API, ce qui a été demandé et le temps de réponse peuvent être automatiquement envoyés à IBM Cloud Logs à des fins d'analyse et d'établissement de rapports pour les services basés sur IBM Cloud. Ces données sont utiles pour surveiller les volumes de demande, les performances et déterminer si votre application dépasse la capacité allouée pour votre service IBM Cloudant.

IBM Cloud Logs est un service mesuré qui offre une variété de périodes de rétention et de niveaux de consommation de journaux. Les niveaux permettent de conserver les données pour les archiver dans le COS, de les rechercher à froid ou à chaud et de les alerter à des coûts variables. Les tranches et les agrégations de vos données peuvent être intégrées dans des tableaux de bord graphiques afin de vous donner une vue d'ensemble de votre trafic IBM Cloudant. Pour plus d'informations, consultez la documentation suivante :

• Démarrer avec IBM Cloud Logs
• Prise en main d'IBM Cloud Logs Routing
• IBM Cloud Logs Total Cost of Ownership Optimizer(en anglais)

Compressez votre trafic HTTP

IBM Cloudant compresse ses réponses JSON si vous fournissez un en-tête HTTP dans la requête qui indique que votre code peut gérer les données dans ce format :

Request:

> GET /cars/_all_docs?limit=5&include_docs=true HTTP/2
> Host: myhost.cloudant.com
> Accept: */*
> Accept-Encoding: deflate, gzip

Response:                                                                   

< HTTP/2 200
< content-type: application/json
< content-encoding: gzip

Le contenu compressé occupe une fraction de la taille de l'équivalent décompressé, ce qui signifie qu'il faut plus de temps pour transporter les données des serveurs IBM Cloudant vers votre application.

Vous pouvez également choisir de compresser les corps de requête HTTP à l'aide de l'en-tête de contenu codé. Cette pratique permet de réduire les temps de transfert des données lorsque vous écrivez des documents sur IBM Cloudant.