L'acide contre des magasins de données de base

Une des caractéristiques des systèmes de bases de données relationnelles est quelque chose de connu comme Respect ACID. Comme vous l'avez deviné, ACID est un acronyme - les lettres individuelles, destinées à décrire une caractéristique des transactions de base de données individuels, peuvent être développées comme décrit dans cette liste:

• Atomicité: La transaction de base de données doit être complètement réussir ou échouer complètement. Succès partiel est pas autorisé.

• Cohérence: Lors de la transaction de base de données, le SGBDR progresse d'un état valide à un autre. L'état ne est invalide.

• Isolation: La transaction de base de données du client doit se produire dans l'isolement d'autres clients qui tentent de traiter avec le SGBDR.

• Durabilité: L'opération de données qui a été le cadre de la transaction doit être reflétée dans stockage non volatile (mémoire de l'ordinateur qui permet de récupérer les informations stockées même quand pas sous tension - comme un disque dur) et persister après l'opération se termine avec succès. Échecs de transaction ne peut pas laisser les données dans un état partiellement engagé.

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

Cette décompose en deux opérations de base de données, où le compte d'origine montre un retrait, et le compte de destination montre un dépôt. De toute évidence, ces deux opérations doivent être attachés ensemble pour être valide afin que si l'un d'entre eux échouent, toute l'opération doit échouer à assurer à la fois les soldes restent valables.

Hadoop lui-même a pas de notion de transactions (ou même des enregistrements, d'ailleurs), il est donc clairement pas un système ACIDE conforme. Penser plus spécifiquement sur le stockage de données et les projets de transformation dans l'ensemble de l'écosystème Hadoop, aucun d'entre eux est entièrement ACIDE conforme, soit. Cependant, ils faire refléter les propriétés que vous voyez souvent dans les magasins de données NoSQL, donc il ya un précédent à l'approche Hadoop.

Un concept clé derrière les magasins de données NoSQL est que non chaque application a vraiment besoin de transactions ACID-conformes. Détente sur certaines propriétés ACID (et éloigner du modèle relationnel) a ouvert une multitude de possibilités, qui ont permis à certains magasins de données NoSQL pour atteindre évolutivité et les performances massive pour leurs applications de niche.

Tandis que l'acide définit les principales caractéristiques requises pour le traitement des transactions fiables, le monde NoSQL requiert des caractéristiques différentes pour permettre la flexibilité et l'évolutivité. Ces caractéristiques opposées sont habilement capturés dans la base acronyme:

• BasicallyUNvailable: Le système est garanti d'être disponible pour l'interrogation par tous les utilisateurs. (Pas d'isolement ici.)

• SÉtat souvent: Les valeurs stockées dans le système peuvent varier en raison de la cohérence de modèle éventuelle, comme décrit dans la prochaine balle.

• EConformément ventually: Comme les données est ajouté au système, l'état du système est progressivement répliqué sur tous les noeuds. Par exemple, dans Hadoop, quand un fichier est écrit dans le HDFS, les répliques des blocs de données sont créés dans différents nœuds de données après les blocs de données originales ont été écrites. Pour la courte période avant que les blocs sont répliqués, l'état du système de fichiers ne sont pas compatibles.

La base de l'acronyme est un peu artificiel, comme la plupart des magasins de données NoSQL ne pas abandonner complètement tous les caractéristiques ACID - il est pas vraiment le concept de pôle opposé que le nom implique, en d'autres termes. En outre, l'État Doux et caractéristiques Finalement cohérentes élèvent à la même chose, mais le fait est que par la cohérence de détente, le système peut horizontalement échelle (nombre de nœuds) et assurer la disponibilité.

Aucune discussion de NoSQL serait complet sans mentionner le théorème de la PAC, qui représente les trois types de garanties que les architectes visent à fournir dans leurs systèmes:

• Cohérence: Similaire au C dans ACID, tous les noeuds dans le système auraient le même point de vue des données à tout moment.

• Disponibilité: Le système répond toujours aux demandes.

• La tolérance de partage: 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 la PAC stipule 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 tous les trois. Cela vous laisse avec les trois possibilités présentées:

• Systèmes utilisant des technologies relationnelles traditionnelles ne sont normalement pas partitionner tolérante, afin qu'ils puissent garantir la cohérence et la disponibilité. En bref, si une partie de ces systèmes traditionnels de technologies relationnelles est déconnecté, l'ensemble du système est déconnecté.

• Systèmes où la tolérance de partition et la disponibilité sont d'une importance primordiale ne peut pas garantir la cohérence, parce que les mises à jour (destroyer de cohérence) peuvent être faites de chaque côté de la cloison. Les clé-valeur magasins Dynamo et CouchDB et le magasin colonne Cassandra famille sont des exemples populaires de partition tolérante / disponibilité (PA) systèmes.

• Systèmes où la tolérance de partition et la cohérence sont de première importance ne peut pas garantir la disponibilité car les systèmes renvoient des erreurs jusqu'à ce que l'état partitionné est résolu.

  Les magasins de données à base de Hadoop-sont considérés comme des systèmes de CP (conformément et partition tolérante). Avec les données stockées de manière redondante sur de nombreux nœuds esclaves, des pannes de grandes parties (partitions) d'un cluster Hadoop peut être tolérée. Hadoop est jugée conforme, car il a un magasin central de métadonnées (l'NameNode) qui maintient une vue unique et cohérente des données stockées dans le cluster.