كيف تعمل المعاملات في MongoDB؟

Question

Accepted Answer

MongoDB يدعم **معاملات ACID متعددة الوثائق** (منذ الإصدار 4.0 للمجموعات المتكررة، الإصدار 4.2 للمجموعات الموزعة) — تجميع العمليات عبر وثائق/مجموعات متعددة بحيث تنجح جميعها أو تفشل جميعها. ومع ذلك، نموذج الوثائق في MongoDB غالباً ما يجعل المعاملات *غير ضرورية* من خلال العمليات الذرية على وثيقة واحدة.

## العمليات على وثيقة واحدة ذرية بالفعل

```text
KEY POINT: operations on a SINGLE document are ALWAYS atomic in MongoDB.
→ Because related data is often EMBEDDED in one document, many operations that would
  need a transaction in SQL are a single atomic document update in MongoDB.
→ Good schema design (embedding) often eliminates the NEED for multi-doc transactions.
```

```js
// updating a document and its embedded array atomically — NO transaction needed
db.accounts.updateOne(
  { _id: id },
  { $inc: { balance: -100 }, $push: { transactions: { amount: -100 } } }
);  // atomic — both changes succeed or fail together (single document)
```

## معاملات متعددة الوثائق (عند الحاجة الفعلية)

```js
// for operations across MULTIPLE documents/collections that must be atomic
const session = db.getMongo().startSession();
session.startTransaction();
try {
  db.accounts.updateOne({ _id: 1 }, { $inc: { balance: -100 } }, { session });
  db.accounts.updateOne({ _id: 2 }, { $inc: { balance: 100 } }, { session });
  session.commitTransaction();        // both succeed together
} catch (e) {
  session.abortTransaction();          // or both roll back
} finally {
  session.endSession();
}
```

معاملات متعددة الوثائق (باستخدام جلسة عمل) توفر ضمانات ACID عبر الوثائق — للحالات مثل التحويل بين وثائق حسابات منفصلة.

## استخدم المعاملات بحذر

```text
✓ Transactions are available and provide ACID across documents WHEN NEEDED
✗ But they have PERFORMANCE COSTS (overhead, locking) — don't overuse them
→ PREFER good schema design (embedding related data) so single-document atomic
  operations suffice. Use multi-document transactions only when data genuinely
  spans documents and must be consistent (e.g. money transfers between accounts).
→ Requires a replica set (not standalone).
```

## لماذا يهم

فهم معاملات MongoDB — والأهم من ذلك متى تكون مطلوبة — مهم لضمان اتساق البيانات في تطبيقات MongoDB، لذلك هو معرفة قيمة لبناء أنظمة صحيحة.

الرؤية الأكثر أهمية هي أن **العمليات على وثيقة واحدة ذرية دائماً** في MongoDB، وبما أن نموذج الوثائق يشجع على **دمج البيانات المرتبطة في وثيقة واحدة**، فإن العديد من العمليات التي ستتطلب معاملة في قاعدة بيانات علائقية (حيث يتم تقسيم البيانات المرتبطة عبر الجداول) هي **تحديث وثيقة ذري واحد** في MongoDB — لذا **تصميم المخطط الجيد غالباً ما يلغي الحاجة إلى معاملات متعددة الوثائق**.

هذه نقطة مفهوم رئيسية: الذرية لكل وثيقة في MongoDB، مدمجة مع الدمج، تتعامل مع العديد من احتياجات الاتساق بدون معاملات.

فهم أن MongoDB **يدعم بالفعل معاملات ACID متعددة الوثائق** (منذ الإصدار 4.0+) للحالات التي تمتد فيها العمليات فعلياً عبر وثائق/مجموعات متعددة (مثل التحويل بين وثائق حسابات منفصلة) مهم — فهي متاحة عند الحاجة الفعلية، توفر ضمانات الكل أو لا شيء.

من المهم بنفس القدر التوجيه باستخدام **المعاملات بحذر**: لديها تكاليف الأداء (الحمل الإضافي، القفل)، لذا النهج المفضل هو تصميم المخطط الجيد (الدمج) بحيث تكون العمليات الذرية على وثيقة واحدة كافية، مع حجز معاملات متعددة الوثائق للاحتياجات الفعلية للاتساق عبر الوثائق.

فهم هذا — الذرية على وثيقة واحدة، أن الدمج غالباً ما يزيل الحاجة للمعاملات، أن معاملات متعددة الوثائق موجودة للعمليات المطلوبة فعلياً، والتفضيل للتصميم على حساب المعاملات — يعكس حكماً سليماً في MongoDB.

بما أن اتساق البيانات حرج ونهج MongoDB (الذرية لكل وثيقة + معاملات اختيارية) يختلف عن نموذج معاملات SQL، فهم معاملات MongoDB — خاصة أن العمليات على وثيقة واحدة ذرية، والدمج يقلل احتياجات المعاملات، ومعاملات متعددة الوثائق متاحة لكن يجب استخدامها بحذر — معرفة قيمة ومهمة لضمان الاتساق بشكل صحيح وفعال في تطبيقات MongoDB، موضوع يعكس فهم نموذج الاتساق في MongoDB وممارسات التصميم الجيدة.