Episode 6: DataGaav mein Concurrency ka Jaadu: Ravi aur Anu ka Kissa

 

DataGaav mein Concurrency ka Jaadu: Ravi aur Anu ka Kissa

Gaanv ki ek ladki curiosity ke saath poochhti hai, “Agar Ravi apne document par changes kar raha hai aur Anu bhi ussi waqt apne document par kaam kar rahi hai, toh Anu ko Ravi ke update wale data milenge ya purane?”

Mongo Baba muskurate hue samjhane lagte hain, “Beta, yehi toh MongoDB ke concurrency ka jaadu hai. Chalo main tumhe yeh jaadu aur clearly samjhata hoon.”


Concurrency Example: Ravi aur Anu ki Situation

Ravi ka Update:

Ravi apne document ko update kar raha hai. MongoDB Ravi ke document par document-level lock laga deta hai. Matlab, Ravi jab tak apne changes complete nahi kar leta, kisi aur ko us document tak access nahi milega.

  • Ravi ne apne document mein "marks" ko update kar diya:

    db.students.updateOne({ name: "Ravi" }, { $set: { marks: 90 } });

Anu ka Access:

Anu apne document par kaam kar rahi hai, lekin uska document Ravi ke document se alag hai. Anu apne document ko freely access kar sakti hai aur koi bhi changes kar sakti hai.

  • Anu ne apne document mein "attendance" check karna chaha:

    db.students.findOne({ name: "Anu" });

Anu ko Ravi ke Document ka Data Kab Milega?

Agar Anu abhi Ravi ke document ko access karti hai, tab bhi usko purana data hi milega, kyunki Ravi ka update operation abhi complete nahi hua hai. Jaise hi Ravi apna update operation complete kar lega, lock release ho jayega. Uske baad agar Anu wo document access karegi, toh usko naya update wala data milega.

  • Anu agar Ravi ke document ko immediately uske update ke baad access karti hai:
    db.students.findOne({ name: "Ravi" });
    Usko updated marks 90 milenge.

Seekh: Concurrency ka Jaadu

Mongo Baba ne samjhaya ki MongoDB mein concurrency ka jaadu is tarah se kaam karta hai:

  • Document-Level Locking ensure karta hai ki specific document par operation complete hone tak us par lock laga rahe. Is wajah se multiple users apne-apne documents par kaam kar sakte hain bina kisi conflict ke.

  • Anu ko Ravi ke document ka updated data tabhi milega jab Ravi apne operation ko complete kar lega aur MongoDB lock ko release kar dega.

DataGaav ke bacchon ne yeh concept clear kar liya ki MongoDB ka concurrency management kaise data consistency aur performance ko maintain karta hai.

Sence2 : DataGaav mein Concurrency ka Jaadu: MySQL ka Purana Formula

Jab DataGaav ke ek sharrti chacha ne pucha, "MySQL mein concurrency ka jaadu kaise hota tha?", to Mongo Baba ne apni yaadon mein kho kar unhe samjhaya ki MySQL apne tareeke se concurrency manage karta tha. Yeh story purane zamaane ke techniques ka hai, jo aaj bhi kuch jagah use hoti hain.


1. MySQL Concurrency: Locking Mechanism

MySQL concurrency ko manage karne ke liye locking mechanisms ka use karta hai. Yeh locks ensure karte hain ki data consistency rahe aur conflicts na ho, jab multiple users ek hi data par simultaneously operations perform karte hain.

Locking Types in MySQL:

  1. Table-Level Locking:

    • Purane zamaane mein, MySQL ke MyISAM storage engine mein table-level locking hota tha. Jab ek user table mein kuch update kar raha hota, to puri table par lock lag jata tha.

    • Example: Agar Ravi "students" table mein apne marks update kar raha hai, to Anu us table mein kisi bhi record ko modify ya access nahi kar sakti thi jab tak Ravi ka update operation complete nahi ho jata.

    • Pro Tip: Yeh locking mechanism performance issues create karta tha jab multiple users same table par operations perform karte, kyunki sabko wait karna padta.

  2. Row-Level Locking:

    • Fir aaya InnoDB storage engine ka zamaana, jisme row-level locking ka use hone laga. Isme sirf wahi row lock hoti thi jisme changes ho rahe hote the, baki rows freely accessible rahte the.

    • Example: Agar Ravi "students" table mein apne specific record ko update kar raha hai, to sirf usi record par lock lagega, aur Anu dusre records ko freely access kar sakti hai.

    • Pro Tip: Is locking mechanism ne concurrency ko kaafi improve kiya, kyunki ab multiple users apne-apne rows par kaam kar sakte hain bina kisi conflict ke.


2. Transactions ka Jaadu in MySQL

MySQL mein transactions ka concept bhi hota hai jo concurrency ko aur bhi smooth banata hai. Transactions ek group of operations ko ek saath execute karte hain, aur ya to saare operations successfully complete hote hain ya koi bhi nahi.

  • Example: Ravi ne decide kiya ki wo apne marks update karega aur saath hi apna attendance bhi. Dono operations ek transaction ke under execute hote hain:
    START TRANSACTION; UPDATE students SET marks = 90 WHERE name = 'Ravi'; UPDATE students SET attendance = 'Present' WHERE name = 'Ravi'; COMMIT;
    • Agar dono operations successfully complete hote hain, to COMMIT ho jata hai aur changes permanently save ho jate hain.
    • Agar koi problem aati hai, to ROLLBACK ho jata hai aur koi bhi changes apply nahi hote, ensuring data consistency.

3. MySQL mein Isolation Levels ka Jaadu

MySQL mein Isolation Levels use hote hain jo define karte hain ki ek transaction ka effect doosri transactions par kaise padta hai. Yeh levels ensure karte hain ki data consistency maintained rahe, aur multiple transactions efficiently execute ho sake.

Common Isolation Levels:

  1. READ UNCOMMITTED: Sabse kam isolation. Ek transaction doosri transaction ke incomplete (uncommitted) changes dekh sakti hai.
  2. READ COMMITTED: Ek transaction sirf doosri transaction ke committed changes dekh sakti hai.
  3. REPEATABLE READ: Ek transaction ke during, agar wahi data multiple baar read kiya jaye, to hamesha same result milega, chahe doosri transactions ho rahi ho.
  4. SERIALIZABLE: Sabse zyada isolation. Transactions ko serially execute kiya jata hai, jaise ek ek karke perform ho rahe ho.
  • Example: Gaanv mein agar Ravi apne transaction ko "REPEATABLE READ" isolation level par set kare:
    SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
    Ab Ravi ke transaction ke dauran, wo hamesha consistent data hi dekhega, chahe doosri transactions chal rahi ho ya nahi.

DataGaav ke Chacha ki Seekh

Sharrti chacha ne yeh samajh liya ki MySQL apne locking aur transaction mechanisms ke zariye concurrency ko kaise manage karta tha. Unhone dekha ki kaise purane zamaane ke table-level locking se naya row-level locking system aaya, jo zyada efficient hai. Transactions aur isolation levels ne MySQL ke concurrency management ko aur bhi robust bana diya.

Mongo Baba ne muskurate hue chacha se poocha, “Chacha, ab samajh mein aaya na ki MySQL ka concurrency ka jaadu kaise kaam karta tha?”

Chacha ne apni sharrti muskaan ke saath kaha, “Bilkul Baba! Ab main apni purani yaadon mein kho gaya hoon, yeh jaadu mere kaam aayega.”


DataGaav mein aaj ka kissa yahin khatam hota hai. Aur koi sawaal ya kissa ho to batao!

Post a Comment

0 Comments