Opérations de lot transactionnel dans Azure Cosmos DB

  • Article

S’APPLIQUE À : NoSQL

Le lot transactionnel décrit un groupe d’opérations de point qui doivent réussir ou échouer avec la même clé de partition dans un conteneur. Des opérations sont définies, ajoutées au lot, puis le lot est exécuté. Si toutes les opérations réussissent dans l’ordre dans lequel elles sont décrites dans l’opération de lot transactionnel, la transaction est validée. Toutefois, si une opération échoue, la totalité de la transaction est restaurée.

Définition d’une transaction dans Azure Cosmos DB

Une transaction dans une base de données classique peut être définie comme étant une séquence d'opérations effectuées en tant qu'unité de travail logique unique. Chaque transaction fournit des garanties de propriété ACID (Atomicité, Cohérence, Isolation, Durabilité).

  • L’atomicité permet de s’assurer que toutes les opérations effectuées au sein d’une transaction sont traitées en tant que simple unité validée dans son intégralité ou aucunement.
  • La cohérence permet de s’assurer que les données sont toujours dans un état valide d’une transaction à l’autre.
  • L’isolation, quant à elle, permet de garantir qu’aucune transaction n’interfère avec les autres. De nombreux systèmes commerciaux fournissent plusieurs niveaux d’isolation pouvant être utilisés en fonction des besoins des applications.
  • La durabilité permet de s’assurer que toute modification validée dans une base de données sera toujours présente. Azure Cosmos DB prend en charge les transactions entièrement compatibles avec ACID avec isolement d’instantané pour les opérations au sein de la même clé de partition logique.

Opérations de lot transactionnel et procédures stockées

Azure Cosmos DB prend actuellement en charge les procédures stockées, qui fournissent également l’étendue transactionnelle sur les opérations. Toutefois, les opérations de lot transactionnel offrent les avantages suivants :

  • Option de langage : le lot transactionnel est pris en charge dans le SDK et dans le langage que vous utilisez déjà, tandis que les procédures stockées doivent être écrites en JavaScript.
  • Contrôle de version du code : le contrôle de version du code d’application et son intégration dans votre pipeline CI/CD est bien plus naturel que l’orchestration de la mise à jour d’une procédure stockée et le fait de s’assurer que la substitution se produit au bon moment. Cela facilite également la restauration des modifications.
  • Performance : réduction de la latence sur les opérations équivalentes jusqu’à 30 % par rapport à l’exécution de la procédure stockée.
  • Sérialisation de contenu : chaque opération au sein d’un lot transactionnel peut tirer parti des options de sérialisation personnalisées pour sa charge utile.

Procédure de création d’une opération de lot transactionnel

Lorsque vous créez une opération transactionnelle par lot, commencez par une instance de conteneur et appelez CreateTransactionalBatch :

PartitionKey partitionKey = new PartitionKey("road-bikes");

TransactionalBatch batch = container.CreateTransactionalBatch(partitionKey);

Ensuite, ajoutez plusieurs opérations au lot :

Product bike = new (
    id: "68719520766",
    category: "road-bikes",
    name: "Chropen Road Bike"
);

batch.CreateItem<Product>(bike);

Part part = new (
    id: "68719519885",
    category: "road-bikes",
    name: "Tronosuros Tire",
    productId: bike.id
);

batch.CreateItem<Part>(part);

Enfin, appelez ExecuteAsync sur le lot :

using TransactionalBatchResponse response = await batch.ExecuteAsync();

Une fois la réponse reçue, examinez si la réponse est positive. Si la réponse indique une réussite, extrayez les résultats :

if (response.IsSuccessStatusCode)
{
    TransactionalBatchOperationResult<Product> productResponse;
    productResponse = response.GetOperationResultAtIndex<Product>(0);
    Product productResult = productResponse.Resource;

    TransactionalBatchOperationResult<Part> partResponse;
    partResponse = response.GetOperationResultAtIndex<Part>(1);
    Part partResult = partResponse.Resource;
}

Important

En cas d’échec, l’opération ayant échoué a un code d’état correspondant à l’erreur. Toutes les autres opérations ont un code d’état 424 (échec de la dépendance). Si l’opération échoue parce qu’elle tente de créer un élément déjà existant, un code d’état 409 (conflit) est retourné. Les codes d’état facilitent l’identification de la cause de l’échec de la transaction.