Utilisation d'IBM Cloudant

Si vous n'utilisez jamais IBM Cloudant ou les bases de données NoSQL, parcourez cette introduction et prenez connaissance de quelques-unes des meilleures pratiques avant d'aller plus loin. Elle décrit les points les plus importants à connaître au sujet d'IBM Cloudant et explique comment optimiser son utilisation. Le reste de la documentation part du principe que vous connaissez ces notions de base.

Vous pouvez obtenir plus d'informations sur IBM Cloudant dans les sections suivantes :

Connexion à IBM Cloudant

Pour accéder à IBM Cloudant, vous devez disposer d'un compte IBM Cloud®.

API HTTP

Toutes les demandes adressées à IBM Cloudant sont acheminées sur le Web. Autrement dit, tout système connecté à Internet peut communiquer avec IBM Cloudant. Toutes les bibliothèques de langue pour IBM Cloudant s'apparentent simplement à des encapsuleurs fournissant des avantages d'ordre pratique et linguistique afin de vous aider à utiliser une API simple. Un grand nombre d'utilisateurs choisissent d'utiliser des bibliothèques HTTP brutes pour travailler avec IBM Cloudant.

Pour plus d'informations sur la façon dont IBM Cloudant utilise HTTP, voir HTTP dans Référence d'API.

Les méthodes de demande HTTP prises en charge par IBM Cloudant sont les suivantes :

GET
Demande l'élément spécifié. A l'instar des demandes HTTP standard, le format de l'URL définit les éléments renvoyés. Avec IBM Cloudant, cette définition peut inclure des éléments statiques, des documents de base de données et des informations sur la configuration et les statistiques. Dans la plupart des cas, les informations sont renvoyées sous forme de document JSON.
HEAD
La méthode HEAD extrait l'en-tête HTTP d'une demande GET sans le corps de la réponse.
POST
Téléchargez des données. Dans l'API d'IBM Cloudant, la méthode POST permet de configurer des valeurs, de transférer des documents, de définir des valeurs de document et d'exécuter certaines commandes d'administration.
PUT
Permet de "stocker" une ressource spécifique. Dans l'API d'IBM Cloudant, la méthode PUT permet de créer des objets, y compris des bases de données, des documents, des vues et des documents de conception.
DELETE
Supprime la ressource spécifiée, y compris des documents, des vues, et des documents de conception.
COPY
Une méthode spéciale qui copie les documents et les objets.

Si le client (certains navigateurs, par exemple) ne prend pas en charge l'utilisation des méthodes HTTP, vous pouvez utiliser à la place la méthode POST avec l'en-tête de demande X-HTTP-Method-Override dont la valeur est la méthode HTTP effective.

Erreur relative à une méthode non autorisée

Si vous utilisez un type de requête « HTTP » non pris en charge avec une ressource « URL » qui ne prend pas en charge le type spécifié, une erreur 405 est renvoyée. Cette erreur répertorie les méthodes HTTP prises en charge, comme indiqué dans l'exemple suivant.

Exemple de message d'erreur en réponse à une demande non prise en charge

{
    "error":"method_not_allowed",
    "reason":"Only GET,HEAD allowed"
}

JSON

IBM Cloudant stocke les documents qui utilisent le codage JSON (JavaScript Object Notation), ce qui signifie que tout élément encodé en JSON peut être stocké sous forme de document. Les fichiers qui incluent du contenu multimédia tel que des images, des vidéos et des pistes audio sont appelés objets BLOB (Binary Large Objects). Les objets BLOB peuvent être stockés sous forme de pièces jointes associées à des documents.

Pour plus d'informations sur JSON, consultez le guide JSON.

Systèmes distribués

En utilisant l'API d'IBM Cloudant, vous pouvez interagir avec un ensemble de machines appelé cluster. Les machines d'un cluster doivent être installées dans le même centre de données, mais peuvent se trouver dans différents "pods" du centre de données. L'utilisation de différents pods permet d'améliorer la haute disponibilité d'IBM Cloudant.

L'un des avantages de la mise en cluster est que vous pouvez simplement ajouter des machines lorsque vous avez besoin d'une plus grande puissance de calcul. Cette méthode est généralement plus économique et offre une meilleure tolérance aux pannes que la mise à l'échelle ou l'optimisation d'une seule machine existante.

Pour plus d'informations sur IBM Cloudant et les concepts de systèmes distribués, consultez le guide Théorème CAP.

Réplication

La réplication est une procédure suivie par IBM Cloudant, CouchDB, PouchDB, et d'autres bases de données distribuées. La réplication synchronise l'état de deux bases de données de sorte que leur contenu soit parfaitement identique.

Vous pouvez procéder à la réplication continue. La réplication continue signifie qu'une base de données cible est mise à jour chaque fois que la base de données source change. La réplication continue peut être utilisée pour la sauvegarde de données, l'agrégation de données entre de nombreuses bases de données, ainsi que le partage de données.

Toutefois, la réplication continue implique de vérifier continuellement les modifications apportées à la base de données source. Cette vérification nécessite des appels internes permanents, ce qui a des répercussions négatives sur les performances ou le coût d'utilisation de la base de données.

La réplication continue peut entraîner de nombreux appels internes. Ces appels peuvent affecter les coûts des utilisateurs multi locataires des systèmes IBM Cloudant. La réplication continue est désactivée par défaut.

Utilisation de l'outil approprié pour un travail

IBM Cloudant est un magasin de documents JSON évolutif, durable, hautement disponible et opérationnel doté d'une API HTTP. Il est approprié pour les objectifs suivants : :

  • Alimenter votre application Web dotée la fonctionnalité Always-On.
  • Servir de magasin de données côté serveur pour les applications mobiles.
  • Stocker des données de séries temporelles dans des bases de données chronologiques avant de les archiver dans le système de stockage d'objets et de supprimer les originaux.
  • Stocker des objets d'application au format JSON tandis que des requêtes sont distribuées à partir d'index secondaires.
  • Répliquer des jeux de données dans différentes zones géographiques pour effectuer une reprise après incident, fournir une capacité supplémentaire ou transférer des données à proximité des utilisateurs.

IBM Cloudant n'inclut pas les fonctions suivantes :

Pour plus d'informations, voir le blogue Best and worst practice.

Organisation des documents et des bases de données

Les données d'IBM Cloudant sont organisées selon une hiérarchie de base de données et de documents. Un document est un objet JSON associé à un identificateur unique : son _id. Une base de données est une collection de documents avec un index principal qui permet d'extraire des documents par _id. Elle possède également des index secondaires facultatifs pour l'interrogation des documents selon d'autres attributs de l'objet.

Lorsque les développeurs commencent un projet, ils ont parfois du mal à répondre aux questions suivantes :

  • Combien de données puis-je placer dans un objet unique ?
  • Dois-je stocker différents types de document dans la même collection ou dans une base de données par type de document ?

Un document doit inclure toutes les données relatives à un objet modélisé par votre application (par exemple, un utilisateur, une commande ou un produit). Cette pratique garantit l'extraction de l'intégralité de l'objet à partir de la base de données dans un appel d'API. IBM Cloudant n'a pas le concept de Joints comme une base de données relationnelle, les données ne sont donc pas normalisées. Toutefois, les données peuvent se répéter sur plusieurs objets. Par exemple, un document order peut inclure un sous-ensemble de documents product relatifs aux produits achetés.

Il est courant de stocker plusieurs types d'objets dans une même base de données : par convention, un attribut type indique le type d'objet. Cette option est optimale si vous devez effectuer des requêtes renvoyant plusieurs types d'objets ou qu'une base de données doit être répliquée vers un autre emplacement. Sinon, des bases de données distinctes (par exemple, users, orders, products) peuvent mieux convenir pour obtenir des index secondaires spécifiques à chaque type d'objet.

Si vous stockez des tableaux d'objets dans un même document, déterminez si les éléments de tableau doivent réellement constituer des documents spécifiques. Par exemple, un produit et chaque revue de produit doivent être stockés dans des documents distincts, mais un utilisateur et chacune de ses commandes doivent posséder des documents spécifiques.

Si vous disposez d'un ensemble de données croissant, vous ne souhaiterez probablement pas stocker les données dans une base de données unique en constante évolution. Il est préférable de stocker les données dans des bases de données chronologiques qui permettent d'archiver et de supprimer proprement les anciennes données. La suppression d'un document IBM Cloudant crée un document correspondant en arrière-plan (tombstone). Par conséquent, la suppression de documents ne permet pas de récupérer de l'espace disque. Vous devez plutôt supprimer les bases de données entières.

JSON n'offre pas de méthode native pour stocker les dates ou les horodatages. Sélectionnez votre format de date avec soin si vous avez l'intention de l'utiliser ultérieurement dans des requêtes.

La taille maximale de document est d'un mégaoctet, mais les documents doivent être beaucoup plus petits, généralement quelques kilooctets.

Pour plus d'informations, voir les articles de blogue suivants :

Optimisation à l'aide de l'index primaire

IBM Cloudant propose un index principal sur l'attribut _id de document. Cet index permet d'extraire des documents par _id (GET /db/id) ou une plage de _ids (GET /db/_all_docs?startkey="a"&endkey="z"). En stockant les données dans la clé primaire et en s'assurant que chaque _id est unique, l'index principal peut être utilisé pour extraire des documents et des plages de documents sans indexation secondaire. Consultez la liste de suggestions ci-après :

  • Si votre objet contient un élément unique pouvant être utile comme critère de requête, utilisez-le comme zone d'identificateur _id (par exemple, bob.smith@gmail.com, isbn9780241265543 ou oakland,ca).
  • Si vos objets contiennent une hiérarchie, modélisez-la dans l'identificateur _id: usa:ca:oakland ou books:fiction:9780241265543. La hiérarchie va de la plus grande ville à la plus petite ville, vous pouvez donc utiliser l'index principal pour rechercher toutes les villes dans usa ou toutes les villes dans usa:ca, sans avoir besoin d'indexation secondaire.
  • Si vous stockez des données de séries temporelles, les données de temps du codage au début de l'identificateur _id permettent de trier l'index primaire en fonction du temps (par exemple, 001j40Ox1b2c1B2ubbtm4CsuLB4L35wQ).
  • Les bases de données partitionnées regroupent des documents qui partagent une clé de partitionnement. Une clé de partitionnement doit comporter de nombreuses valeurs et ne doit pas inclure de points sensibles pour éviter de diriger une grande partie du trafic de l'application vers un nombre restreint de partitions.

Pour plus d'informations, voir les articles de blogue suivants :

Requêtes et index secondaires

IBM Cloudant permet d'exécuter des requêtes sur une seule base de données renvoyant un ensemble de documents correspondants et un signet, qui permet d'accéder au bloc suivant de résultats de recherche. Pour obtenir de meilleures performances, vos requêtes doivent s'appuyer sur des index secondaires appropriés. La base de données utilise l'index pour répondre à une requête sans parcourir tous les documents qu'elle contient, ce qui permet d'obtenir des performances beaucoup plus rapides.

Consultez les conseils suivants :

  • Il est parfois difficile de mesurer les performances des requêtes tant que le jeu de données n'est pas suffisamment grand pour exposer les opérations lentes. Générez suffisamment de données réalistes pour pouvoir tester les performances d'indexation et de requête avant de passer en phase de production.
  • IBM Cloudant peut renvoyer des données sans index, mais vous ne devez jamais les utiliser pour les charges de travail de production. Si votre ensemble de résultats inclut l'avertissement, No matching index found. Create an index to optimize query time, vous devez alors revoir votre stratégie d'indexation. Utilisez la fonction explain pour voir l'index sélectionné pour chaque requête.
  • Lorsque plusieurs types d'objets sont présents dans une même base de données, de nombreux cas d'utilisation peuvent être traités par quelques index à l'aide d'attributs fixes. Pour plus d'informations, voir Optimal IBM Cloudant Indexing.
  • Donnez des noms significatifs aux index et indiquez le nom d'index au moment de la requête pour permettre identifier clairement l'index correspondant à la requête de votre application. .

Pour plus d'informations, voir les articles de blogue suivants :