Tables élastiques pour les développeurs

  • Article

Les tables élastiques Dataverse sont optimisées par Azure Cosmos DB. Elles évoluent automatiquement horizontalement pour gérer de grandes quantités de données et des niveaux de débit élevés avec une faible latence. Les tables élastiques conviennent aux applications ayant des charges de travail imprévisibles, sporadiques ou en croissance rapide.

Cet article se concentre sur les informations que les développeurs doivent connaître sur l’utilisation des tables élastiques. Pour plus d’informations sur les fonctionnalités des tables élastiques et sur ce qui est pris en charge, consultez Créer et modifier des tables élastiques

Quand utiliser les tables élastiques

Les exigences spécifiques de vos données et de votre application déterminent si vous devez utiliser des tables élastiques ou des tables standard.

Utilisez des tables élastiques dans ces situations :

  • Vos données peuvent être non structurées ou semi-structurées, ou votre modèle de données peut être en constante évolution.
  • Vous avez besoin d’une mise à l’échelle horizontale pour gérer la croissance de la charge de travail au fil du temps ou une charge de travail en rafales à un moment donné.
  • vous devez gérer un volume élevé de demandes de lecture et d’écriture.

Utilisez des tables standard dans ces situations :

  • votre application nécessite une forte cohérence des données ;
  • votre application exige une modélisation relationnelle et une capacité transactionnelle entre les tables et pendant les étapes d’exécution du plug-in ;
  • votre application nécessite des jointures complexes.

Une combinaison de tables élastiques et standard peut être appropriée pour vos données et votre application.

Pour plus d’informations sur les différences dans la modélisation des tables élastiques, voir :

Partitionnement et mise à l’échelle horizontale

Les tables élastiques utilisent le partitionnement Azure Cosmos DB pour mettre à l’échelle des tables individuelles afin de répondre aux exigences de performances de votre application. Toutes les tables élastiques contiennent une colonne de chaîne Partition Id définie par le système. Cette colonne a le nom de schéma PartitionId et le nom logique partitionid.

Azure Cosmos DB garantit que les lignes d’une table sont divisées en sous-ensembles distincts, en fonction de la valeur de la colonne partitionid pour chaque ligne. Ces sous-ensembles sont appelés partitions logiques.

Important

Pour obtenir les meilleures performances possibles avec les tables élastiques, vous devez choisir et appliquer systématiquement une stratégie de partitionnement. Si vous ne définissez pas de valeur partitionid pour chaque ligne, la valeur reste nulle et vous ne pouvez pas la modifier ultérieurement.

Si vous utilisez une valeur personnalisée partitionid, la valeur de la clé primaire n’a pas de contrainte d’unicité. En d’autres termes, vous pouvez créer plusieurs enregistrements ayant la même clé primaire, mais avec des valeurs partitionid différentes. Il est important de comprendre que les références uniques pour les tables élastiques sont une combinaison de la clé primaire et de la valeur partitionid.

Choisir une valeur partitionid

La valeur partitionid que vous devez utiliser dépend de la nature de vos données. Une partition logique dans une table élastique consiste en un ensemble de lignes qui ont la même valeur partitionid. Par exemple, dans une table qui contient des données sur différents produits, vous pouvez utiliser la catégorie de produits comme valeur partitionid pour la table. Dans ce cas, les groupes d’éléments qui ont des valeurs spécifiques pour la catégorie de produit, tels que Clothing, Books, Electronic Appliances et Pet supplies, forment des partitions logiques distinctes.

Dataverse gère de manière transparente et automatique les partitions logiques associées à une table. Il n’y a pas de limite au nombre de partitions logiques que vous pouvez avoir dans une table. De plus, il n’y a aucun risque qu’une partition logique soit supprimée si ses lignes sous-jacentes sont supprimées.

Pour toutes les tables élastiques, la colonne partitionid doit répondre à ces critères :

  • Les valeurs qu’elle contient ne changent pas. Une fois qu’une ligne a été créée avec une valeur partitionid, Vous ne pouvez plus la modifier.
  • Elle a une valeur de cardinalité élevée. En d’autres termes, la propriété doit avoir un large éventail de valeurs possibles. Chaque partition logique peut stocker 20 gigaoctets (Go) de données. Par conséquent, en choisissant une valeur partitionid ayant une large plage de valeurs possibles, vous vous assurez que la table peut évoluer sans atteindre les limites d’une partition logique spécifique.
  • Elle répartit les données aussi uniformément que possible entre toutes les partitions logiques.
  • Aucune valeur n’est supérieure à 1 024 octets.
  • Aucune valeur ne contient des barres obliques (/), des crochets pointus (<, >), des astérisques (*), des signes de pourcentage (%), des esperluettes (&), des deux points (:), des barres obliques inverses (\), des points d’interrogation (?), ou des signes plus (+). Ces caractères ne sont pas pris en charge pour les clés secondaires.

Si une valeur partitionid n’est pas spécifiée pour une ligne, Dataverse utilise la valeur de la clé primaire comme valeur par défaut partitionid. Pour les tables à forte écriture de n’importe quelle taille, ou pour les cas où les lignes sont principalement récupérées à l’aide de la clé primaire, la clé primaire est un excellent choix pour la colonne partitionid.

Niveau de cohérence

La table élastique prend en charge la cohérence pendant une session logique. Une session logique est une connexion entre un client et Dataverse. Lorsqu’un client effectue une opération d’écriture sur une table élastique, il reçoit un jeton de session qui identifie de manière unique la session logique. Pour assurer une bonne cohérence, vous devez maintenir le contexte logique de la session en incluant le jeton de la session dans toutes les demandes ultérieures.

Les jetons de session garantissent que toutes les opérations de lecture effectuées dans le même contexte de session logique renvoient l’écriture la plus récente effectuée au cours de cette session logique. En d’autres termes, les jetons de session garantissent que les lectures respectent toujours les garanties read-your-writes, et write-follows-reads au cours d’une session logique. Si une autre session logique effectue une opération d’écriture, les autres sessions logiques peuvent ne pas détecter immédiatement ces modifications.

Le jeton de session est disponible en tant que valeur x-ms-session-token dans la réponse de toutes les opérations d’écriture. Pour récupérer la ligne la plus récente, vous devez inclure cette valeur lorsque vous récupérez les données.

  • Si vous utilisez le kit de développement logiciel (SDK), utilisez le paramètre facultatif SessionToken.
  • Si vous utilisez l’API web, utilisez l’en-tête de demande MSCRM.SessionToken.

Si vous récupérez un enregistrement sans jeton de session, il se peut que les modifications récemment apportées ne soient pas appliquées. Au lieu de cela, elles peuvent être renvoyés dans des demandes ultérieures.

En savoir plus sur l’utilisation du jeton de session.

Comportement transactionnel

Les tables élastiques ne prennent pas en charge les transactions multi-enregistrements. Pour l’exécution d’une seule demande, plusieurs opérations d’écriture qui se produisent au cours de la même phase de plug-in synchrone ou au cours de différentes phases de plug-in synchrone ne sont pas transactionnelles les unes par rapport aux autres.

Par exemple, vous avez une étape de plug-in synchrone qui est enregistrée sur la phase PostOperation du message Create sur une table élastique. Dans ce cas, une erreur qui se produit dans le plug-in n’annule pas l’enregistrement créé dans Dataverse. Vous devez toujours éviter d’annuler intentionnellement une opération en lançant une exception InvalidPluginExecutionExceptionInvalidPluginExecutionException dans la phase synchrone PreOperation ou PostOperation. Si l’erreur est renvoyée après l’opération Main, la demande renvoie une erreur, mais l’opération de données est une réussite. Toutes opérations d’écriture lancées dans la phase PreOperation aboutissent.

Cependant, vous devez toujours appliquer les règles de validation dans un plug-in enregistré pour la phase PreValidation synchrone. La validation est le but de cette étape. Même si vous utilisez des tables élastiques, la requête renvoie une erreur et l’opération de données ne commence pas. En savoir plus sur le pipeline d’exécution d’événements.

Les tables élastiques ne prennent pas non plus en charge les requêtes de regroupement dans une transaction de base de données unique qui utilise la classe classe ExecuteTransactionRequest du kit de développement logiciel (SDK) ou dans une API web $batch operation changeset. Actuellement, ces opérations réussissent, mais ne sont pas atomiques. À l’avenir, une erreur sera renvoyée.

Les tables élastiques ne prennent pas en charge l’insertion profonde, contrairement aux tables standard. Vous obtiendrez cette erreur : Cannot create related entities. Create has to be called individually for each entity.

Pour en savoir plus sur les transactions à plusieurs enregistrements, voir :

Faire expirer les données à l’aide de la durée de vie

Dataverse inclut automatiquement une colonne d’entiers pour la Durée de vie avec les tables élastiques. Cette colonne a le nom de schéma TTLInSeconds et le nom logique ttlinseconds.

Lorsqu’une valeur est définie dans cette colonne, elle définit la durée, en secondes, avant que la ligne n’expire et ne soit automatiquement supprimée de la base de données. Si aucune valeur n’est définie, l’enregistrement persiste indéfiniment, tout comme les tables standard.

Scénario

Les exemples des articles connexes utilisent ce scénario.

Contoso exploite un grand nombre d’appareil de l’Internet des objets (IoT) que l’entreprise a déployés dans le monde entier. Contoso doit stocker et interroger de grandes quantités de données de capteurs émises par les appareils IoT afin de pouvoir surveiller leur intégrité et recueillir d’autres informations.

Pour stocker et interroger le grand volume de données IoT, Contoso crée une table élastique qui est nommée contoso_SensorData. Elle utilise une colonne de chaîne nommée contoso_DeviceId avec la valeur partitionid pour chaque ligne correspondant à un appareil. Étant donné que chaque valeur contoso_DeviceId est unique pour un appareil et que Contoso effectue des requêtes principalement dans le contexte d’une valeur contoso_DeviceId donnée, il s’agit d’une bonne stratégie de partition pour l’ensemble du jeu de données.

Articles associés :

Problèmes connus

Les problèmes connus suivants concernant les tables élastiques doivent être résolus avant que cette fonctionnalité ne soit disponible de manière générale.

Aucune erreur n’est renvoyée lorsque les opérations sur les données des tables élastiques sont regroupées dans une transaction

Dataverse ne renvoie pas d’erreur lorsque vous regroupez des opérations de données à l’aide de la classe ExecuteTransactionRequest du kit de développement logiciel (SDK) ou d’un $batch operation changset d’une API web. Bien que ces opérations de données soient effectuées, aucune transaction n’est appliquée. Comme aucune transaction ne peut être appliquée, ces opérations doivent échouer et renvoyer une erreur.

Aucune valeur x-ms-session-token n’est renvoyée pour les opérations de suppression

Dataverse ne renvoie pas la valeur x-ms-session-token pour les opérations de suppression. En savoir plus sur la façon dont cette valeur est utilisée pour gérer la cohérence des données.

Le paramètre facultatif partitionId n’est pas disponible pour tous les messages

Lorsqu’un enregistrement utilisant une valeur partitionid doit être identifié, comme pour les opérations Retrieve, Update ou Upsert, vous avez besoin d’un moyen pour référencer la valeur partitionid. Dans ce cas, vous pouvez utiliser le clé secondaire pour référencer l’enregistrement. Si vous préférez, vous devriez également pouvoir utiliser le style de paramètre facultatif partitionId. Actuellement, seules les opérations Retrieve et Delete prennent en charge l’utilisation du paramètre facultatif partitionId . En savoir plus sur l’utilisation du paramètre partitionId.

Lorsque la durée de vie (TTL) est utilisée sur une ligne, la ligne est supprimée de la table élastique lorsque la TTL a expiré. Si elle est synchronisée avec un lac de données à l’aide de Synapse Link pour Dataverse avant l’expiration de la TTL, elle ne sera pas supprimée du lac de données.

Questions fréquentes

Cette section comprendra toutes les questions fréquemment posées (FAQ). Si vous avez une question qui n’est pas abordée dans la documentation, sélectionnez le bouton Cette page dans la section Commentaires en bas de page. Vous devez avoir un compte GitHub pour soumettre des questions de cette façon.

Étapes suivantes

Créer des tables élastiques à l’aide de code

Voir aussi

Utiliser des tables élastiques à l’aide de code
Interroger les colonnes JSON dans les tables élastiques
Messages d’opération en bloc
Exemple de code de table élastique
Partitionnement et mise à l’échelle horizontale dans Azure Cosmos DB