ব্যাকএন্ড ডেভেলপমেন্ট করতে গেলে আমাদের প্রাথমিক অবস্থায় ডাটাবেজের একদম গভীরে না গেলেও একটা নির্দিষ্ট সীমা পর্যন্ত স্টাডি করতে হয়। এরপর সেই নির্দিষ্ট সীমায় গেলে আরো বেশি স্টাডি করতে হয়। ডাটাবেজ হলো ব্যাকএন্ড ডেভেলপমেন্টের সবচেয়ে ক্রিটিকাল একটা পার্ট। এটা নিয়ে পড়াশোনার শেষ নেই। সারাজীবন করতে চাইলে তাও পারবেন। কিন্তু শেষ হবে না। ডাটাবেজ কেন এত গুরুত্বপূর্ন? কারণ পৃথিবীটা চলছে ডাটার উপর। ডাটা কিভাবে ক্রিয়েট করতে হবে, কিভাবে স্কেল করতে হবে, কিভাবে মাল্টি রিজিওনে আমাদের ডাটা সমানভাবে রীড, রাইট এবং আপডেট করতে পারবে এগুলো নিয়েই মূলত চলছে। এই ডাটার সিকিউরিটিও অনেক বড় একটা বিষয়। আমরা একটু এদিক থেকে ওদিক ভুল করলেই ডাটা হ্যাকররা চুরি করে ফেলবে। যদি ডাটাবেজ ম্যানেজ করার দায়িত্ব ব্যাকএন্ড ডেভেলপারের না। কিন্তু যদি ভাল একটা জ্ঞান না থাকে তাহলে কোথায় কোথায় ডাটা লিক হতে পারে, কোথায় কোথায় হ্যাকাররা অ্যাটাক করতে পারে সেটা আমরা ধরতে পারবো না। যেকারণে সিকিউরড অ্যাপ্লিকেশন তৈরি করাটা অনেক কঠিন হয়ে পড়ে। সুতরাং আমাদের দায়িত্ব না এমন একটা সেক্টরে আমাদের স্টাডি করতে হবে। বিগিনার লেভেলে আমাদের অতো গভীরে যেতে না হলেও যতোই আমরা বিগিনার থেকে ইন্টারমডিয়েট, ইন্টারমিডিয়েট থেকে অ্যাডভান্সড লেভেলে যাবো ততোই আমাদের দরকার পড়বে ডাটাবেজের অনেক গভীরে গিয়ে এর আর্কিটেকচারটা বুঝা, যাতে আমরা বুঝতে পারি কিভাবে কোড করলে আমাদের ডাটা লিক হওয়ার কোনো সম্ভাবনা থাকবে না।

আমরা ডাটাবেজের নাম কমবেশি সবাই শুনলেও আমরা ডাটাবেজ সম্পর্কে খুব বেশি কেউই জানিনা। আজকের লেকচারে আমরা ডাটাবেজ সম্পর্কে একটা ধারণা নেয়ার চেষ্টা করবো।

সাধারণত ব্যাকএন্ড ডেভেলপার হিসেবে আমাদের এই সিদ্ধান্ত নিতে হয় না যে আমরা কোনো ডাটাবেইজ ব্যবহার করবো। এই দায়িত্ব সল্যুশন আর্কিটেক্টের। সল্যুশন আর্কিটেক্ট বিজনেস রিকোয়ারমেন্ট অ্যানালাইসিস করে ঐ বিজনেস রিকোয়ারমেন্টের জন্য কোন ধরণের ডাটাবেজ ঠিক হবে সেটা ডিসিশন নিবে। ব্যাকএন্ড ডেভেলপার হিসেবে আমাদের দায়িত্ব হলো ঐ ডাটাবেজকে ইমপ্লিমেন্ট করা। কিন্তু যেহেতু আমরা এই কোর্সে সল্যুশন আর্কিটেক্ট নিয়ে কিছুটা জানবো যতটা না জানলে নয়, তাই ধরে নিচ্ছি আমিই সব ডিসিশন নিবো। আমি একাই ক্লাউড ইঞ্জিনিয়ার, আমি একাই ডেভঅপ্স, আমি একাই সল্যুশন আর্কিটেক্ট, আমি একাই ডেভেলপার। তো সে হিসেবে কি কি ধরণের ডাটাবেজ মার্কেটে আছে, কোন কাজের জন্য কোন ধরণের ডাটাবেজ ব্যবহার হয় তার একটা ছোট জ্ঞান যদি আমাদের থাকে তবে সবচেয়ে সহজ হয় ইন্টারভিউ ক্র্যাক করতে। আমরা সাধারণত ডাটাবেজ বলতে বুঝি SQL এবং NoSQL Database. SQL বলতে আমরা বুঝি MySQL, PostgreSQL আর NoSQL বলতে বুঝি MongoDB। যদি আমাদের অন্যান্য ডাটাবেজ সম্পর্কেও ন্যুনতম ধারণা থাকে তাহলে আমাদের জন্য ইন্টারভিউ ক্র্যাক করতে সুবিধা হবে। প্রোগ্রামিং ল্যাঙ্গুয়েজের যেমন প্যারাডাইম আছে, ডাটাবেজেরও প্যারাডাইম আছে। আমরা যদি ইন্টারনেটে সার্চ করি আমরা সাত ধরণের ডাটাবেজ প্যারাডাইম পাবো। এগুলো হলোঃ

1. Key Value Database - Key Value ডাটাবেজ একদম জাভাস্ক্রিপ্ট অবজেক্ট বা পাইথনের ডিকশনারির মতো। এটা ইন মেমোরি ডাটাবেজ। তার মানে এটা র‍্যামের মধ্যে ডাটা স্টোর করে। তবে সমস্যা হলো এটা স্টেবল না। পিসি কোনো কারণে রিস্টার্ট বা শাট ডাউন হয়ে গেলে ডাটা হারিয়ে যাবে। এই প্যারাডাইমের মধ্যে Redis, MEMcached, Amazon DynamoDB এই তিনটা ডাটাবেজ খুব জনপ্রিয়। বাইরের কোম্পানিতে যদি জব করতে যান তাহলে অবশ্যই ডায়নামোডিবি সম্পর্কে জানতে হবে। এটা আসলে কোন ক্যাটাগরিতে ফেলা যায় সেটা বুঝার কোনো জায়গা নাই। এর অফিসিয়াল সাইটে একে NoSQL বলা হলেও এর বিহেভিয়ার অনুযায়ী একে key value databse ও বলা যায় আবার wide-column database ও বলা যায়। যদি কোনো জায়গায় কন্টিনিউ ডাটা হিট হচ্ছে, তাহলে দ্রুত ডাটা রীড করার জন্য এটা ব্যবহার করা হয়। এটা অনেক ফাস্ট। এটা শেখাটা খুব সহজ। কিন্তু আমার বিজনেস রিকোয়ারমেন্ট অনুসারে এই ডাটাবেজে ফিট করাটা হচ্ছে খুব কঠিন। এতে রয়েছে পার্টিশন কী, হ্যাশ কী এবং অ্যাট্রিবিউটস।

   

2. Wide-Column Database - এটা অনেকটা কী ভ্যালু ডাটাবেজের মতোই শুধু এর সাথে একটা সেকেন্ড ডাইমেনশন যোগ করে দিবেন। আমরা ডায়নামোডিবির বেলায় যেটা বললাম এখানে পার্টিশন কী, হ্যাশ কী এবং অ্যাট্রিবিউটস রয়েছে, সেরকম এই ডাটাবেজের ক্ষেত্রে আপনি একটা কী এর বিপরীতে মাল্টিপল অ্যাট্রিবিউটস ইউজ করতে পারবেন। ডায়নামোডিবিতেও পারবেন। তাই উপরের প্যারায় বলেছিলাম এটাকে wide-column database ও বলে। এই প্যারাডাইমের মধ্যে সবচেয়ে জনপ্রিয় হচ্ছে Cassandra। NoSQL ডাটাবেজের মধ্যে MongoDB এর পর সবচেয়ে জনপ্রিয় ডাটাবেজ হলো Cassandra। MongoDB তে আপনি যদি Atlas cloud service ব্যবহার করেন তাহলে ঠিক আছে। কিন্তু যদি কমিউনিটি এডিশনে আপনি অ্যাপ্লিকেশনকে স্কেল করতে চান বা ৯৯.৯৯% আপটাইম প্রোভাইড করতে চান তবে আপনাকে অনেক ঝক্কি পোহাতে হবে। এসব কাজের জন্য Cassandra বেস্ট। এছাড়াও রয়েছে Apache Hbase। যদিও Cassandra এবং MongoDB দুইটাই NoSQL তবে দুইটার কনসেপ্ট টোটালি ভিন্ন।

   

3. Document Oriented Database - Document Oriented Database বলতে আমরা বুঝি MongoDB। যদিও আমরা MongoDB বলতে বুঝি NoSQL। কিন্তু এটা ডাটাবেজের কোনো টাইপের মধ্যেই পড়ে না। এটার মানে হচ্ছে যেটা সিক্যুয়্যাল না। এরকম অনেক NoSQL ডাটাবেজ আছে, যেমনঃ Cassandra, DynamoDB, IndexedDB, Apache Hbase, Redis, MemCached। কিন্তু যদি আমরা MongoDB কে একটা টাইপ দেয়ার চেষ্টা করি সেটা হলো Document Oriented Database। এখন Document Oriented Database বলতে কি বুঝায় সেটাই আমাদের আজকের মূল আলোচ্য বিষয়। সেটা নিয়ে আমরা বিস্তারিত আলোচনা করবো। তাই এখন এটা এড়িয়ে যাচ্ছি। এছাড়াও এই টাইপের ডাটাবেজের মধ্যে Firebase কেও রাখা যায়।

4. The Relational Database - আমরা ডাটাবেজ বলতেই বুঝতাম রিলেশনাল ডাটাবেজ। কি কি আছে এতে? এতে আছে MySQL, PostgreSQL, Microsoft SQL ইত্যাদি। যেখানে টেবিল রয়েছে, রো রয়েছে, কলাম রয়েছে সেগুলোই রিলেশনাল ডাটাবেজ। আর এখানে একটা কমন কুয়েরি ল্যাঙ্গুয়েজ রয়েছে, যেটা দিয়ে ডাটা কুয়েরি করে আনা হয়।
5. Graph Database - এটা নিয়ে লেকচার ১৫ তে আলোচনা করা হয়েছে। আপনারা আশা করি সেটা সম্পর্কে অলরেডি ভালভাবেই বুঝেছেন। না বুঝে থাকলে একটু লেকচার ১৫ তে গিয়ে পড়ে নিবেন।
6. A Full Text Search Engine - একে আবার ইনডেক্স ডাটাবেজও বলা হয়। ইনডেক্সিং করা এর কাজ। ইনডেক্স করা হয় মূলত কোনো একটা ডাটাকে সার্চ করে আনার জন্য। হ্যাশিং অ্যালগরিদম এখানে কাজ করে, বা হ্যাশ টেবিলের মতো একটা কনসেপ্ট এখানে কাজ করে। সেটা বিস্তারিত আমরা জানবো যখন ইনডেক্স নিয়ে জানবো। এখন আমাদের এত গভীরে যাওয়ার প্রয়োজন নেই। ধরেন আমাদের কোনো প্রোডাক্টের ৫০টা প্রোপার্টিজ রয়েছে। ঐ ৫০টা প্রোপার্টিজ আমাদের ডাটাবেজে স্টোর করে রাখতে হবে। কিন্তু যখন আমরা সার্চ করছি তখন আমরা হয় টাইটেল দিয়ে সার্চ করছি, নাহয় ট্যাগ দিয়ে সার্চ করছি, অথবা ক্যাটাগরি দিয়ে সার্চ করছি, অথবা প্রাইস দিয়ে সার্চ করছি। এখানে আরো অনেক অ্যাট্রিবিউটস থাকতে পারে। কিন্তু আমরা সার্চ করার জন্য নির্দিষ্ট কিছু প্রোপার্টিজ ব্যবহার করি। এখন যেগুলো দিয়ে আমরা সার্চ করি সেই সার্চিং কনসেপ্টগুলোকে আমরা ইনডেক্স করে রাখতে পারি সহজে এক্সেস করার জন্য। যখন আমরা ইনডেক্স করি তখন এগুলো একটা হ্যাশ টেবিলের মধ্যে চলে যায় যেখানে আমাদের রীড অপারেশন কমপ্লিট হতে O(1) পরিমাণ সময় লাগে। তার মানে এটা খুব দ্রুত কাজ করে ইনডেক্স করার মাধ্যমে। আমরা যেকোনো ডাটাবেজে ইনডেক্স করতে পারি, কিন্তু A Full Text Search Engine ডাটাবেজগুলো ইনডেক্স করার কাজেই ব্যবহৃত হয়। এরা অরিজিনাল ডাটা স্টোর করে না, তাই এরা খুবই ফাস্ট হয়। এখানে শুধুমাত্র সার্চ করার অপারেশনগুলোই পাওয়া যাবে। আপনি চাইলে এই ডাটাবেজগুলোকে নরমাল ডাটাবেজগুলোর মতো ব্যবহার করতে পারেন, কিন্তু এগুলোর খরচ অনেক বেশি। যে কারণে শুধু ইনস্ট্যান্ট সার্চ রেজাল্ট দেয়ার জন্য যা যা দরকার শুধুমাত্র সেগুলোই এখানে ব্যবহার করা হয়। এই ধরণের ডাটাবেজের মধ্যে রয়েছে Algolia যেটা নতুন এসেছে। এটা Open AI3 ব্যবহার করে। যার কারণে আপনি যেটা সার্চ করেছেন সেটা পুরোপুরি ম্যাচ না করলেও যদি তার ভাবার্থ অনুযায়ী কিছু থাকে ডাটাবেজে সেটা খুঁজে বের করে আনার পাওয়ার রাখে Algolia। এটা নেক্সট জেনারেশন সার্চ ইঞ্জিন। আর বহু বছর ধরে মার্কেটে রয়েছে Elastic Search। এটা Old জেনারেশন। এখানে অবশ্যই টেক্সট ম্যাচ হতে হবে। ম্যাচ না হলে ডাটা বের করতে পারবে না। তবে এটা ইন্ডাস্ট্রিয়ালি প্রমাণিত। প্রচুর ব্যবহার হয় এটা।
7. Multi Model Database - এর মধ্যে আছে Fauna DB। মেইনলি ডাটাবেজ থেকে GraphQL এ রূপান্তরিত করার কাজ করে থাকে। এটা অনেকটা প্রোগ্রামিং ল্যাঙ্গুয়েজের খুব কাছাকাছি। এখানে যেকোনো কিছু হতে পারে। কিন্তু এখনও পর্যন্ত এটা সেরকম পপুলার না।

প্রাথমিক অবস্থায় আমাদের এত ডাটাবেজ সম্পর্কে অতো বেশি জানতে হবে না। আমাদের এটুকু জানলেই হবে যে এরকম একটা ডাটাবেজ রয়েছে, আর এই টাইপের কাজ করার জন্য এই ডাটাবেজ ইউজ করা হয়। আমরা প্রথমে শিখবো MongoDB। পরবর্তীতে আমরা যখন ভাল মাপের ডেভেলপার হয়ে যাবো, যখন আমাদের মধ্যে বিশ্বাস আসবে MongoDB ব্যবহার করে Data Model, Aggregation, Transaction সহ যা যা করা দরকার সবই করতে পারি, আমার কোনো সমস্যা হয় না, তখন আমরা অন্য নতুন একটা ডাটাবেজ এক্সপ্লোর করার চেষ্টা করবো।

এই ক্লাসে একটা প্রশ্ন এসেছিলো আমরা Redis কখন ব্যবহার করবো? আমরা মূলত Redis ক্যাশিং করার কাজে ব্যবহার করবো। ধরেন আপনার অনলাইনে মোবাইলের ওয়েবসাইট আছে। এখন নতুন কোনো মোবাইল আসলো। সে মোবাইলের ইনফরমেশনের জন্য ১ লক্ষ মানুষ রিকোয়েস্ট দিলো। এখন এই ১ লক্ষ রিকোয়েস্ট প্রতিবার ডাটাবেজ থেকে প্রসেসিং করে আনতে অনেক খরচ পড়ে যায়। আমরা সেক্ষেত্রে রেডিস ব্যবহার করে প্রথমবার সে রিকোয়েস্ট ডাটাবেজ থেকে প্রসেসিং করে ইন মেমোরিতে ক্যাশিং করে রেখে দিবো। মোবাইল তো আর প্রতিদিন আসে না। ধরেন আমি ২৪ ঘন্টার টাইম লিমিট দিয়ে দিলাম, ডাটা ২৪ ঘন্টা আপডেট হবে না। ২৪ ঘন্টা পর অটোমেটিক ডাটা মেমোরি থেকে হারিয়ে যাবে, আবার নতুন করে ডাটা ডাটাবেজ থেকে প্রসেস করে আনবে। এই ২৪ ঘন্টার মধ্যে ১০ লক্ষ রিকোয়েস্ট আসলে তা ঐ ক্যাশিং এর ডাটা থেকে পেয়ে যাবে। এতে আমাদের ডাটাবেজের খরচও কমে যাবে। আবার যদি কেউ কোনো প্রোডাক্ট অর্ডার করে তাহলে প্রথমে কার্টে অ্যাড হয়, এরপর ইনভয়েস জেনারেট হয়, তারপর ইউজারের কাছে ইনভয়েস নামক একটা মেইল যাবে, তারপর ওয়্যারহাউজে একটা নোটিফিকেশন যাবে সেটা প্রসেসিং করার জন্য। অনেকগুলো স্টেপ। এখন সব স্টেপ কমপ্লিট করে এসে যদি ইউজারকে দেখানো হয় 'Order Accepted' সেটা অনেক সময়ের ব্যাপার। সে সময়টা ইউজার কিছুই করতে পারছে না অপেক্ষা করা ছাড়া। এটাতে ইউজার এক্সপেরিয়েন্স ভাল হয় না। এক্ষেত্রে আমরা রেডিস ব্যবহার করতে পারি। একটা ইভেন্ট ক্রিয়েট করবে অর্ডার রিকোয়েস্ট আসলে। সেই ইভেন্ট কিউ (Queue) তে রেখে আমরা প্রথমে ইউজারকে ম্যাসেজ দিয়ে দিবো। এরপর আমাদের বাকি কাজ একে একে আমরা সারবো। এতে ইউজার সাথে সাথে ফিডব্যাক পেয়ে গেলো।

এই দুনিয়াতে মারামারি চলে SQL আর NoSQL এর মধ্যে। এখন উপরের প্যারাডাইমের মধ্যে কোনটা SQL আর কোনটা NoSQL তা একটু জেনে নিই। শুধুমাত্র Relational Database হলো SQL ডাটাবেজ, আর বাকি সব NoSQL.

এখন আরেকটা প্রশ্ন আসতে পারে এখানে অনেক ডাটাবেইজই তো MongoDB আসার আগে এসেছে তাহলে কেন আগে NoSQL টার্মটা শোনা যায়নি। শোনা যায়নি কারণ এই টার্মটা প্রথম MngoDB ব্যবহার করেছে। তাই আগে শোনা যায়নি।

SQL আর NoSQL এর মধ্যে কিছু ভুল ধারণা আছে। সেগুলো নিচে দেয়া হলো।

প্রথম ধারণা হলো আমরা SQL শিখে যখন NoSQL এ যাই, তখন সিক্যুয়েলের কনসেপ্টই নো সিক্যুয়েলে লাগাতে চাই। কিন্তু সেটা তো সম্ভব হয় না, কারণ দুইটার কনসেপ্ট পুরোপুরি ভিন্ন। তখন ঐ ডেভেলপারদের কাছে নো সিক্যুয়েল খারাপ হয়ে যায়।

দ্বিতীয় ধারণা হলো স্ট্যাক। প্রতিটা টেকনোলজির সাথে এক একটা স্ট্যাক ক্রিয়েট হয়ে যায়। যেমন পিএইচপির সাথে MySQL, জ্যাঙ্গোর সাথে PostgreSQL, nodejs এর সাথে MongoDB এরকম। এই কারণে আমরা ধরে নিই যে এই টেকনোলজির সাথে এই ডাটাবেজ ছাড়া অন্য কোনো ডাটাবেজ যাবে না। কিন্তু এটা সম্পূর্ণ ভুল ধারণা। যেকোনো ল্যাঙ্গুয়েজের সাথে যেকোনো ডাটাবেজ ফিট করা যায়।

এরপর আরেকটা ভুল ধারণা হলো MongoDB তে ট্রানজেকশন নিয়ে কাজ করা যায় না।

এরপর হলো MongoDB তে joining করা যায় না। এটা সত্যি কথা, কারণ যেখানে টেবিল নেই সেখানে জয়েন কিভাবে করবো। তবে এর মতো একই টেকনিক আছে। যেমন Aggregate, lookup এরকম কিছু অ্যাডভান্সড কনসেপ্ট দিয়ে আমরা টেবিল জয়েনিং এর চেয়েও বেটার কাজ করে ফেলতে পারি। আবার এমন কিছু কনসেপ্ট রয়েছে যেগুলো খুব হাই লেভেল। যেমন টাইম সিরিজ ডাটা। ধরেন আপনি একটা সিস্টেম ডিজাইন করছেন যেখানে রুগীর ব্লাড প্রেশার মনিটর হবে। প্রতি মিনিটে। তাহলে প্রতি মিনিটের ডাটা মিনিট বাই মিনিট নিতে নিতে একটা টাইম সিরিজ হয়ে গেলো। এই টাইম সিরিজ ডাটা স্টোর করা এবং কুয়েরি করে বের করে আনা অনেক কঠিন। সেই জায়গায় MongoDB অনেক সহজ একটা সার্ভিস প্রোভাইড করে।

এবার আসি আমাদের মূল আলোচনা MongoDB নিয়ে।

এর ওয়েবসাইটে গেলে আমরা দেখবো এটা এখন ডাটাবেজের চেয়েও বেশি। এর চারটা প্রোডাক্ট রয়েছে। Atlas, Enterprise Advanced, Community Edition, Realm। আমরা সাধারণত Community Edition নিয়ে কাজ করবো। এটা ফ্রি। এটা আমাদের মেশিনে ইনস্টল করে আমরা কাজ করতে পারবো। Enterprise Advanced ও Community Edition এর মতোই। তবে এখানে আমরা এক্সট্রা সাপোর্ট পাবো। কোথাও কোনো সমস্যায় পড়লে ওদেরকে পে করলে আমরা সেই সম্পর্কে সাপোর্ট পাবো। Atlas হচ্ছে মঙ্গোডিবির ম্যানেজড সার্ভিস। ম্যানেজড সার্ভিস হলো এই ডাটাবেজ হোস্ট করা, ম্যানেজ করা, ডেপ্লয় করা, প্যাচ করা, সিকিউরিটি প্রোভাইড করা এর কোনো কাজ আপনাকে করতে হবে না। আপনার কাজ হচ্ছে আপনি ডাটাবেজ ক্রিয়েট করে যেভাবে কাজ করেন সেভাবে কাজ করা। বাকি কাজ এই কোম্পানি আপনার জন্য করে দিবে। Atlas ব্যবহার করলে মঙ্গোডিবির লেটেস্ট ভার্সন আপনি পাবেন, ডাটা ম্যানেজ করার দায়িত্ব এদের, স্কেল করার দায়িত্ব এদের, সিকিউরিটি লিক হলে তা ফিক্স করার দায়িত্ব এদের, ডাটা ব্যাকআপ করার দায়িত্ব এদের, নতুন কোনো আপডেট আসলে আপডেট দিয়ে দেয়ার দায়িত্ব এদের আপনার কোনো দায়িত্ব নেই। আপনার কাজ হলো একটা ডাটাবেজ ক্রিয়েট করে তা ম্যানেজ করা। এটাকেই বলে ম্যানেজড সার্ভিস। অবশ্যই ম্যানেজড সার্ভিস নিতে গেলে আপনাকে পে করতে হবে। কম্যুনিটি এডিশনে এতক্ষণ যা যা বললাম সব আপনার নিজেকেই ম্যানেজ করতে হবে। আরেকটা প্রোডাক্ট আছে তার নাম Realm। এটা মঙ্গোডিবির সার্ভারলেস টেকনোলজি। সার্ভারলেস হচ্ছে আমাদের ভবিষ্যত। ধরেন কোনো ইউজার তার আইডি ডিলিট করতে চাইছে। এখন তার সমস্ত ডাটা ডিলিট করার পরই আমরা তার আইডি ডিলিট করতে পারবো। এখন ডিলিট একটা কমপ্লেক্স টাস্ক। ইউজার যখন ডিলিট রিকোয়েস্ট পাঠায় তখন আমাদেরকে তার পোস্ট ডিলিট করতে হবে, তার সমস্ত ছবি, ভিডিও, লাইক, কমেন্ট, শেয়ার, প্রোফাইল, ইনফরমেশন সব ডিলিট করতে হবে। এখন যদি কয়েক বছরের বিলিয়ন বিলিয়ন ডাটা জমে থাকে তাহলে সব ডিলিট করে এরপর ওকে বলতে পারবো তোমার সব ডাটা ডিলিট হয়ে গেছে। এটা করতে অনেক সময় লাগবে। ততক্ষণ পর্যন্ত কি ইউজারকে আমরা বসিয়ে রাখবো? দুইটা উপায় আছে। একটা হলো পূর্বের মতো ইভেন্ট ড্রিভেন আর্কিটেকচার। আমরা রিকোয়েস্ট কিউতে রেখে একটা ইভেন্ট তৈরি করে ম্যাসেজ দিলাম যে আমরা প্রসেস শুরু করেছি, প্রসেস শেষ হলে আমরা তোমাকে জানাবো। এরপর প্রসেস শেষে আমরা আরেকটা ইভেন্ট ক্রিয়েট করে তাকে মেইলের মাধ্যমে জানালাম প্রসেস শেষ। এটা সবচেয়ে সহজ উপায়। এছাড়া আরেকটা উপায় আছে। সেটা Realm আসার পর আমরা মঙ্গোডিবির ক্লাউড ফাংশনে গিয়ে একটা ফাংশন লিখে দিয়ে আসতে পারি যে যখন ডিলিট রিকুয়েস্ট আসবে তখনই এই ফাংশনটা ট্রিগার হবে। এবার ফাংশনের মধ্যে আমরা কোড লিখে দিলাম যে যখন ইউজার ডিলিট হবে তখন তার সম্পর্কিত সকল ডাটা ডিলিট হয়ে যাবে। এটা আসার পর আমাদের আর কিউ, ইভেন্ট, ম্যাসেজ এতকিছু ক্রিয়েট করার প্রয়োজন পড়ছে না। আমরা একটা ফাংশন লিখে দিলেই কাজ শেষ। আমাদের খরচ কমে যাবে। ফাংশন সার্ভিসের একটা সুবিধা হলো আপনি ফাংশন লিখে আসলেও সেটা চার্জ করবে না ততক্ষণ পর্যন্ত, যতক্ষণ পর্যন্ত এটা ট্রিগার হবে না। শুধু যতক্ষণ এই ফাংশন এক্সিকিউশন হবে ততক্ষণ পর্যন্তই আপনাকে এরা চার্জ করবে। তার মানে হলো এটা এক্সিকিউট হতে যদি ১০ মিলিসেকেন্ড নেয় তাহলে ১০ মিলিসেকেন্ডের চার্জ নিবে আর যদি ১০ সেকেন্ড নেয় তাহলে ১০ সেকেন্ডের চার্জ নিবে। আবার এই Realm সার্ভিসের আরেকটা সুবিধা হলো আপনি এটা ব্যবহার করে খুব সহজে GraphQL সার্ভার তৈরি করে ফেলতে পারবেন ব্যাকএন্ডে এক লাইন কোড লেখা ছাড়া। আপনি এখানে API তৈরি করতে পারেন যা আপনি যেকোনো ওয়েব বা মোবাইল অ্যাপ্লিকেশনের সাথে কানেক্ট করতে পারেন। কোনো ব্যাকএন্ড তৈরি না করে আপনার একটা ব্যাকএন্ড সার্ভিস তৈরি হয়ে যাবে অনেক ফায়ারবেসের মতো। কিন্তু ফায়ারবেসের চাইতে অনেকটা অ্যাডভান্সড। Realm FAAS (Function As A Service) এবং BAAS (Backend As A Service) সার্ভিস প্রোভাইড করে। ফায়ারবেস মূলত BAAS সার্ভিস প্রোভাইড করে তবে গুগল ক্লাউডের সাহায্য নিয়ে আমরা দুইটা সার্ভিসই পেতে পারি। বাজারে ছোটখাট ব্যাকএন্ড ডেভেলপারের এখন আর কোনো দরকার নাই। কারণ ব্যাকএন্ডের কাজগুলো এত রিপিটেটিভ যে খুব কমপ্লেক্স লেভেলের অ্যাপ্লিকেশন না হলে ঐ দুই ধরণের সার্ভিস ব্যবহার করে তা করে ফেলা যায়। এর জন্য বাজারে firebase, supabase, MongoDB Realm, Amazon Amplify, Amazon Lambda এই ধরণের প্লাটফর্ম রয়েছে।

মঙ্গোডিবিতে আপনি ডাটা নিয়ে কাজ করছেন মানে আপনাকে স্কেলিং নিয়ে ভাবতে হবে না। ইউজার যতো হবে সে সেই লেভেলের স্কেলিং করার ক্ষমতা রাখে। এটা ডিজাইনই করার হয়েছে ট্রিলিয়ন ট্রিলিয়ন ডাটা নিয়ে কাজ করার জন্য। এত পরিমাণ ডাটা থেকে খুব কম সময়ে ডাটা কুয়েরি করে নিয়ে আসতে পারে।

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

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

এখানে দেখুন নাম, ইমেইল আর পাসওয়ার্ড একই, বাকিগুলো ভিন্ন। সেক্ষেত্রে নাম, ইমেইল এবং পাসওয়ার্ডের ক্ষেত্রে ডাটা ডুপ্লিকেশন হচ্ছে। এখন আমরা করবো কি যেগুলোতে ডাটা ডুপ্লিকেশন হচ্ছে সেগুলো এতবার না লিখে একবার লিখবো।

আর যেগুলো ভিন্ন সেগুলোর জন্য আলাদা টেবিল বানাবো। এটাকেই বলা হয় ডাটা নরমালাইজেশন।

এখানে যে সমস্যাটা হয় এখন আমি যদি জানতে চাই এই ইউজার মাস্টার্স কোথা থেকে করেছেন তাহলে দুইটা টেবিলকে জয়ন করে তারপর ডাটাটা বের করে আনতে হবে। এটা একটা বিশাল সমস্যা। এই সমস্যার সমাধান করা যায় একটা সিম্পল JSON অবজেক্টের মাধ্যমে এভাবে।

{
    "ID": "12345",
    "name": "Alvi",
    "email": "alvi@gmail.com",
    "password": "1234",
    "educations": [
        {
            "1": 2,
            "2010": 2014,
            "HSC": "BSC",
            "College": "Dhaka University",
            "1__1": 1,
        },
        {
            "1": 3,
            "2010": 2016,
            "HSC": "MSC",
            "College": "BUET",
            "1__1": 1,
        },
    ],
}              I

কোনো টেবিল নাই, কলাম নাই, রো নাই। যা খুশি ডাটা রাখতে পারছি। যেভাবে খুশি রাখতে পারছি, যতো চাই ততো পারছি। এখন ধরেন কারো কোনো এডুকেশনাল ব্যাকগ্রাউন্ড নাই তার জন্য আপনি ডাটা রাখতে চাইছেন। সেটাও পারবেন। এডুকেশন না দিলেও কোনো ক্ষতি হবে না।

আজকের ক্লাসে আমরা ডাটাবেজ নিয়ে একটা বেসিক ধারনা দেয়ার চেষ্টা করলাম। ডাটাবেজ সম্পর্কে যত ধরণের ভুল ধারণা আছে সব আশা করি আপনাদের মিটে গিয়েছে। SQL, NoSQL নিয়ে মারামারির দরকার নাই। আমার অ্যাপ্লিকেশনের জন্য আমার যে ডাটাবেজ দরকার আমরা সেটাই ব্যবহার করবো। কোনোটাই খারাপ না। সবাই যার যার উদ্দেশ্য পূরণের ক্ষেত্রে সফল।