transactions acid

Les systèmes de gestion de bases de données robustes doivent protéger les données qu'ils stockent et traitent contre la corruption. La norme ACID ( atomicité cohérence isolement durabilité ) fournit un ensemble de règles pour préserver l'intégrité des bases de données et des transactions.

Qu'est-ce que l'ACID ?

L'acronyme ACID a été inventé dans les années 1960 et a été mis en œuvre par les systèmes de bases de données relationnelles depuis lors. Les quatre propriétés peuvent être développées comme suit.

atomicité

atomicité applique la règle selon laquelle toutes les modifications d'une transaction sont validées ensemble. Si l'une des modifications de la transaction échoue, c'est toute la transaction qui échoue et toutes les modifications en attente sont annulées. Par exemple, dans le cas d'une transaction bancaire, la première étape consiste à déduire un montant d'un compte d'épargne, suivie d'une deuxième étape consistant à créditer le solde d'un compte courant du même montant. Si l'une des étapes échoue pour une raison quelconque, l'ensemble de la transaction est annulée. De cette manière, les deux comptes conservent leur solde initial. Chaque système de base de données relationnelle effectue par défaut un retour en arrière implicite de toutes les transactions non engagées lors du démarrage de l'instance de la base de données. Le système de gestion des bases de données relationnellesSGBDR) doit procéder ainsi parce qu'il enregistre de manière optimiste les modifications non validées dans les fichiers journaux, qui ne sont considérées comme confirmées que lorsque l'enregistrement validation correspondant est écrit dans le journal.

cohérence

Un système de base de données se protège en validant les données insérées ou mises à jour. Lorsqu'une table est créée ou modifiée, chaque champ ou attribut d'un enregistrement a un type de données fixe. Toute tentative d'insertion de données parasites d'un type de données incorrect est rejetée. Par exemple, un caractère alphabétique n'est pas autorisé dans un champ de type entier.

Les contraintes d'intégrité référentielle constituent un deuxième niveau de contrôle pour les champs de données. Ces règles sont utilisées pour limiter les valeurs d'un champ, par exemple celles qui existent dans une table connexe. Il s'agit alors d'une contrainte de clé étrangère. Par exemple, une table de ventes peut faire référence à des produits qui doivent exister dans la table des produits pour que l'enregistrement ventes soit valide. Ces contraintes d'intégrité référentielle protègent la structure de la base de données même si une application est mal codée.

isolement

L'isolement transactions garantit que chaque transaction est séparée des autres. Si deux transactions veulent modifier le même enregistrement, les mécanismes de verrouillage d'un SGBDR sérialiseront l'accès pour que les transactions fassent la queue pour l'accès à la mise à jour d'un enregistrement. De nombreuses bases de données escaladent les verrous de niveau ligne au niveau de la page ou de la table en cas de forte concurrence pour les verrous de transaction.

Les normes du langage de requête structuré (SQL) pour les niveaux d'isolement sont définies comme READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ et SERIALIZABLE. Les lectures non engagées aident les bases de données dont les modèles de verrouillage sont médiocres, mais elles sont considérées comme des lectures sales dans l'industrie, et donc mal vues. Les lectures répétées, en revanche, sont considérées comme très utiles car elles maintiennent l'intégrité de l'ensemble des résultats, de sorte qu'un ensemble d'enregistrements récupérés par une requête 'additionnera toujours de manière cohérente.

durabilité

Les modifications de données se produisent d'abord dans la mémoire, où le processeur peut les voir. Pour des raisons de durabilité, elles sont ensuite écrites sur un support de sauvegarde, qui est considéré comme un support non volatil. Les fichiers journaux de la base de données enregistrement toutes les modifications afin de protéger le SGBDR contre les défaillances du serveur. La durabilité garantit que les modifications des transactions engagées ne sont pas perdues au démarrage de l'instance de la base de données.

Pourquoi l'ACID est-il important pour les transactions ?

ACID définit un ensemble de règles qui protègent l'intégrité des données et des transactions afin d'éviter toute corruption logique des données. Les fichiers de données ne contiennent que des données validées ; dans le cas contraire, la base de données devient rapidement incohérente, irrécupérable et inutilisable.

Support bases de données relationnelles Actian Support transactions acid

La plateforme de données Actian s'intègre à plusieurs bases de données relationnelles, notamment Actian Vector pour les workloads analytiques à grande vitesse utilisant un schéma de stockage en colonnes et Actian Ingres utilisant un magasin de rangées conçu pour les charges de travail transactionnelles. DataConnect fournit une plateforme d'intégration intelligente à code bas pour répondre à des cas d'utilisation complexes avec des intégrations automatisées, intuitives et réutilisables.

La plateforme de données Actian fonctionne sur site et sur plusieurs plateformes cloud, notamment AWS, Azure et Google Cloud, de sorte que vous pouvez exécuter vos analyses là où résident vos données.