Bien que ce soit une question vieille de plusieurs années ...
En bref, vous pouvez comprendre ACID comme une garantie d'intégrité / sécurité des données dans toutes les circonstances attendues . Comme dans la programmation générique, tous les maux de tête proviennent du multi-threading.
Le plus gros problème sur NoSQL est principalement ACI. D (urability) est généralement un problème distinct.
Si votre base de données est monothread - donc un seul utilisateur peut y accéder à la fois -, c'est compatible ACI en natif. Mais je suis sûr qu'aucun serveur ne peut avoir ce luxe.
Si votre base de données doit être multithread - servir plusieurs utilisateurs / clients simultanément - vous devez avoir besoin d'une transaction compatible ACI. Ou vous obtiendrez une corruption de données silencieuse plutôt qu'une simple perte de données. Ce qui est beaucoup plus horrible. Simplement, c'est exactement la même chose avec la programmation générique multi-thread. Si vous ne disposez pas d'un mécanisme approprié tel que le verrouillage, vous obtiendrez des données non définies. Et le mécanisme dans DB a appelé la conformité entièrement ACID .
De nombreuses bases de données YesSQL / NoSQL se disent conformes à ACID, mais en fait, très peu d'entre elles le sont vraiment.
Pas de conformité ACID = Vous obtiendrez toujours un résultat indéfini dans un environnement multi-utilisateur (client). Je ne pense même pas quel type de DB fait cela.
Ligne unique / clé conforme ACID = Vous obtiendrez un résultat garanti si vous ne modifiez qu'une seule valeur à la fois. Mais résultat indéfini (= corruption de données silencieuse) pour une mise à jour simultanée de plusieurs lignes / clés. La plupart des bases de données NoSQL actuellement populaires, notamment Cassandra, MongoDB, CouchDB,… Ces types de bases de données ne sont sûrs que pour les transactions sur une seule ligne. Vous devez donc garantir que votre logique de base de données ne touchera pas plusieurs lignes dans une transaction.
Conformité ACID à plusieurs lignes / clés = Vous obtiendrez toujours un résultat garanti pour toute opération. Il s'agit d'exigences minimales en tant que SGBDR. Dans le domaine NoSQL, très peu d'entre eux le font. Spanner, MarkLogic, VoltDB, FoundationDB. Je ne suis même pas sûr qu'il y ait plus de solutions. Ces types de bases de données sont vraiment frais et nouveaux, donc la plupart du temps on ne sait rien de leur capacité ou limitation.
Quoi qu'il en soit, c'est une comparaison sauf D (urability). N'oubliez pas de vérifier également l'attribut de durabilité. Il est très difficile de comparer la durabilité car la plage devient trop large. Je ne connais pas bien ce sujet…
Aucune durabilité. Vous perdrez des données à tout moment.
Stocké en toute sécurité sur le disque. Lorsque vous obtenez COMMIT OK, les données sont garanties sur le disque. Vous avez perdu des données en cas de rupture de disque.
En outre, il existe des différences même sur les bases de données compatibles ACID.
Parfois conforme ACID / vous avez besoin d'une configuration / pas de quelque chose automatique .. / certains composants ne sont pas conformes ACID / très rapide mais vous devez désactiver quelque chose pour cela ... / conforme ACID si vous utilisez un module spécifique ... = nous ne regroupera pas la sécurité des données par défaut. C'est un module complémentaire, une option ou vendu séparément. N'oubliez pas de télécharger, d'assembler, de configurer et d'émettre la commande appropriée. Quoi qu'il en soit, la sécurité des données peut être ignorée en silence. Fais le toi-même. Vérifiez-le vous-même. Bonne chance pour ne faire aucune erreur. Tout le monde dans votre équipe doit être un DBA sans faille pour utiliser ce type de base de données en toute sécurité. MySQL.
Toujours conforme à ACID = Nous n'échangeons pas la sécurité des données avec des performances ou quoi que ce soit. La sécurité des données est un ensemble forcé avec ce package DB. SGBDR le plus commercial, PostgreSQL.
Ci-dessus est l'implémentation typique de DB. Mais malgré tout, toute autre défaillance matérielle peut corrompre la base de données. Telles qu'une erreur de mémoire, une erreur de canal de données ou toute autre erreur possible. Vous avez donc besoin d'une redondance supplémentaire et une véritable base de données de qualité de production doit offrir des fonctionnalités de tolérance aux pannes.
Pas de redondance. Vous perdez toutes les données si vos données sont corrompues.
Sauvegarde. Vous effectuez une copie / restauration d'instantanés. Vous perdez des données après la dernière sauvegarde.
Sauvegarde en ligne. Vous pouvez effectuer une sauvegarde d'instantané pendant que la base de données est en cours d'exécution.
Réplication asynchrone. Sauvegarde pour chaque seconde (ou période spécifiée). Si la machine est en panne, cette base de données garantit de récupérer les données en redémarrant simplement. Vous perdez des données après la dernière seconde.
Réplication synchrone. Sauvegardez immédiatement pour chaque mise à jour des données. Vous avez toujours une copie exacte des données originales. Utilisez la copie si l'origine se casse.
Jusqu'à présent, je constate que de nombreuses implémentations de bases de données en manquent. Et je pense que s'ils ne disposent pas d'un support ACID et de redondance approprié, les utilisateurs finiront par perdre des données.