Atomicity in Database

Atom শব্দের অর্থ পরমাণু। এমন নামকরণের কারণ নিশ্চয় এই যে, একসময় মনে করা হতো এটাই পদার্থের ক্ষুদ্রতম কণা, যাকে আর ভাঙ্গা যায় না। পরবর্তীতে পরমাণুর বিভেজ্যতার প্রমাণ মিললেও ইংরেজিতে যেকোনো কিছুর ক্ষুদ্রতম একক বোঝাতে এখনো Atom শব্দের ব্যবহার দেখা যায়। অতএব Atomicity বলতে বস্তুর এই অবিভেজ্যতাকে বোঝায়। কিন্তু Database এ Atomicity বলতে আসলে কী বোঝানো হয়?

Database এ Atomicity বলতে এক বা একাধিক কুয়েরি অপারেশনের এমন সিঙ্গেল ইউনিট অফ ওয়ার্ক প্রপার্টিকে বোঝানো হয়। তবে একটা সিঙ্গেল কুয়েরি অপারেশনের জন্য এটা চিন্তা করা খুব স্বাভাবিকই মনে হবে। কারণ ব্যাপারটাকে তখন ফর গ্র্যাণ্টেড ধরা হয় যে, এই অপারেশন হয় পুরোপুরি সাকসেসফুল হবে, না হয় পুরোটাই ক্যান্সেল হবে।

মানে আমি কোনো টেবিলের পার্টিকুলার একটা row এর কিছু column যদি আপডেট করি, এটা হয় সবগুলো column ই আপডেট করবে না হয় কোনো column ই আপডেট করবে না। এবং যেকোনো RDBMSএ সিঙ্গেল কুয়েরি অপারেশনের জন্য এই প্রপার্টিটা ইনবিল্ট থাকে তাই সিংগেল কুয়েরি অপারেশনের জন্য আলাদা করে Atomicity নিয়ে ভাবা লাগে না।

কিন্তু কেইসটা যদি এমন হয়, দুইটা ডিফরেন্ট Write অপারেশন আসলে একটা পার্টিকুলার টাস্কই সম্পাদন করে, মানে তারা আদতে একটা সিঙ্গেল ইউনিট অফ ওয়ার্কই কমপ্লিট করছে, তখন Atomicity নিয়ে আলাদা করে ভাবা লাগে, না হয় Data inconsistency তৈরি হবে। ডাটাবেজে একাধিক কুয়েরির এমন সিঙ্গেল ইউনিট অফ ওয়ার্ক মেইনটেইন করার জন্য Transaction ইউজড হয়। এটার সবচেয়ে জনপ্রিয় ব্যবহার হলো ব্যাংকিং সফটওয়্যার গুলোতে। উদাহরণ দিলে দাঁড়ায়,

ধরা যাক, কোনো ব্যাংকিং সিস্টেমে একাউন্ট A থেকে অন্য আরেকটা একাউন্ট B তে কিছু মানি ট্রান্সফার হবে। এক্ষেত্রে সব রকম ভ্যালিডিটি চেক করার পর হাই লেভেল থেকে যদি বলি, খুব স্বাভাবিক ভাবেই একাউন্ট A থেকে যে পরিমাণ টাকা ডেবিট হবে, একাউন্ট B তে সমপরিমাণ টাকা ক্রেডিট হওয়া লাগবে। এখন আমরা এই মানি ট্রান্সফারের কুয়েরিগুলো যদি সিকুয়েনশালি লিখি, তাহলে নিশ্চয় একটা আপডেট কুয়েরি দিয়ে প্রথমে একাউন্ট A থেকে X পরিমাণ টাকা মাইনাস করে নিবো। এরপর এটা সাকসেসফুল হলে ঠিক X পরিমাণ টাকা Account B তে যোগ করার জন্য ডাটাবেজে আরেকটা আপডেট কুয়েরি লিখে ফেলবো। এবং হ্যাপি কেইসে দেখা যাবে, ঠিকঠাক দুইটা একাউন্টেই ডেবিট এবং ক্রেডিট ক্রিয়া সম্পন্ন হচ্ছে। কিন্তু এভাবে সিকুয়েনশালি কুয়েরি লিখলে একটা কঠিন বিপদ আছে।

একটা কেইস চিন্তা করি। ধরা যাক, আমরা একাউন্ট A থেকে ডেবিট করার পরপর এবং একাউন্ট B তে আপডেট কুয়েরি চলার আগেই ডাটাবেজের সার্ভার ডাউন হয়ে গেলো, এটা পাওয়ার অফ হওয়ার জন্য হতে পারে, হঠাৎ সার্ভিস রিস্টার্ট খাওয়ার জন্য হতে পারে বা যেকোনো ন্যাচারাল ডিজেস্টারের কারণেও হতে পারে। তাহলে দেখা যাবে একাউন্ট A থেকে আমরা X পরিমাণ টাকা মাইনাস করে ঠিকঠাক আপডেট করতে পারছি ঠিকই, কিন্তু সমপরিমাণ টাকা আমরা একাউন্ট B তে যোগ করতে পারি নাই। এমন Data Inconsistency কোনোভাবেই গ্রহণযোগ্য নয়, এবং ব্যাংকিং সিস্টেমে এটা একটা বড়ো ডিজেস্টার।

কাজেই এই ধরনের একাধিক ডাটাবেজ কুয়েরি অপারেশন যেগুলো আসলে ইন্টাররিলেটেড এবং একটা সিঙ্গেল ইউনিট অফ ওয়ার্কের মতো, সেগুলো এভাবে সিকুয়েনশালি রান করা যাবে না। এর জন্য দরকার পড়ে Transaction এর। Transaction এর একটা বৈশিষ্ট হলো, এখানে একটা ইউনিট অফ ওয়ার্ক পুরোপুরি Comitted না হলে, ইতোমধ্যে সম্পন্ন হওয়া কুয়েরিগুলো আবার Rollback করানো যায়। কাজেই সার্ভার যখন আপ হবে, তখন একটা ইনকমপ্লিট ট্রাঞ্জেকশনের পূর্বেকার কুয়েরিগুলো সে Rollback করে আগের অবস্থায় ব্যাক করতে পারে।

Atomicity ডাটাবেইজের ACID property এর মধ্যে অন্যতম। বাকী ৩ টা প্রপার্টি হলো, Consistency, Isolation এবং Durability। Atomicity এর অভাবে Data consistency নষ্ট হয়। কিন্তু এটা মনে রাখা বা বোঝা গুরুত্বপূর্ণ যে, Transaction ব্যবহার করলেই আপনা আপনি Consistency অর্জন করা হয়ে যায় না। এক্ষেত্রে Isolation level গুলো বোঝা জরুরী। কারণ দুইটা ডিফ্রেন্ট transaction একটা সেইম row কে কনকারেন্টলি এফেক্ট করতে পারে। তখন নানান রকম Read phenomenon তৈরি হয়। যেমন Dirty Read, Non repeatable read, phantom read, lost update। এগুলো বিভিন্ন টেকনিক ব্যবহার করে Handle করা হয়ে থাকে। যেহেতু শুধু Atomicity নিয়ে লেখা তাই এটা নিয়ে লিখে ভারী করলাম না। পরে একসময় লেখা যাবে।