Partager via

Tables élastiques pour les développeurs

Les tables élastiques Dataverse sont alimenté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 qui ont des charges de travail imprévisibles, irrégulières ou en croissance rapide.

Cet article se concentre sur les informations que les développeurs doivent savoir sur l’utilisation de tables élastiques. Pour plus d’informations sur les fonctionnalités des tables élastiques et ce qui est pris en charge, accédez à Créer et modifier des tables élastiques.

Quand utiliser des 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 changer constamment.
  • 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 rafale à 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 cohérence forte des données.
  • Votre application nécessite une modélisation relationnelle et nécessite une fonctionnalité transactionnelle entre les tables ou pendant l’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, accédez à :

Partitionnement et mise à l’échelle horizontale

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

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

Important

Pour obtenir les meilleures performances disponibles avec des tables élastiques, vous devez choisir et appliquer de manière cohérente une stratégie de partitionnement. Si vous ne définissez pas de partitionid valeur pour chaque ligne, la valeur reste null et vous ne pourrez pas la modifier ultérieurement.

Si vous utilisez une valeur personnalisée partitionid , la valeur de clé primaire n’a pas de contrainte unique. En d’autres termes, vous pouvez créer plusieurs enregistrements qui ont la même clé primaire, mais des valeurs différentes partitionid . 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 partitionid valeur.

Choix d’une valeur partitionId

La partitionid valeur que vous devez utiliser dépend de la nature de vos données. Une partition logique dans une table élastique se compose d’un ensemble de lignes qui ont la même partitionid valeur. Par exemple, dans une table qui contient des données sur différents produits, vous pouvez utiliser la catégorie de produit comme partitionid valeur pour la table. Dans ce cas, les groupes d’éléments qui ont des valeurs spécifiques pour la catégorie de produit, telles que Clothing, , BooksElectronic Applianceset 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’existe aucune limite quant au nombre de partitions logiques que vous pouvez avoir dans une table. En outre, il n’existe aucun risque qu’une partition logique soit supprimée si ses lignes sous-jacentes sont supprimées.

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

  • Les valeurs qu’il contient ne changent pas. Une fois qu’une ligne a une partitionid valeur, vous ne pouvez pas la modifier.
  • Il 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 partitionid valeur qui a une large gamme de valeurs possibles, vous assurez que la table peut être mise à l’échelle sans atteindre les limites d’une partition logique spécifique.
  • Il 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 de barres obliques (/), crochets d’angle (<, >), astérisques (*), signes de pourcentage (%), ampersands (>), deux-points (:), barres obliques inverses (\), points d’interrogation ( ?) ou signes plus (+). Ces caractères ne sont pas pris en charge pour les touches alternatives.

Si aucune partitionid valeur n’est spécifiée pour une ligne, Dataverse utilise la valeur de 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 offre une cohérence forte 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 avoir une cohérence forte, vous devez conserver le contexte de session logique en incluant le jeton de session avec toutes les demandes suivantes.

Les jetons de session garantissent que toutes les opérations de lecture effectuées pendant le même contexte de session logique retournent l’écriture la plus récente effectuée pendant 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, d’autres sessions logiques peuvent ne pas détecter immédiatement ces modifications.

Le jeton de session est disponible sous forme de x-ms-session-token valeur dans la réponse de toutes les opérations d’écriture. Pour récupérer la ligne la plus up-to-date, vous devez inclure cette valeur lorsque vous récupérez des données.

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

Si vous récupérez un enregistrement sans jeton de session, les modifications récemment appliquées peuvent ne pas être appliquées. Au lieu de cela, ils peuvent être retournés dans les demandes suivantes.

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 une exécution de requête unique, plusieurs opérations d’écriture qui se produisent au cours de la même phase de plug-in synchrone ou pendant différentes phases de plug-in synchrones ne sont pas transactionnelles entre elles.

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 ne restaure pas l’enregistrement créé dans Dataverse. Vous devez toujours éviter d’annuler intentionnellement toute opération en lançant une InvalidPluginExecutionException pendant l’étape PreOperation ou PostOperation synchrone. Si l’erreur est levée après l’opération Main , la requête retourne une erreur, mais l’opération de données réussit. Toutes les opérations d’écriture démarrées à l’étape PreOperation réussissent.

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

Les tables élastiques ne prennent pas également en charge le regroupement de demandes dans une transaction de base de données unique qui utilise la classe ExecuteTransactionRequest du SDK ou dans un ensemble d’opérations d’API $batch web. 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 approfondie comme le font les 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 multi-enregistrements, accédez à :

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

Dataverse inclut automatiquement une colonne time to live integer avec des tables élastiques. Cette colonne a le nom TTLInSeconds du schéma et le nom ttlinsecondslogique .

Lorsqu’une valeur est définie dans cette colonne, elle définit la durée, en secondes, avant l’expiration de la ligne et est 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’appareils IoT (Internet des objets) déployés par l’entreprise dans le monde entier. Contoso doit stocker et interroger de grandes quantités de données de capteurs émises par les appareils IoT afin qu’il puisse surveiller leur état de fonctionnement et recueillir d’autres informations.

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

Articles associés :

Problèmes connus

Les problèmes connus suivants liés aux tables élastiques doivent être résolus avant que cette fonctionnalité ne devienne généralement disponible.

Aucune erreur n’est retournée lorsque les opérations de données de table élastique sont regroupées dans une transaction

Dataverse ne retourne pas d’erreur lorsque vous regroupez des opérations de données à l’aide de la classe ExecuteTransactionRequest SDK ou d’un ensemble de modifications d’API Web $batch. Bien que ces opérations de données soient terminées, aucune transaction n’est appliquée. Étant donné qu’aucune transaction ne peut être appliquée, ces opérations doivent échouer et retourner une erreur.

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

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

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

Chaque fois qu’un enregistrement qui utilise une valeur personnalisée partitionid doit être identifié, par exemple pour Retrieve, Updateou Upsert les opérations, vous avez besoin d’un moyen de référencer la partitionid valeur. Dans ce cas, vous pouvez utiliser la clé de remplacement pour référencer l’enregistrement. Si vous préférez, vous devez également être en mesure d’utiliser le partitionId style de paramètre facultatif. 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.

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

Questions fréquemment posées

Cette section inclut toutes les questions fréquentes (FAQ). Si vous avez une question qui n’est pas traitée dans la documentation, sélectionnez le bouton Cette page dans la section Commentaires en bas de la page. Vous devez disposer d’un compte GitHub pour envoyer 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

  • Last updated on