ACID Transactions in MongoDB

Yes, MongoDB supports ACID transactions. 1. It supports single-document ACID operations from version 4.0, and multi-document transactions from 4.2, including replica sets and shard clusters. 2. Multi-document transactions need to be started through a session. All operations must be passed in session. Try-catch handles commits or rollbacks, and finally call endSession to release resources. 3. The transaction has a 60-second default timeout limit, and the performance overhead is high. Especially cross-sanded transactions require mongos coordination, which should avoid long-term or high-frequency use; 4. Eval, mapReduce and other commands are disabled in the transaction, and read and write attention and read preferences must be set at the transaction level; 5. It is recommended to use single-document atomic operations first, and use transactions through embedded data models to reduce transaction requirements to improve performance and scalability; 6. It is suitable for strong consistency scenarios such as transfer and inventory deduction, but the transaction time should be shortened as much as possible to avoid blockage. MongoDB's ACID capability can meet most scenarios, and the key is to choose the usage method according to the business reasonably.

MongoDB supports ACID transactions, but its implementation is different from traditional relational databases, especially in distributed environments with usage limitations and best practices. The following is a few key points to illustrate ACID transactions in MongoDB.

What is ACID?

ACID is the four key properties of database transactions:

• A tomicity: All operations in a transaction are either successful or fail.
• C onsistency: Before and after the transaction is executed, the database is in a consistent state.
• I solation: Concurrent transactions do not interfere with each other.
• D urability: Once a transaction is committed, the result is permanent.

In MongoDB, starting from version 4.0, single-document operations are ACID by default . Starting in version 4.2, MongoDB supports multi-document ACID transactions , including across multiple collections, databases, and even sharded clusters (gradually supported from 4.2).

Multi-document transactions: support scope

MongoDB's multi-document transaction supports the following scenarios:

• Replica Set : Supported from 4.0.
• Sharded Cluster : Supported since 4.2, but with more limitations and performance considerations.

Note: Cross-shash transactions require coordinator (mongos) to participate, which has greater performance overhead. It is recommended to avoid high-frequency use as much as possible.

How to use transactions (example)

Here is an example of a multi-document transaction using Node.js driver:

 const session = client.startSession();
session.startTransaction();

try {
  const db = client.db('bank');

  // Deduct the balance of the three await db.collection('accounts').updateOne(
    { name: 'zhangsan', balance: { $gte: 100 } },
    { $inc: { balance: -100 } },
    { session }
  );

  // Increase Li Si balance await db.collection('accounts').updateOne(
    { name: 'lisi' },
    { $inc: { balance: 100 } },
    { session }
  );

  await session.commitTransaction();
  console.log('Transfer successfully');
} catch (error) {
  await session.abortTransaction();
  console.error('Transaction failed, rolled back', error);
} finally {
  await session.endSession();
}

Key points:

• session must be used to start the transaction.
• All operations must be passed in session parameters.
• Use try-catch to handle exceptions and roll back.
• Finally, endSession() is called to release the resource.

Transaction usage restrictions and precautions

• High performance overhead : transactions will be locked, and long-running transactions may cause blockage.
• Timeout limit : By default, transactions must be completed within 60 seconds (can be adjusted via transactionLifetimeLimitSeconds , but it is not recommended to be too long).
• Some commands cannot be used across multiple shard transactions : such as eval , mapReduce , etc.
• ReadConcern, writeConcern, and readPreference need to be set at the transaction level and cannot be specified separately in the operation.

suggestion:

• Shorten the transaction execution time as much as possible.
• Avoid performing network requests or time-consuming calculations in transactions.
• Priority is given to single document atomic operations, and no transactions can be used.

Single document atomicity: the first choice for daily development

MongoDB's single document update naturally supports atomicity. For example:

 db.accounts.updateOne(
  { name: "zhangsan", balance: { $gte: 50 } },
  { $inc: { balance: -50 }, $push: { history: "paid 50" } }
)

This operation is atomic: either all succeed or fail, and there will be no situation where only money is deducted and history is not recorded.

Design recommendation : Putting relevant data in one document through embedded documents or arrays can avoid multi-document transactions, improve performance and scalability.

Summarize

• MongoDB supports ACID transactions, including multi-document transactions (replica sets and shard clusters).
• Transactions are suitable for short-term operations with strong consistency requirements , such as financial transfers, inventory deductions, etc.
• In daily development, it is preferred to use data modeling with reasonable operation of single-document atoms to avoid transactions.
• Be cautious when using transactions in sharded clusters, pay attention to performance and timeout limits.

Basically, MongoDB's ACID capabilities are enough to cope with most scenarios. The key is to choose the usage method according to business needs.

The above is the detailed content of ACID Transactions in MongoDB. For more information, please follow other related articles on the PHP Chinese website!