Partitionnement de base de données

Comme indiqué sur la page Comment les données sont-elles stockées? les données sont stockées, les bases de données partitionnées permettent à votre application de co-localiser les documents sur le même shard à l'aide de la clé de partition des documents shard à l'aide de la clé de partition du document. Cette page vous aide à déterminer si votre est adapté à l'utilisation de bases de données partitionnées.

IBM® Cloudant® for IBM Cloud® prend en charge deux types de bases de données :

Non partitionné: le type par défaut. Les documents sont assignés automatiquement par la base de données afin d'équilibrer la charge de travail.
Partitionné: les identifiants des documents contiennent une clé de partition spécifiée par l'application qui affecte la manière dont les données sont allouées aux ensembles.

IBM Cloudant recommande de n'utiliser une base de données partitionnée que lorsque le modèle de données permet un partitionnement logique des documents en un grand nombre de partitions (plus de 500). Pour savoir si votre application peut utiliser des bases de données partitionnées, reportez-vous à la rubrique Détermination de l'adéquation d'une base de données partitionnée.

Du point de vue de l'application, la principale différence entre une base de données non partitionnée et une base de données partitionnée réside dans la manière dont vous pouvez interroger vos données :

Une base de données non partitionnée ne permet de créer et d'interroger que des index secondaires globaux.
Une base de données partitionnée permet de créer et d'interroger des index secondaires globaux et partitionnés.

Ce document contient plus de détails sur les cas d'utilisation de chaque type d'index.

Limites pour les bases de données partitionnées

Les bases de données partitionnées ont des limites quant au nombre d'index et à la taille totale de tous les documents ayant la même clé de partition tous les documents ayant la même clé de partition.

Les requêtes portant sur des partitions ont un délai d'attente imposé par le service plus court que les requêtes globales et une limite plus faible sur le nombre total de documents pouvant être récupérés en une seule fois globales et une limite plus faible sur le nombre total de documents pouvant être récupérés en une seule HTTP requête.

Voir IBM Cloudant Limites pour plus de détails sur ces restrictions.

Raisons d'utiliser une base de données partitionnée

Les bases de données partitionnées sont idéales lorsque votre application bénéficie du regroupement de documents connexes et qu'elle nécessite des performances d'interrogation prévisibles et évolutives.

Une base de données partitionnée permet d'effectuer des requêtes tant au niveau des partitions qu'au niveau global. L'interrogation à l'échelle de la partition tire parti de la colocalisation des documents avec une clé de partition donnée, ce qui permet des performances d'interrogation plus efficaces et évolutives d'une clé de partition donnée, ce qui permet d'effectuer des requêtes plus efficaces et plus évolutives. Pour les charges de travail qui peuvent être exprimées en termes de clé de partition, cela peut réduire considérablement la latence des requêtes et diminuer les coûts réduire considérablement le temps de latence des requêtes et diminuer les coûts.

Le partitionnement est particulièrement utile lorsque votre application a besoin de performances prévisibles à l'échelle prévisibles à l'échelle. Les requêtes à l'échelle de la partition qui utilisent efficacement les index restent rapides même lorsque le jeu de données augmente index restent rapides même lorsque l'ensemble de données s'accroît, et peuvent s'étendre efficacement et peuvent s'étendre efficacement sur un maximum de 64 unités (shards). Les bases de données partitionnées sont donc bien adaptées aux charges de travail à haut débit et à faible latence pour les charges de travail à haut débit et à faible latence.

En règle générale, lorsque l'ensemble des données nécessite de nombreuses unités de base de données, les applications utilisent des requêtes à l'échelle de la partition pour les opérations sensibles à la latence pour les opérations sensibles aux temps de latence, tandis que les requêtes globales sont sont réservées aux tâches moins critiques en termes de temps, telles que le traitement par lots.

Raisons pour lesquelles les bases de données partitionnées ne conviennent pas

Les bases de données partitionnées nécessitent une modélisation soigneuse des données et peuvent nécessiter la duplication des index index. Pour de nombreux cas d'utilisation, cet effort supplémentaire n'est pas rentable.

Bien que les bases de données partitionnées offrent des avantages en termes de performances lorsqu'elles sont utilisées de manière appropriée, elles introduisent des contraintes qui peuvent ne pas correspondre à toutes les charges de travail. Vous devez définir une clé de partition significative pour vos applications, qui regroupe les documents liés et permet une recherche efficace documents apparentés et qui permet d'effectuer des requêtes efficaces. Si chaque document possède une clé unique, ou s'il y a trop peu de clés de partition, les bases de données partitionnées risquent d'être moins performantes que les bases de données non partitionnées que les bases de données non partitionnées.

Les requêtes à portée de partition nécessitent la création d'index partitionnés. Cela peut cela peut nécessiter le maintien d'index globaux et partitionnés, en fonction des schémas d'accès à votre application d'accès de votre application.

Déterminer l'adéquation d'une base de données partitionnée

Vous comprenez maintenant les avantages et les inconvénients des bases de données partitionnées, l'étape suivante consiste à déterminer si votre modèle de données fonctionnera bien avec une base de données partitionnée base de données partitionnée.

Évaluez votre modèle de données et les besoins de votre application en fonction de ces critères pour pour déterminer la pertinence d'une base de données partitionnée :

Il est essentiel que la cardinalité des clés de partition soit élevée: le nombre de clés de partition distinctes doit être largement supérieur au nombre d'unités.
La charge de travail doit être uniformément répartie: si la plupart des requêtes ciblent une seule clé de partition, cela peut créer des points chauds et dégrader les performances.
Les clés de partition doivent regrouper les documents apparentés: si chaque clé ne correspond qu'à un seul document, la partition n'offre que peu d'avantages.

Exemples de bonnes et mauvaises partitions

Afin de mettre cela en pratique, examinons quelques cas d'utilisation et quelques bons et mauvais choix pour une clé de partition clé de partition.

Bons et mauvais choix pour une clé de partition
Cas d'utilisation	Clé de partitionnement	Bon ou mauvais	Motif
Systèmes de commerce électronique - commandes	`customer_id`	Bien	La cardinalité est élevée et les requêtes sont réparties entre de nombreux clients.
Systèmes de commerce électronique - commandes	`order_id`	Incorrect	Un document par partition; pas de regroupement ni de réutilisation.
Systèmes de commerce électronique - commandes	`status`	Incorrect	La faible cardinalité des valeurs de statut (provisoire, payé, remboursé, annulé) crée trop peu de partitions.
Systèmes de commerce électronique - commandes	`country_code`	Incorrect	Faible cardinalité; quelques pays dominent le trafic.
IOT - relevés de capteur	`device_id`	Bien	De nombreux appareils génèrent des données, ce qui répartit la charge de manière uniforme.
IOT - relevés de capteur	`reading_id`	Incorrect	Unique par document; les partitions ne contiennent qu'un seul élément.
IOT - relevés de capteur	`date`	Incorrect	La plupart des requêtes portent sur des dates récentes, ce qui crée des points chauds.
IOT - relevés de capteur	`region`	Incorrect	Quelques régions peuvent dominer le trafic, ce qui entraîne un déséquilibre.

Il existe certains cas d'utilisation où il n'existe aucun choix viable pour une clé de partition. Dans ces situations, une base de données non partitionnée constitue le meilleur choix. Par exemple, une base de données stockant les adresses e-mail, les hachages de mot de passe et les dates de dernière connexion des utilisateurs. Aucun de ces champs ne constitue une clé de partitionnement appropriée; il faut donc utiliser à la place une base de données non partitionnée.

Création de bases de données et d'index partitionnés

Vous devez décider si vous souhaitez partitionner la base de données lors de sa création. Lorsque vous créez une base de données, utilisez le paramètre de chaîne de requête partitioned pour indiquer si la base de données est partitionnée. La valeur par défaut de partitioned est false.

De même, un index est soit global, soit partitionné lorsque vous créez un index à l'aide du champ partitioned dans votre document de conception. Tous les tous les index du document de conception héritent du champ partitioned du document de conception du document de conception. Lorsque vous interrogez un index partitionné, vous utilisez des requêtes à l'échelle de la partition qui incluent la clé de partition à interroger dans la requête.

Le type de partitionnement d'un index ou d'une base de données ne peut pas être modifié après sa création.

Les requêtes portant sur des partitions ne peuvent être effectuées que sur des index partitionnés. De même, les requêtes globales ne peuvent être effectuées que sur des index globaux.

Interrogation

IBM Cloudant prend en charge les requêtes globales et les requêtes à l'échelle d'une partition. Pour utiliser efficacement les deux types d'index, des index distincts doivent être créés pour chaque champ d'application de la requête être créés pour chaque champ d'application de la requête.

Les requêtes globales donnent de bons résultats dans les bases de données dont le nombre de tessons est faible (16 ou moins), mais elles sont de moins en moins adaptées aux opérations sensibles à la latence au fur et à mesure que le nombre de nombre d'unités. En revanche, les requêtes à l'échelle de la partition s'adaptent efficacement à un plus grand nombre de tessons avec des nombres plus importants de tessons et constituent l'option préférée pour les applications qui nécessitent des performances des performances prévisibles et à faible latence pour les grands ensembles de données.

Pour bénéficier de l'interrogation à l'échelle de la partition, la majorité des requêtes d'application doivent cibler des clés de partition spécifiques. Cela permet à la base de données de tirer parti de la colocalisation des documents et d'offrir des performances constantes à l'échelle de la colocalisation des documents et d'offrir des performances constantes à l'échelle.

Voir Comment le sharding affecte les performances de la base de données pour plus de détails sur la façon dont les requêtes globales et les requêtes à l'échelle de la partition affectent les performances des opérations de la base de données.

Interrogation globale

Vous pouvez effectuer des requêtes globales à l'aide de :

La création d'un index global est une option par défaut, mais vous pouvez créer explicitement un index global à l'aide de "options.partitioned": false dans votre document de conception :

{
  "options": {
    "partitioned": false
  },
  "views": {
    "by-device": {
      "map": "function(doc) { emit(doc.deviceID, doc.infrastructureID) }"
    }
  }
}

Interrogation à l'échelle d'une partition

Vous pouvez effectuer des requêtes à l'échelle de la partition en utilisant :

Pour créer un index partitionné qui prend en charge les requêtes à portée de partition, spécifiez "options.partitioned": true dans votre document de conception :

{
  "options": {
    "partitioned": true
  },
  "views": {
    "by-device": {
      "map": "function(doc) { emit(doc.deviceID, doc.infrastructureID) }"
    }
  }
}

Tutoriels relatifs aux bases de données partitionnées

Les bases de données partitionnées peuvent être difficiles à comprendre dans l'abstrait. Vous pouvez voir ces concepts en action dans ces deux exemples :

Lisez Creating an IoT historian using partitioned databases pour une plongée en profondeur dans les bases de données partitionnées avec des exemples dans plusieurs langages de programmation.
Découvrez les bases de données partitionnées et l' Node.js s dans cet article de blog, qui explique notamment comment créer une base de données partitionnée, effectuer des recherches, utiliser des vues et créer un index global.