Comment faire pour contourner l'absence de transactions dans MongoDB?

Je sais qu'il y a des questions similaires ici, mais ils sont soit de me dire pour revenir à la régulière systèmes SGBDR si j'ai besoin d'opérations ou d'utiliser les opérations atomiques ou validation à deux phases. La deuxième solution semble le meilleur choix. Le troisième, je ne veux pas les suivre, car il semble que beaucoup de choses pourraient aller mal et je ne peux pas le tester dans tous les aspects. Je vais avoir un moment difficile de refactoring mon projet pour effectuer des opérations atomiques. Je ne sais pas si cela vient de mon point de vue limité (j'ai seulement travaillé avec des bases de données SQL jusqu'à présent), ou si elle en fait ne peut pas être fait.

Nous aimerions tester MongoDB au sein de notre société. Nous avons choisi un relativement simple projet d'une passerelle SMS. Il permet à notre logiciel d'envoi de SMS pour le réseau cellulaire et la passerelle ne le sale boulot: en fait, la communication avec les fournisseurs via différents protocoles de communication. La passerelle gère également la facturation des messages. Chaque client qui s'applique pour le service de a à acheter des crédits. Le système diminue automatiquement de l'équilibre de l'utilisateur lorsqu'un message est envoyé et refuse l'accès si le solde est insuffisant. Aussi parce que nous sommes des clients de tiers fournisseurs de SMS, nous pouvons aussi nous avons notre propre soldes avec eux. Nous devons garder la trace de ceux aussi bien.

J'ai commencé à penser comment je peux stocker les données requises avec MongoDB si j'ai coupé une certaine complexité (facturation externe, en file d'attente d'envoi de SMS). Venant du monde SQL, je voudrais créer un tableau distinct pour les utilisateurs, une autre pour les messages SMS, et une pour stocker les transactions concernant les utilisateurs de l'équilibre. Disons que je créer des collections pour tous ceux dans MongoDB.

Imaginer un SMS l'envoi de la tâche avec les étapes suivantes dans ce système simplifié:

  1. vérifier si l'utilisateur dispose de suffisamment d'équilibre; refuser l'accès si il n'y a pas assez de crédit

  2. d'envoyer et de stocker le message dans la collection de SMS avec les détails et le coût (dans le système live le message aurait un status attribut et d'une tâche de ramasser pour la livraison et le prix des SMS en fonction de son état actuel)

  3. diminuer les utilisateurs de l'équilibre par le coût du message envoyé

  4. journal de la transaction dans l'opération de collecte de

Maintenant, quel est le problème avec ça? MongoDB peut faire les mises à jour atomiques sur un seul document. Dans la précédente flux, il pourrait arriver qu'une erreur se glisse dans et le message est stocké dans la base de données, mais l'équilibre de l'utilisateur n'est pas à jour et/ou de la transaction n'est pas connecté.

Je suis venu avec deux idées:

  • Créer une collection unique pour les utilisateurs, et de stocker le reste comme un champ, l'utilisateur opérations et les messages que sous les documents de l'utilisateur dans le document. Parce que nous pouvons mettre à jour les documents de façon atomique, cela résout le problème de transaction. Inconvénients: si l'utilisateur envoie beaucoup de SMS, la taille du document pourrait devenir grand et le 4 MO document limite pourrait être atteint. Je peux peut-être créer de l'historique des documents dans de tels scénarios, mais je ne pense pas que ce serait une bonne idée. Aussi, je ne sais pas à quelle vitesse le système serait si je pousse de plus en plus de données pour le même document.

  • Créer une collection pour les utilisateurs, et un pour les transactions. Il peut y avoir deux types de transactions: achat de crédit avec un solde positif de changement et messages envoyés avec un solde négatif de changement. Transaction peut avoir un sous-document; par exemple, dans messages envoyés les détails de la SMS peut être inclus dans la transaction. Inconvénients: je n'ai pas de magasin de l'utilisateur actuel de la balance donc je dois le calculer à chaque fois qu'un utilisateur tente d'envoyer un message pour dire si le message peut passer ou pas. J'ai peur que ce calcul est devenu lent que le nombre de transactions stockées augmente.

Je suis un peu confus au sujet de la méthode à choisir. Existe-il d'autres solutions? Je ne pouvais pas trouver toutes les meilleures pratiques en ligne sur la façon de contourner ce genre de problèmes. Je suppose que beaucoup de programmeurs qui tentent de se familiariser avec le monde NoSQL sont confrontés à des problèmes similaires dans le début.

  • Pardonnez-moi si je me trompe, mais il semble que ce projet va utiliser une banque de données NoSQL, indépendamment de savoir si il va en bénéficier ou non. NoSQL ne sont pas une alternative à SQL comme une "mode" choix mais pour quand la technologie relationnelle du SGBDR ne correspond pas au problème de l'espace & un magasin de données non relationnel n'. Beaucoup de votre question "Si c'était SQL puis ..." & que les anneaux de sonnette d'alarme pour moi. Tout le NoSQL est venu d'un besoin de résoudre un problème que SQL ne pouvait et ensuite, ils ont été un peu généralisé pour le rendre plus facile à utiliser & puis, bien sûr, le train commence à rouler.
  • Je suis conscient que ce projet n'est pas exactement le meilleur pour essayer de NoSQL. Cependant, j'ai peur si l'on commence à l'utiliser avec d'autres projets (disons une collection de la bibliothèque de logiciels de gestion, parce que nous sommes dans la gestion de la collection) et tout à coup une sorte de demande qui doit transactions (et c'est réellement là, imaginez que l'un des livres est transféré à partir d'une collection à l'autre) nous avons besoin de savoir comment pouvons-nous surmonter le problème. Peut-être que c'est juste moi qui est l'esprit étroit et pense qu'il ya toujours un besoin pour les transactions. Mais il pourrait être un moyen de surmonter ces quelque sorte.
  • Je suis d'accord avec PurplePilot, vous devez choisir une technologie qui s'adapte à une solution, ne pas essayer de greffer une solution qui n'est pas appropriée à un problème. La modélisation des données pour le graphique de bases de données est un tout autre paradigme que le SGBDR de conception et vous avez oublier tout ce que vous savez et réapprendre la nouvelle façon de penser.
  • Je ne comprends pas pourquoi je devrais utiliser l'outil approprié pour la tâche. Mais pour moi, quand j'ai lu les réponses comme celle - ci, il semble que le NoSQL n'est pas bon pour quoi que ce soit où des données est critique. C'est bon pour Facebook ou Twitter, où si certains commentaires se perd, le monde passe, mais rien au-dessus de qui est hors de l'entreprise. Si c'est vrai, je ne comprends pas pourquoi les autres le soin au sujet de la construction par exemple. une boutique en ligne avec MongoDB: kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce Il mentionne que la plupart des opérations peuvent être surmontés avec des opérations atomiques. Ce que je cherche, c'est le comment.
  • Vous dites "il semble que le NoSQL n'est pas bon pour quoi que ce soit où des données est critique" n'est pas le cas lorsqu'il n'est pas bon (peut-être) est transactionnelle de l'ACIDE type de traitement transactionnel. Aussi NoSQL sont conçus pour la distribution de magasins de données SQL magasins de type peut être très difficile à réaliser lorsque vous entrez dans le maître-esclave de réplication de scénarios. NoSQL ont des stratégies pour la cohérence des résultats et de s'assurer que la dernière série de données est utilisé, mais pas ACIDE.
  • Il y a des cas où le droit de la technologie de l'application n'existe tout simplement pas. Je viens d'un SQL de fond et suis en train d'écrire une application qui aura besoin de la transaction et de la base de données de la structure qui conviendrait parfaitement à un SQL DB. donc mon choix est évident ? Bien que pas si, j'ai aussi de très gros volumes de Données et de très haute Lectures et les écritures. Maintenant, après avoir passé quelques temps à la gestion de MySql, Informix et DB2, je sais que la mise à l'échelle est un gros travail, tout en NoSQL DB ont l'avantage de faciliter les opérations de mise à l'échelle. Pour revenir à la question, quel est le "Moins objectable" manière de mettre en place une sorte de transaction avec mongodb ?
  • Merci Dan pour la correction du texte!

InformationsquelleAutor NagyI | 2011-07-09
  1. 16

    De 4.0, MongoDB multi-document de transactions ACID. Le plan est de permettre à ceux dans le jeu de réplicas déploiements en premier, suivie par la fragmenté clusters. Les Transactions dans MongoDB, vous vous sentirez comme les transactions les développeurs connaissent à partir de bases de données relationnelles - ils être multi-déclaration, avec la même sémantique et la syntaxe (comme start_transaction et commit_transaction). Surtout, les changements de MongoDB qui permettent les transactions n'ont pas d'incidence sur les performances pour les charges de travail qui ne nécessitent pas d'eux.

    Pour plus de détails, voir ici.

    InformationsquelleAutor Grigori Melnik
  2. 81

    Vivre Sans Transactions

    Prise en charge des Transactions L'ACIDE propriétés, mais bien qu'il n'existe pas de transactions en MongoDB, nous avons des opérations atomiques. Ainsi, les opérations atomiques signifie que lorsque vous travaillez sur un document unique, que les travaux seront terminés avant tout le monde voit le document. Ils vont en voir de toutes les modifications que nous avons apportées ou aucun d'eux. Et à l'aide d'opérations atomiques, vous pouvez souvent faire la même chose que nous aurions accompli à l'aide de transactions dans une base de données relationnelle. Et la raison en est que, dans une base de données relationnelle, nous avons besoin de faire des changements sur plusieurs tables. Généralement, les tables qui doivent être rejoint et nous voulons faire tout à la fois. Et pour le faire, car il y a plusieurs tables, nous allons commencer une transaction et de faire toutes les mises à jour et puis à la fin de la transaction. Mais avec MongoDB, nous allons intégrer les données, puisque nous allons pré-rejoindre dans les documents et ce sont ces documents riches qui ont de la hiérarchie. On peut souvent faire la même chose. Par exemple, dans le blog exemple, si nous voulions nous assurer que nous avons mis à jour un blog de façon atomique, nous pouvons le faire parce que nous pouvons mettre à jour l'ensemble du blog à la fois. Où comme si c'était un tas de tables relationnelles, nous aurions probablement d'ouvrir une transaction afin que nous puissions mettre à jour le poste de collecte et de commentaires de la collection.

    Alors, quelles sont les approches que nous pouvons prendre en MongoDB pour pallier à un manque de transactions?

    • restructurer - restructurer le code, de sorte que nous travaillons au sein d'un document unique et de profiter de la opérations atomiques que nous vous proposons au sein de ce document. Et si nous faisons cela, alors d'habitude, nous sommes tous mis.
    • mettre en œuvre dans le logiciel - nous pouvons mettre en œuvre de verrouillage dans le logiciel, par la création d'une section critique. Nous pouvons construire un test, d'essai et de définir à l'aide de trouver et de modifier. Nous pouvons construire des sémaphores, si nécessaire. Et dans un sens, c'est la façon dont le monde fonctionne de toute façon. Si nous pensons à ce sujet, si une banque besoin de transférer de l'argent à une autre banque, ils ne vivons pas dans le même système relationnel. Et ils ont chacun leurs propres bases de données relationnelles souvent. Et ils ont d'être en mesure de coordonner cette opération même si nous ne pouvons pas commencer la transaction et la fin de la transaction dans l'ensemble de ces systèmes de base de données, seulement à l'intérieur d'un système, au sein d'une banque. Donc, il y a certainement les moyens dans un logiciel pour contourner le problème.
    • tolérer - l'approche finale, qui travaille souvent dans les applications web modernes et d'autres applications qui prennent en une quantité énorme de données est simplement de tolérer un peu d'incohérence. Par exemple, si nous parlons d'un ami d'alimentation dans Facebook, ce n'est pas grave si tout le monde voit votre mur de mettre à jour simultanément. Si okey, si une personne est à quelques battements derrière pendant quelques secondes et ils se rattraper. Il n'est pas souvent critique dans beaucoup de dessins qui tout reste parfaitement cohérente et que tout le monde ait une parfaite cohérence et la même vue de la base de données. Donc, nous pourrions simplement tolérer un peu d'incohérence qui est en quelque sorte temporaire.

    Update, findAndModify, $addToSet (à moins d'une mise à jour) & $push (à moins d'une mise à jour) des opérations de fonctionner automatiquement dans un document unique.

    • J'aime la façon dont cette réponse n', au lieu de garder le questionnement si l'on doit rentrer au relationnel. Merci @xameeramir !
    • une section critique de code ne fonctionnera pas si vous avez plus de 1 serveur, utiliser un externe distribué verrouillage de service
    • Pouvez-vous développer s'il vous plaît?
    • answere semble être transcription de la vidéo à partir d'ici: youtube.com/watch?v=_Iz5xLZr8Lw
    • Je pense que cela semble très bien jusqu'à ce que nous sommes restreint d'avoir à fonctionner sur une seule collection. Mais nous ne pouvons pas tout mettre dans un seul document, à cause de diverses raisons (doc taille ou si vous utilisez des références). Je pense que nous pourrions avoir besoin de faire des transactions.
    InformationsquelleAutor student
  3. 24

    Vérifier cette, par Tokutek. Ils développent un plugin pour Mongo qui promet non seulement les transactions, mais aussi le renforcement de la performance.

    • Bitliner. Tokutek a depuis été acquis par Percona, et sur le lien que tu as donné, je ne vois aucune référence à une quelconque information à tout ce qui s'est passé depuis le poste. Savez-vous ce qui est arrivé à leur effort? J'ai envoyé à l'adresse e-mail sur la page pour en trouver.
    • De quoi avez-vous besoin particulier? Si vous avez besoin de toku de la technologie appliquée à Mongodb essayer github.com/Tokutek/mongo , si vous avez besoin de la version de mysql peut-être ils l'ont ajouté à leur version standard de Mysql qu'ils fournissent habituellement avec
    • Comment puis-je intégrons tokutek avec nodejs.
    InformationsquelleAutor Giovanni Bitliner
  4. 11

    L'amener au point: si l'intégrité transactionnelle est une doit, puis ne pas utiliser MongoDB, mais uniquement les composants du système à l'appui des opérations. Il est extrêmement difficile de construire quelque chose sur le dessus de la composante dans le but de fournir de l'ACIDE-une fonctionnalité similaire pour les non-ACIDE composants conformes. Selon la personne usecases il peut faire sens pour séparer les actions dans la transaction et de la non-transactionnel des actions d'une certaine façon...

    • Je suppose que tu veux dire NoSQL peut être utilisé comme un acolyte de la base de données avec les classiques de SGBDR. Je n'aime pas l'idée de mélanger le NoSQL et SQL dans le même projet. Il augmente la complexité et éventuellement introduit certains non trivial problèmes.
    • Les solutions NoSQL sont rarement utilisés seuls. Document de magasins (mongo et canapé-lit) sont probablement les seuls exeception de cette règle.
    InformationsquelleAutor Andreas Jung
  5. 7

    Maintenant, quel est le problème avec ça? MongoDB peut faire les mises à jour atomiques sur un seul document. Dans la précédente flux, il pourrait arriver qu'une erreur se glisse dans et le message est stocké dans la base de données, mais l'équilibre de l'utilisateur n'est pas est réduite et/ou la transaction est pas devient connecté.

    Ce n'est pas vraiment un problème. L'erreur que vous avez mentionné est une logique (bug) ou IO error (réseau, panne de disque). Ce genre d'erreur peut laisser les deux transactionless et transactionnels dans les magasins de non-état cohérent. Par exemple, si elle a déjà envoyé des SMS, mais bien que le stockage de message d'erreur est survenue, il ne peut pas la restauration d'envoi de SMS, ce qui signifie qu'il ne sera pas connecté, l'utilisateur de la balance ne sera pas réduite etc.

    Le vrai problème ici est que l'utilisateur peut profiter de la race, de condition et d'envoyer plus de messages que son équilibre permet. Ceci s'applique également aux SGBDR, à moins que vous ne l'envoi de SMS à l'intérieur de la transaction avec l'équilibre champ de verrouillage (ce qui serait un grand goulot d'étranglement). Une solution possible pour MongoDB serait à l'aide de findAndModify abord à la réduction de l'équilibre et de vérifier, si c'est négatif interdire l'envoi et de rembourser le montant atomiques (incrément). Si elle est positive, continuer à envoyer et en cas d'échec éventuel du montant du remboursement. Le solde de l'histoire de la collection peut être également maintenue pour aider à corriger/vérifier l'équilibre de terrain.

    • Merci pour cette super réponse! Je sais que si j'utilise transaction capable de stockages de données peuvent être corrompues à cause de le système SMS whichover je n'ai pas de contrôle. Cependant, avec Mongo il y a une chance que les données erreur peut se produire en interne aussi bien. Disons que les modifications du code de l'équilibre de l'utilisateur avec findAndModify, le solde devient négatif, mais avant que je puisse corriger l'erreur, une erreur se produit et il faut redémarrer l'application. Je suppose que tu veux dire que je doit mettre en place quelque chose de similaire pour les deux phases de validation basée sur la transaction de collecte et de procéder régulièrement à la vérification de la correction sur la base de données.
    • Pas vrai, les opérations des magasins de revenir en arrière si vous ne faites pas une finale de validation.
    • Aussi, vous n'avez pas d'envoyer des SMS et ensuite de vous connecter à la DB, c'est tout simplement faux. Premier magasin tout en DB et de faire un dernier commit, vous pouvez ensuite envoyer le message. À ce stade, quelque chose pourrait encore échouer, si vous avez besoin d'une tâche cron pour vérifier que le message a bien été envoyé, si ce n'est essayer de l'envoyer. Peut-être un dédié message de la file d'attente serait mieux pour cela. Mais le tout se résume à savoir si vous pouvez envoyer des Sms de façon transactionnelle...
    • oui, c'est ce que je voulais dire. - Il des avantages commerciaux de transactions pour la facilité de l'évolutivité. Fondamentalement, l'application doit s'attendre à tout les deux documents dans différentes collections peuvent être dans un état incohérent et être prêt à gérer cela. @yi_H il restaure mais l'état ne serez pas réel plus (d'informations sur le message sera perdu). Ce n'est pas beaucoup mieux que d'avoir des données partielles (comme l'équilibre réduit, mais pas de message d'information ou vice versa).
    • Je vois. Ce n'est effectivement pas facile les contraintes. Je devrais peut-être en savoir plus sur la façon de systèmes SGBDR faire des transactions. Pouvez-vous recommander un certain type de matériel en ligne ou livre où je peut lire à ce sujet?
    • Correct, la vraie question ici est la condition de la course. La solution est une livraison atomique.

    InformationsquelleAutor pingw33n
  6. 6

    Le projet est simple, mais vous devez prendre en charge les transactions de paiement, ce qui rend la chose difficile. Ainsi, par exemple, un complexe système de portail avec des centaines de collections (forum, chat, annonces, etc...) est à certains égards plus simple, parce que si vous perdez un forum ou un chat entrée, personne ne se soucie vraiment. Si vous avez, d'autre part, la perdre une opération de paiement qui est un problème grave.

    Donc, si vous voulez vraiment un projet pilote pour MongoDB, choisissez-en un qui est simple dans la que respect.

    • Merci pour l'explication. Triste d'entendre cela. J'aime la simplicité de NoSQL et l'utilisation de JSON. Nous sommes à la recherche d'une alternative à l'ORM, mais il semble que nous devons rester avec elle pendant un certain temps.
    • Pouvez-vous donner des bonnes raisons pourquoi MongoDB est mieux que SQL pour cette tâche? Projet pilote a l'air un peu idiot.
    • Je n'ai pas dit que MongoDB est mieux que SQL. Nous voulons simplement savoir si c'est mieux que SQL+ORM. Mais maintenant, il devient de plus en plus clair qu'ils ne sont pas compétitifs dans ce genre de projets.
    InformationsquelleAutor Karoly Horvath
  7. 6

    Transactions sont absents dans MongoDB pour des raisons valables. C'est une de ces choses qui font de MongoDB plus rapide.

    Dans votre cas, si la transaction est un must, mongo semble pas un bon ajustement.

    Peut être RDMBS + MongoDB, mais qui va ajouter de la complexité et de la, il sera plus difficile à gérer et à soutenir l'application.

    • Il y a maintenant une distribution de MongoDB, appelé TokuMX qui utilise fractale de la technologie pour délivrer 50x l'amélioration de la performance et qui donne plein d'ACIDE soutien à la transaction, dans le même temps: tokutek.com/tokumx-for-mongodb
    • Comment une transaction ne devait pas être un "must". Dès que vous avez toujours besoin de 1 cas simple où vous devez mettre à jour 2 tables de mongo est tout à coup plus un bon ajustement? Qui ne laisse pas de très nombreux cas d'utilisation à tous.
    • d'accord, c'est pourquoi MongoDB est un peu stupide 🙂
    InformationsquelleAutor kheya
  8. 6

    C'est probablement le meilleur blog que j'ai trouvé concernant la mise en œuvre de la transaction comme caractéristique pour mongodb .!

    Synchronisation Drapeau: le meilleur pour juste copier les données à partir d'un document maître

    Travail de la File d'attente: très polyvalent, résout 95% des cas. La plupart des systèmes ont besoin d'avoir au moins une file d'attente de travail autour de toute façon!

    Deux phases de validation: cette technique s'assurer que chaque entité a toujours toutes les informations nécessaires pour arriver à un état cohérent

    Journal de la Réconciliation: le plus technique robuste, idéal pour les systèmes financiers

    Versions: fournit une isolation et soutient des structures complexes

    Lire ceci pour plus d'info: https://dzone.com/articles/how-implement-robust-and

    • Veuillez inclure les éléments pertinents liés des ressources nécessaires pour répondre à la question dans votre réponse. En l'état, votre réponse est très sensible à la pourriture des liens (c'est à dire si le lien de site web est en panne ou modifications de votre réponse est potentiellement inutiles).
    • Merci @mech pour la suggestion
    InformationsquelleAutor Vaibhav