ACID par rapport aux magasins de données BASE - mannequins

Une des caractéristiques des systèmes de bases de données relationnelles est ce qu'on appelle la conformité ACID . Comme vous l'avez peut-être deviné, ACID est un acronyme - les lettres individuelles, destinées à décrire une caractéristique de transactions de base de données individuelles, peuvent être développées comme décrit dans cette liste:

Atomicité: réussir ou échouer complètement. Le succès partiel n'est pas autorisé.
Cohérence: Lors de la transaction de la base de données, le SGBDR progresse d'un état valide à l'autre. L'état n'est jamais invalide.
Isolation: La transaction de base de données du client doit se faire isolément des autres clients qui tentent d'effectuer des transactions avec le SGBDR.
Durabilité: L'opération de données faisant partie de la transaction doit être reflétée dans stockage non volatile (mémoire d'ordinateur capable de récupérer des informations stockées même si non alimentées - comme un disque dur) la transaction se termine avec succès. Les échecs de transaction ne peuvent pas laisser les données dans un état partiellement engagé.

Certains cas d'utilisation des SGBDR, comme le traitement des transactions en ligne, dépendent des transactions conformes à l'ACID entre le client et le SGBDR pour que le système fonctionne correctement. Un bon exemple de transaction conforme ACID est un transfert de fonds d'un compte bancaire à un autre.

Cela se décompose en deux transactions de base de données, où le compte d'origine montre un retrait, et le compte de destination montre un dépôt. Évidemment, ces deux transactions doivent être liées ensemble pour être valides de sorte que si l'une d'entre elles échoue, toute l'opération doit échouer pour s'assurer que les deux soldes restent valides.

Hadoop lui-même n'a aucun concept de transactions (ni même d'enregistrements, d'ailleurs), il ne s'agit donc clairement pas d'un système conforme ACID. En pensant plus spécifiquement aux projets de stockage et de traitement des données dans l'ensemble de l'écosystème Hadoop, aucun d'entre eux n'est entièrement conforme ACID. Cependant, ils ne reflètent les propriétés que vous voyez souvent dans les magasins de données NoSQL, donc il y a un précédent à l'approche Hadoop.

Un concept clé derrière les banques de données NoSQL est que toutes les applications n'ont pas vraiment besoin de transactions compatibles ACID. Se relaxer sur certaines propriétés ACID (et s'éloigner du modèle relationnel) a ouvert une multitude de possibilités, qui ont permis à certaines bases de données NoSQL d'atteindre une évolutivité et des performances massives pour leurs applications de niche.

Alors que l'ACID définit les principales caractéristiques requises pour un traitement fiable des transactions, le monde NoSQL requiert des caractéristiques différentes pour permettre la flexibilité et l'évolutivité.Ces caractéristiques opposées sont habilement saisies dans l'acronyme BASE:

B asically A disponible: Le système est garanti pour être disponible pour tous les utilisateurs. (Pas d'isolation ici.)
S oft State: Les valeurs stockées dans le système peuvent changer en raison du modèle de cohérence éventuel, comme décrit dans la puce suivante.
E Ventuellement cohérent: Au fur et à mesure que des données sont ajoutées au système, l'état du système est reproduit progressivement sur tous les nœuds. Par exemple, dans Hadoop, lorsqu'un fichier est écrit dans HDFS, les réplicas des blocs de données sont créés dans différents nœuds de données après l'écriture des blocs de données d'origine. Pendant la courte période précédant la réplication des blocs, l'état du système de fichiers n'est pas cohérent.

L'acronyme BASE est un peu artificiel, car la plupart des banques de données NoSQL n'abandonnent pas complètement toutes les caractéristiques ACID - ce n'est pas vraiment le contraire du nom, en d'autres termes. En outre, les caractéristiques Soft State et Eventually Consistent équivalent à la même chose, mais le fait est qu'en relaxant la cohérence, le système peut évoluer horizontalement (plusieurs nœuds) et assurer la disponibilité.

Aucune discussion de NoSQL ne serait complète sans mentionner le théorème CAP, qui représente les trois types de garanties que les architectes cherchent à fournir dans leurs systèmes:

Cohérence: Semblable au C dans ACID, tous les nœuds de le système aurait la même vue des données à tout moment.
Disponibilité: Le système répond toujours aux demandes.
Tolérance de partition: Le système reste en ligne si des problèmes de réseau se produisent entre les nœuds du système.

Le théorème de CAP indique que dans les systèmes en réseau distribués, les architectes doivent choisir deux de ces trois garanties - vous ne pouvez pas promettre à vos utilisateurs les trois. Cela vous laisse avec les trois possibilités indiquées:

Les systèmes utilisant des technologies relationnelles traditionnelles ne sont normalement pas tolérants aux partitions, ils peuvent donc garantir la cohérence et la disponibilité. En bref, si une partie de ces systèmes de technologies relationnelles traditionnelles est hors ligne, l'ensemble du système est hors ligne.
Les systèmes où la tolérance et la disponibilité des partitions sont d'une importance primordiale ne peuvent garantir la cohérence, car les mises à jour (destructeur de cohérence) peuvent être effectuées de chaque côté de la partition. Les magasins de valeurs-clés Dynamo et CouchDB et le magasin de colonnes-familles Cassandra sont des exemples populaires de systèmes de tolérance de partition / disponibilité (PA).
Les systèmes où la tolérance de partition et la cohérence sont d'une importance primordiale ne peuvent pas garantir la disponibilité, car les systèmes renvoient des erreurs jusqu'à ce que l'état partitionné soit résolu.

Les magasins de données basés sur Hadoop sont considérés comme des systèmes CP ( c compatibles et p tolérants à l'artition). Avec des données stockées de manière redondante sur de nombreux nœuds esclaves, les pannes sur de grandes parties (partitions) d'un cluster Hadoop peuvent être tolérées. Hadoop est considéré comme cohérent car il possède un magasin de métadonnées central (NameNode) qui conserve une vue unique et cohérente des données stockées dans le cluster.