Prise en charge de Java et MongoDB 4.0 pour les transactions à plusieurs documents

Monologies de MongoDB 4.0 Explication détaillée du support des transactions acides

(Cet article a été créé en collaboration avec MongoDB. Merci pour votre soutien aux partenaires qui ont rendu SITEPoint possible.)

MONGODB 4.0 ajoute la prise en charge des transactions à l'acide multi-documents. Mais cela signifie-t-il que MongoDB n'a pas pris en charge les transactions auparavant? Ce n'est pas le cas, MongoDB a toujours pris en charge les transactions de documents uniques. MongoDB 4.0 garantit que ces transactions peuvent être étendues à plusieurs documents, instructions multiples, collections multiples et plusieurs bases de données. Sans une forme de garantie d'intégrité des données de transaction, quelle est la base de données utile d'autre?

Avant de plonger dans cet article, vous pouvez trouver tout le code ici et essayer des transactions en acide multi-documentées.

Points clés

• MongoDB 4.0 introduit des transactions d'acide multi-documents qui étendent les garanties de transaction à plusieurs documents, instructions, collections et bases de données, améliorant ainsi l'intégrité et la cohérence des données.
• Avant MongoDB 4.0, MongoDB a pris en charge les transactions de documents uniques, assurant des opérations atomiques dans un seul document et convient à la plupart des applications.
• Les transactions d'acide multi-documents MongoDB 4.0 sont cohérentes avec les transactions traditionnelles de base de données relationnelles, fournissant l'atomicité, la cohérence, l'isolement et la persistance dans des opérations plus complexes.
• Les paramètres d'utilisation des transactions à l'acide multi-documents incluent le démarrage du réplicaset MongoDB, la mise en place d'un environnement Java avec les dépendances nécessaires et la réalisation des opérations de transaction via des scripts fournis.
La démonstration réelle de l'article montre la mise en œuvre des transactions à plusieurs documents, y compris les scénarios où les transactions sont engagées ou renvoyées en fonction de la disponibilité des stocks, garantissant la cohérence de l'état de la base de données.

Démarrage rapide

Étape 1: Démarrez MongoDB

Démarrez un répliquant MongoDB à nœud avec au moins la version 4.0.0 sur le port 27017 de LocalHost.

si vous utilisez docker:

Vous pouvez utiliser
• . start-mongo.sh
Lorsque vous avez terminé, vous pouvez utiliser
• . stop-mongo.sh
Si vous souhaitez vous connecter à MongoDB à l'aide de Mongo Shell, vous pouvez utiliser
• . connect-mongo.sh

Si vous préférez démarrer manuellement mongod:

• mkdir /tmp/data && mongod --dbpath /tmp/data --replSet rs
• mongo --eval 'rs.initiate()'

Étape 2: Démarrez Java

Cette démo contient deux programmes principaux:

et ChangeStreams.java. Transactions.java

Changer Streams vous permet de recevoir des notifications de tout changement de données dans une collection ou une base de données MongoDB.
Le processus de transaction est la démonstration elle-même.

Vous avez besoin de deux coquilles pour les exécuter.

si vous utilisez docker:

Première coquille:

./compile-docker.sh
./change-streams-docker.sh

Deuxième shell:

./transactions-docker.sh

Si vous n'utilisez pas Docker, vous devrez installer Maven 3.5.x et JDK 10 (ou JDK 8 version minimale, mais vous devrez mettre à jour la version Java dans

): pom.xml

Première coquille:

./compile-docker.sh
./change-streams-docker.sh

Deuxième shell:

./transactions-docker.sh

Comparons les transactions de documents uniques existantes avec des transactions multi-documents compatibles à l'acide pour MongoDB 4.0 et apprenez à utiliser Java pour profiter de cette nouvelle fonctionnalité.

Versions avant MongoDB 4.0

Même dans MongoDB 3.6 et plus tôt, chaque opération d'écriture est représentée comme une transaction portée sur la couche de stockage avec un seul niveau de document. Étant donné que le modèle de document combine les données pertinentes, sinon la modélisation de différentes tables parents-enfants dans le schéma tabulaire, l'opération de document unique atomique de MongoDB fournit une sémantique transactionnelle qui répond aux besoins d'intégrité des données de la plupart des applications.

Chaque opération d'écriture typique qui modifie plusieurs documents se produira réellement dans plusieurs transactions indépendantes: une transaction par document.

Prenons une application de gestion des stocks très simple à titre d'exemple.

Tout d'abord, j'ai besoin d'un ensemble de répliques MongoDB, alors veuillez démarrer MongoDB comme décrit ci-dessus.

maintenant insérons le document suivant dans la collection de produits:

./compile.sh
./change-streams.sh

En supposant qu'une promotion est en cours, nous voulons offrir à nos clients une remise de 20% sur tous les produits.

Mais avant d'appliquer cette remise, nous voulons utiliser des flux de changement pour surveiller la durée de ces opérations dans MongoDB.

Faites ce qui suit dans Mongo Shell:

./transactions.sh

Laisser cette coquille de côté, ouvrir un autre coquille de Mongo et appliquer la remise:

MongoDB Enterprise rs:PRIMARY> db.product.insertMany([
    { "_id" : "beer", "price" : NumberDecimal("3.75"), "stock" : NumberInt(5) }, 
    { "_id" : "wine", "price" : NumberDecimal("7.5"), "stock" : NumberInt(3) }
])

Comme vous pouvez le voir, les deux documents sont mis à jour à l'aide d'une seule ligne de commande, mais pas dans une seule transaction. Voici ce que nous avons vu dans la coquille de flux de changement:

cursor = db.product.watch([{$match: {operationType: "update"}}]);
while (!cursor.isExhausted()) {
  if (cursor.hasNext()) {
    print(tojson(cursor.next()));
  }
}

Comme vous pouvez le voir, le temps de cluster des deux opérations (voir clusterTime clé) est différent: ces opérations se produisent en la même seconde, mais le compteur pour l'horodatage est incrémenté de 1.

Alors ici, mettez-vous à jour un à la fois, même si cela se produit très rapidement, d'autres peuvent lire le document pendant que la mise à jour s'exécute et ne voir que l'un des produits a des remises.

La plupart du temps, c'est quelque chose que vous pouvez tolérer dans une base de données MongoDB, car nous essayons d'incorporer des données étroitement liées ou connexes dans le même document que possible. Par conséquent, deux mises à jour du même document se produisent dans une seule transaction:

PRIMARY> db.product.updateMany({}, {$mul: {price:0.8}})
{ "acknowledged" : true, "matchedCount" : 2, "modifiedCount" : 2 }
PRIMARY> db.product.find().pretty()
{
    "_id" : "beer",
    "price" : NumberDecimal("3.00000000000000000"),
    "stock" : 5
}
{
    "_id" : "wine",
    "price" : NumberDecimal("6.0000000000000000"),
    "stock" : 3
}

Cependant, parfois vous ne pouvez pas modéliser toutes les données pertinentes dans un seul document, et il existe de nombreuses raisons de choisir de ne pas intégrer le document.

MONGODB 4.0 en utilisant des transactions d'acide multi-documents

Les transactions en acide multi-documentées dans MongoDB sont très similaires à ce que vous pourriez avoir appris des bases de données relationnelles traditionnelles.

Les transactions MongoDB sont des opérations conversationnelles liées qui doivent être soumises atomiquement ou complètement en arrière d'une manière d'exécution tout ou rien.

Les transactions sont utilisées pour garantir que les opérations sont atomiques même sur plusieurs collections ou bases de données. Par conséquent, en utilisant des lectures d'isolement instantané, un autre utilisateur ne peut voir que toutes les actions ou aucune actions.

Ajoutons maintenant un panier à notre exemple.

Dans cet exemple, 2 collections sont nécessaires car nous traitons de 2 entités commerciales différentes: gestion des stocks et chariots que chaque client peut créer lors des achats. Chaque document de ces collections a un cycle de vie différent.

La documentation de la collection de produits indique l'article que je vends. Cela comprend le prix actuel du produit et l'inventaire actuel. J'ai créé un pojo pour le représenter: Product.java.

./compile-docker.sh
./change-streams-docker.sh

Lorsque le client ajoute son premier élément au panier, le panier est créé et lorsque le client continue de vérifier ou quitte le site Web, le panier est supprimé. J'ai créé un pojo pour le représenter: Cart.java.

./transactions-docker.sh

Le défi ici est que je ne peux pas vendre plus que moi: si j'ai 5 bières à vendre, je ne peux pas avoir plus de 5 bières dans les caddages sur différents clients.

Pour m'assurer cela, je dois m'assurer que le fonctionnement de la création ou de la mise à jour du panier client est atomique avec la mise à jour des stocks. C'est là que les transactions multi-documents entrent en jeu. Si quelqu'un essaie d'acheter quelque chose que je n'ai pas en stock, la transaction doit échouer. J'ajouterai une contrainte à l'inventaire du produit:

./compile.sh
./change-streams.sh

(Notez que cela est déjà inclus dans le code Java.)

Pour surveiller nos exemples, nous utiliserons les flux de changement MongoDB introduits dans MongoDB 3.6.

Dans chaque thread de ce processus appelé ChangeStreams.java, je surveillerai l'une des 2 collections et imprimerai chaque opération et son temps de cluster associé.

... (Le contenu suivant doit être complété avec des extraits de code Java et des explications basées sur le code fourni. La longueur est trop longue et omise ici) ....

Étapes suivantes

Merci d'avoir pris le temps de lire mon message - j'espère que vous le trouverez utile et intéressant. Pour rappel, tout le code peut être trouvé dans ce référentiel GitHub pour que vous puissiez expérimenter.

Si vous cherchez un moyen très simple de commencer, vous pouvez le faire en 5 clics dans le service de base de données MongoDB Atlas dans le cloud.

En outre, les transactions à plusieurs documents en acide ne sont pas la seule nouvelle fonctionnalité dans MongoDB 4.0, alors n'hésitez pas à consulter notre cours gratuit M040: nouvelles fonctionnalités et outils dans MongoDB 4.0 à l'Université MongoDB et notre guide sur les nouvelles fonctionnalités de MongoDB 4.0, où vous pouvez en savoir plus sur les conversions de type natif, les nouveaux outils de visualisation et d'analyse et l'intégration de Kubernetes.

... (Le contenu suivant est la FAQ, l'article est trop long, omis ici) ....

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!