Des transactions dans NoSQL?
J'examine NoSQL pour mettre à l'échelle des alternatives à une base de données. Que dois-je faire si je veux des choses basées sur des transactions qui sont sensibles à ce genre de choses?
De manière générale, les solutions NoSQL ont une sémantique transactionnelle plus légère que les bases de données relationnelles, mais ont toujours des installations pour les opérations atomiques à un certain niveau.
Généralement, ceux qui effectuent la réplication maître-maître offrent moins de cohérence et plus de disponibilité. Il faut donc choisir le bon outil pour le bon problème.
Beaucoup proposent des transactions au niveau d'un seul document (ou ligne, etc.). Par exemple, avec MongoDB, il y a atomicité dans le document unique - mais les documents peuvent être assez riches, donc cela fonctionne assez bien - plus d'infos ici .
C'est la réponse la plus proche que j'ai trouvée qui s'appliquerait à n'importe quelle base de données NoSQL. C'est sur un article de blog 2007 d'Adam Wiggins de Heroku.com:
Le vieil exemple consiste à utiliser une transaction de base de données pour envelopper le transfert d'argent d'un compte bancaire à un autre. La bonne solution consiste à stocker une liste des événements du grand livre (transferts entre comptes) et à afficher le solde actuel sous la forme d'une somme du grand livre. Si vous programmez dans un langage fonctionnel (ou pensez de cette façon), cela est évident.
De: http://adam.heroku.com/past/2007/12/17/a_world_without_sql/ (Son site Web est idéal pour des idées sur l'évolutivité.)
J'ai interprété le paragraphe ci-dessus comme:
- Créez une base de données pour les comptes des membres.
- Créez une file d'attente de messagerie. Surnommez-le "grand livre".
- Ajoutez des travailleurs en arrière-plan pour répondre à chaque demande de la file d'attente.
Plus d'informations. sur les files d'attente/les travailleurs en arrière-plan: http://adam.heroku.com/past/2009/4/14/building_a_queuebacked_feed_reader_part_1/
Le client (alias membre ou client) suit ces étapes pour retirer de l'argent:
- Soumettez une demande de retrait d'argent.
- La demande est envoyée au serveur.
- Le serveur le place dans une file d'attente. Le message est le suivant: "Retirez 5 000 $".
- Le client s'affiche: "Veuillez patienter car la demande est en cours de traitement ..."
- Les ordinateurs clients interrogent le serveur toutes les 2 secondes en demandant: "La demande a-t-elle été satisfaite?"
- Sur le serveur, les travailleurs d'arrière-plan répondent aux demandes précédentes des autres membres de la manière premier entré/premier sorti. Finalement, ils obtiennent à la demande de votre client de retirer de l'argent.
- Une fois la demande satisfaite, le client reçoit un message avec son nouvel équilibre.
Vous pouvez utiliser Heroku.com pour créer rapidement une petite maquette si vous êtes à l'aise avec Node.js ou Ruby/Rack.
L'idée générale semble assez facile et bien meilleure que l'utilisation de transactions intégrées à la base de données, ce qui la rend extrêmement difficile à mettre à l'échelle.
Avis de non-responsabilité: Je ne l'ai pas encore implémenté. Je lis ces choses par curiosité même si je n'en ai pas besoin en pratique. Oui, @gbn a raison de dire qu'un SGBDR avec des transactions serait probablement suffisant pour les besoins de Timmy et moi. Néanmoins, il serait amusant de voir jusqu'où vous pouvez aller dans les bases de données NoSQL avec des outils open-source et un site Web appelé " A Tornado of Razorblades ".
NoSQL couvre un ensemble diversifié d'outils et de services, y compris des magasins de valeurs-clés, de documents, de graphiques et de colonnes larges. Ils essaient généralement d'améliorer l'évolutivité du magasin de données, généralement en distribuant le traitement des données. Les transactions nécessitent ACIDE propriétés de la façon dont les bases de données effectuent les opérations utilisateur. ACID limite la façon dont l'évolutivité peut être améliorée: la plupart des outils NoSQL assouplissent les critères de cohérence des opérations pour obtenir la tolérance aux pannes et la disponibilité pour la mise à l'échelle, ce qui rend la mise en œuvre des transactions ACID très difficile.
Un raisonnement théorique couramment cité des magasins de données distribuées est le théorème CAP : la cohérence, la disponibilité et la tolérance de partition ne peuvent pas être atteintes en même temps. Les outils SQL, NoSQL et NewSQL peuvent être classés en fonction de ce qu'ils abandonnent; un bon chiffre pourrait être trouvé ici .
Un nouvel ensemble d'exigences plus faible remplaçant ACID est BASE ("essentiellement disponible, état souple, cohérence éventuelle"). Cependant, des outils finalement cohérents ("éventuellement tous les accès à un article retourneront la dernière valeur mise à jour") sont difficilement acceptables dans les applications transactionnelles comme les opérations bancaires. Ici, une bonne idée serait d'utiliser des bases de données SQL/ACID en mémoire, orientées colonnes et distribuées, par exemple VoltDB ; Je suggère de regarder ces solutions "NewSQL".
Je voulais juste commenter des conseils sur les transactions monétaires sur ce fil. Les transactions sont quelque chose que vous voulez vraiment utiliser avec les transferts d'argent.
L'exemple donné comment faire que les transferts est très agréable et bien rangé.
Mais dans la vie réelle, le transfert d'argent peut inclure des frais ou des paiements vers d'autres comptes. Les gens obtiennent des bonus pour l'utilisation de certaines cartes qui proviennent d'un autre compte ou ils peuvent obtenir des frais prélevés sur leur compte vers un autre compte dans le même système. Les frais ou les paiements peuvent varier selon la transaction financière et vous devrez peut-être maintenir un système de comptabilité qui indique le crédit et le débit de chaque transaction au fur et à mesure.
Cela signifie que vous souhaitez mettre à jour plusieurs lignes en même temps, car le crédit sur un compte peut être débité sur un ou plusieurs comptes. Vous verrouillez d'abord les lignes afin que rien ne puisse changer avant la mise à jour, puis vous vous assurez que les données écrites sont cohérentes avec la transaction.
C'est pourquoi vous voulez vraiment utiliser les transactions. Si quelque chose se passe mal en écrivant sur une ligne, vous pouvez annuler toute une série de mises à jour sans que les données de transaction financière se terminent de manière incohérente.
Le problème avec une transaction et deux opérations (par exemple, un paye 5 000 $, la seconde reçoit 5 000 $) - c'est que vous avez deux comptes avec la même priorité. Vous ne pouvez pas utiliser un seul compte pour confirmer le deuxième (ou dans l'ordre inverse). Dans ce cas, vous pouvez garantir qu'un seul compte sera correct (c'est-à-dire confirmé), le second (qui confirmera) peut avoir échoué. Voyons pourquoi il peut échouer (en utilisant le message aproatch, l'expéditeur est confirmé par le destinataire):
- Écrire + 5 000 $ sur le compte récepteur
- En cas de succès - écrire - 5000 $ sur le compte de l'expéditeur
- En cas d'échec - essayez à nouveau ou annulez ou affichez un message
Il garantira économiser pour # 1. Mais qui garantit en cas d'échec # 2? Idem pour l'ordre inverse.
Mais cela est possible aux implémentations pour être en sécurité sans transactions et avec NoSQL. Vous êtes toujours autorisé à utiliser une troisième entité qui sera confirmée par l'expéditeur et le destinataire et garantissez que votre opération a été effectuée:
- Génération d'un identifiant de transaction unique et création d'une entité de transaction
- Écrire + 5 000 $ sur le compte du destinataire (en référence à l'ID de transaction)
- En cas de succès - définir l'état de la transaction à envoyer
- Écriture - 5 000 $ sur le compte du compte sedned (avec référence à l'ID de transaction)
- En cas de succès - définir l'état de la transaction à recevoir
Cet enregistrement de transaction garantira que c'était correct pour envoyer/recevoir des massages. Vous pouvez maintenant vérifier chaque message par identifiant de transaction et s'il a reçu ou terminé l'état - vous en tenez compte pour l'équilibre de l'utilisateur.
Cela dépend de votre base de données, mais ... je dirais qu'en général, vous pouvez utiliser 'Transactions optimistes' pour y parvenir, mais j'imagine que l'on devrait s'assurer de comprendre l'implémentation de la base de données atomicité garanties (par exemple quel type d'opérations d'écriture et de lecture sont atomiques).
Il semble y avoir quelques discussions sur le net à propos de HBase transactions, si c'est une aide.
jetez un œil à scalaris c'est une base de données sans sql avec une forte cohérence et des transactions implémentées.
C'est pourquoi je crée une solution de stockage de documents NoSQL pour pouvoir utiliser des transactions "réelles" sur des applications d'entreprise avec la puissance d'une approche de données non structurées. Jetez un oeil à http://djondb.com et n'hésitez pas à ajouter toute fonctionnalité qui pourrait être utile.
Vous pouvez toujours utiliser une approche NoSQL dans une base de données SQL. NoSQL semble généralement utiliser des "magasins de données clés/valeurs": vous pouvez toujours l'implémenter dans votre SGBDR préféré et donc conserver les bonnes choses comme les transactions, les propriétés ACID, le support de votre DBA convivial, etc., tout en réalisant les avantages de performances et de flexibilité de NoSQL , par exemple via une table telle que
CREATE TABLE MY_KEY_VALUE_DATA
(
id_content INTEGER PRIMARY KEY,
b_content BLOB
);
Le bonus est que vous pouvez ajouter des champs supplémentaires ici pour lier votre contenu à d'autres tables correctement relationnelles, tout en conservant votre contenu volumineux dans le champ BLOB principal (ou TEXT si apt).
Personnellement, je préfère une représentation TEXT donc vous n'êtes pas lié à une langue pour travailler avec les données, par ex. utiliser sérialisé Java signifie que vous pouvez accéder au contenu de Perl pour les rapports, par exemple. TEXT est également plus facile à déboguer et fonctionne généralement avec en tant que développeur.
- Nouveau magasin de valeurs-clés FoundationDB
- Ancien magasin de valeurs-clés Berkley DB
il y en a sûrement d'autres
Vous pouvez implémenter des transactions optimistes par-dessus la solution NoSQL si elle prend en charge la comparaison et la définition. J'ai écrit un exemple et une explication sur une page GitHub comment le faire dans MongoDB, mais vous pouvez le répéter dans n'importe quelle solution NoSQL appropriée.