Comprendre l'API que vous ciblez

Vous pouvez utiliser Java™, Python, Goou Node.js ou tout autre langage ou plateforme spécifique à un cas d'utilisation. L'une de ces langues est très probablement fournie avec des bibliothèques côté client qui intègrent facilement l'accès IBM Cloudant, en suivant les conventions que vous attendez de vos outils. Ces langages sont magnigiques pour l'efficacité du programmeur, mais ils cachent également l'API de la vue.

Cette abstraction est ce que vous voulez, toute la raison de l'utilisation d'une bibliothèque client est de vous sauver de façon répétée et fastidieuse de la chaudière. Cependant, vous devez comprendre que l'API sous-jacente joue un rôle essentiel lors du dépannage et du signalement des problèmes. Lorsque vous signalez un incident suspecté à IBM Cloudant, cela nous aide et vous aide si vous pouvez nous fournir un moyen de reproduire le problème.

Cette requête ne signifie pas couper et coller un bloc important de la source Java™ de votre application dans un ticket de support, car nous ne sommes probablement pas en mesure de le générer. De plus, votre code côté client introduit des incertitudes quant à l'endroit où le problème pourrait être, de votre côté ou de notre côté ?

Au lieu de cela, les équipes d'assistance d' IBM Cloudant demandent généralement une série d'appels API, de préférence sous la forme d'une série de commandes curl qu'elles peuvent exécuter, afin de reproduire le problème. L'adoption de cette approche pour l'identification et la résolution des problèmes en tant que règle vous permet également de déterminer plus facilement où les problèmes sont défaillants. Si votre code se comporte de façon inattendue, essayez de reproduire le problème en utilisant uniquement l'accès direct à l'API.

Si vous ne le pouvez pas, le problème n'est pas celui du service IBM Cloudant lui-même.

Si vous enquêtez sur un problème de performances, consultez les journaux fournis par IBM Cloud®. Si les journaux montrent que vos demandes sont traitées rapidement par IBM Cloudant, mais que votre application est lente, la racine de ce problème réside dans votre code d'application côté client. Voir la règle relative au sujet de la consignation et surveillance.

Si vous pensez qu'un problème réside dans une bibliothèque client officiellement prise en charge, essayez de construire un petit exemple de code autonome qui illustre le problème. Dans cet exemple de code autonome, utilisez le moins de dépendances possibles. Si vous utilisez Java™, cela nous aiderait beaucoup si vous pouviez utiliser un cadre de test minimal pour mettre en évidence les problèmes liés à la bibliothèque.

À l'occasion, IBM Cloudant reçoit des tickets de support indiquant que " IBM Cloudant est en panne car mon application est lente " sans beaucoup de preuves à l'appui. Presque toujours, ce cas peut être retracé à des problèmes dans le code de l'application côté client, ou des idées fausses sur le fonctionnement de IBM Cloudant.

Pas toujours, mais presque toujours.

En comprenant mieux l'API, vous pouvez également acquérir de l'expérience dans le comportement de IBM Cloudant, notamment en termes de performances. Si vous utilisez une bibliothèque client, vous devez au moins viser à savoir quelles demandes HTTP sont générées par un appel de fonction spécifique. Pour plus d'informations, consultez les sites Web suivants :

• IBM Cloudant Documentation sur les API
• Journalisation de l'intégration
• Article de blogue sur la consignation

Les documents doivent regrouper des données qui pour la plupart se modifient ensemble

Lorsque vous commencez à modéliser vos données, tôt ou tard, vous rencontrerez le problème de la structure de vos documents. Vous savez désormais que IBM Cloudant n'impose aucune normalisation et qu'il ne prend pas en charge les transactions telles que vous les connaissez, par exemple, Postgres. La tentation peut être d'entasser autant que possible dans chaque document, ce qui permettrait également d'économiser sur l'utilisation du protocole HTTP.

Cette pratique est souvent une mauvaise idée.

Si votre modèle regroupe des informations qui ne changent pas ensemble, vous êtes plus susceptible de souffrir de conflits de mise à jour.

Prenez en compte une situation où vous avez des utilisateurs, chacun avec un ensemble de commandes associées. Un moyen peut être de représenter les commandes sous la forme d'un tableau dans le document utilisateur :

{ // DON'T DO THIS
  "customer_id": 65522389,
  "orders": [
    {
      "order_id": 887865,
      "items": [
        {
          "item_id": 9982,
          "item_name": "Iron sprocket",
          "cost": 53.0
        },
        {
          "item_id": 2932,
          "item_name": "Rubber wedge",
          "cost": 3.0
        }
      ]
    }
  ]
}

Pour ajouter une commande, j'ai besoin d'extraire le document complet, de désorganiser le fichier JSON, d'ajouter l'élément, de rassembler le nouveau JSON et de l'envoyer en tant que mise à jour. Si je suis le seul à le faire, cela pourrait fonctionner pendant un certain temps. Si le document est mis à jour simultanément ou en cours de réplication, il se peut que des conflits de mise à jour soient possibles.

En revanche, gardez les commandes séparées comme leur propre type de document, en faisant référence à l'ID client. Le modèle est immuable. Pour ajouter une commande, je crée un nouveau document de commande dans la base de données, ce qui ne peut pas entraîner de conflits.

Pour pouvoir récupérer toutes les commandes d'un client spécifique, nous pouvons utiliser une vue, ce que nous verrons plus tard.

Évitez les constructions qui reposent sur des mises à jour de parties de documents existants, dans la mesure du possible. Les modèles de données inadéquats sont souvent difficiles à modifier une fois que le système est en production.

Le schéma précédent peut être résolu efficacement à l'aide de bases de données partitionnées, qui sont abordées plus en détail ultérieurement.

Pour plus d'informations, consultez la documentation suivante :

• Guide IBM Cloudant sur la modélisation des données
• Partitions de base de données

Conserver les documents dans une petite taille

IBM Cloudant impose une taille de doc maximale de 1 Mo. Cette limite ne signifie pas qu'une taille de document proche de 1Mo est une bonne idée. Au contraire, si vous trouvez que vous créez des documents qui dépassent les Ko à un seul chiffre, vous devez probablement revoir votre modèle. Plusieurs éléments de IBM Cloudant deviennent moins performants à mesure que les documents augmentent. Le décodage JSON est coûteux, par exemple.

Regardons les sections suivantes : Les documents doivent regrouper des données qui pour la plupart se modifient ensemble et conserver les documents de petite taille. Il convient de souligner que les modèles qui reposent sur les mises à jour ont une limite de volume maximale de 1 Mo, la limite pour la taille du document. Cette taille n'est pas ce que vous voulez.

Évitez d'utiliser des pièces jointes

IBM Cloudant prend en charge le stockage des pièces jointes aux côtés de documents, une fonction de longue date héritée de CouchDB. Si vous utilisez IBM Cloudant comme backend pour une application web, vous pouvez également stocker de petites icônes et d'autres ressources statiques, telles que des fichiers CSS et JavaScript, avec les données.

Vous devez prendre en compte quelques éléments avant d'utiliser des pièces jointes dans IBM Cloudant aujourd'hui, en particulier si vous recherchez des actifs plus importants tels que des images et des vidéos :

1. IBM Cloudant est coûteux en tant que magasin de blocs.
2. L'implémentation interne de IBM Cloudant n'est pas efficace pour gérer de grandes quantités de données binaires.

Donc, c'est lent et cher.

IBM Cloudant est acceptable pour les petits actifs et pour une utilisation occasionnelle. En règle générale, si vous devez stocker des données binaires aux côtés de documents IBM Cloudant, il est préférable d'utiliser une solution distincte plus adaptée à cette fin. Vous devez uniquement enregistrer les métadonnées de la pièce jointe dans le document « IBM Cloudant ». Oui, cela signifie que vous devez écrire un code supplémentaire pour télécharger la pièce jointe à un magasin de blocs approprié de votre choix. Vérifiez qu'elle a réussi avant de stocker le jeton ou l'URL vers la pièce jointe dans le document IBM Cloudant.

Vos bases de données sont plus petites, moins chères, plus rapides et plus faciles à reproduire. Pour plus d'informations, consultez les sites Web suivants :

• IBM Cloudant docs dans les pièces jointes
• Déconnexion des pièces jointes IBM Cloudant à Object Storage

Moins de bases de données sont meilleures que plusieurs

Si vous le pouvez, limitez le nombre de bases de données par compte IBM Cloudant à 500 ou moins. Bien que ce nombre ne soit pas magique (IBM Cloudant peut gérer plus efficacement), il existe plusieurs cas d'utilisation qui sont affectés par un grand nombre de bases de données dans un compte.

Le planificateur du réplicateur dispose d'un nombre limité de travaux de réplication simultanés qu'il est prêt à exécuter. Au fur et à mesure que le nombre de bases de données augmente, le temps d'attente de réplication est susceptible d'augmenter si vous essayez de répliquer toutes les données contenues dans un compte.

Le revers de la médaille est l'aspect opérationnel : l'équipe des opérations de IBM Cloudant s'appuie également sur la réplication pour se déplacer vers les comptes. En conservant le nombre de bases de données, vous nous aiderez à vous aider si vous avez besoin de déplacer votre compte d'un emplacement à un autre.

Par conséquent, lorsque vous devez utiliser une seule base de données et distinguer différents types de document en utilisant des vues, et quand devez-vous utiliser plusieurs bases de données pour modéliser vos données ? IBM Cloudant ne peut pas fédérer les vues dans plusieurs bases de données. Si vous disposez de données sans rapport entre elles, qui ne peuvent jamais être « jointes » ni interrogées conjointement, celles-ci peuvent alors être réparties entre plusieurs bases de données.

Si vous avez un ensemble de données sans cesse croissant (comme un journal, des relevés de capteurs ou d'autres types de séries chronologiques), ce n'est pas aussi une bonne idée de créer une base de données unique, sans cesse croissante. Ce type de cas d'utilisation nécessite du time-boxing, que nous couvrons plus en détail plus tard.

Évitez à tout prix l'anti-modèle consistant à créer une base de données par utilisateur

Si vous développez un service multi-utilisateurs sur IBM Cloudant, il peut être tentant de permettre à chaque utilisateur de stocker ses données dans une base de données distincte, sous le compte de l'application. Cela fonctionne bien, surtout si le nombre d'utilisateurs est faible.

Maintenant, ajoutez la nécessité de dériver des outils analytiques inter-utilisateurs. Pour ce faire, vous devez répliquer toutes les bases de données utilisateur dans une seule base de données d'analyse. Tout va bien. Cette application a soudainement connu un succès, et le nombre d'utilisateurs a augmenté de 150 à 20 000. Vous avez 20 000 réplications uniquement pour conserver le courant de base de données d'analyse. Si vous souhaitez également exécuter une configuration de reprise après incident active, ajoutez 20 000 autres réplications, et le système ne fonctionne plus.

A la place, les données utilisateur multiplex dans moins de bases de données, ou les utilisateurs de fragments dans un ensemble de bases de données ou de comptes, ou les deux. De cette façon, vous n'avez pas besoin de répliquer pour fournir une base de données d'analyse, mais l'authentification devient plus complexe car IBM Cloudant fournit uniquement l'authentification au niveau de la base de données.

Cela vaut la peine de dire que l'approche " base de données par utilisateur " est tentante car les permissions IBM Cloudant sont " par base de données ", mais ce n'est pas vraiment la faute des utilisateurs que ce modèle ait émergé.

Éviter d'écrire des fonctions de réduction JavaScript personnalisées

Les vues MapReduce dans IBM Cloudant sont géniales. Cependant, avec un grand pouvoir viennent de grandes responsabilités. La partie de mappe d'une vue MapReduce est générée de façon incrémentielle, si bien que le code de mauvaise qualité dans la mappe n'affecte que le temps d'indexation, et non pas le temps de requête. Malheureusement, la partie de réduction s'exécute au moment de la requête. IBM Cloudant fournit un ensemble de fonctions de réduction intégrées qui sont implémentées en interne dans Erlang. Ces fonctions sont performantes à l'échelle alors que vos fonctions JavaScript réduites à la main ne le sont pas.

Si vous vous retrouvez à écrire des fonctions reduce, arrêtez-vous un instant et demandez-vous s'il n'est pas possible de réorganiser vos données de manière à ce que l'écriture de ces fonctions ne soit plus nécessaire. Ou pour que vous soyez en mesure de compter sur les réducteurs intégrés.

Les vues sur des bases de données partitionnées ne prennent pas en charge les opérations « reduce » personnalisées, ce qui est l'un des facteurs contribuant à l'accélération significative des requêtes que seules ces vues peuvent offrir.

Pour plus d'informations, voir la documentation IBM Cloudant sur , qui réduit.

Utiliser des bases de données en boîte pour des ensembles de données sans cesse croissants

Il n'est généralement pas une bonne idée d'avoir une base de données sans cesse croissante dans IBM Cloudant. Les grandes bases de données peuvent être difficiles à sauvegarder, exiger des " refragmentations " pour maintenir une bonne performance au fur et à mesure qu'elles grandisse, et souffrir de temps de création d'index longs.

Une façon d'atténuer ce problème est d'avoir plusieurs bases de données plus petites, avec un modèle commun qui est des bases de données à temps plein : un ensemble de données important est divisé en bases de données plus petites, chacune représentant une fenêtre de temps, par exemple, un mois.

• orders_2019_01
• orders_2019_02
• orders_2019_02

De nouvelles données sont écrites dans la base de données de ce mois-ci et les requêtes pour les données historiques peuvent être dirigées vers les bases de données des mois précédents. Lorsque les données d'un mois ne présentent plus d'intérêt, elles peuvent être archivées dans Object Storage, la base de données IBM Cloudant mensuelle est supprimée et l'espace disque récupéré. Pour plus d'informations, consultez le site Web suivant.

• Blogue de stockage de données de séries temporelles