MongoDB ব্যবহার করার নতুন যারা তাদের জন্য, MongoDB স্পেস ইউজেজ 꽤 কনফিউজিং দেখাতে পারে। এই আর্টিকেলে, আমি ব্যাখ্যা করব MongoDB কীভাবে স্পেস অ্যালোকেট করে এবং কীভাবে আমাদের ObjectRocket ড্যাশবোর্ডের স্পেস ইউজেজ ইনফরমেশন ইন্টারপ্রেট করবেন যাতে আপনি জাজ করতে পারেন কখন আপনার ইনস্ট্যান্স কম্প্যাক্ট করতে হবে বা একটি শার্ড যোগ করে আপনার ইনস্ট্যান্সে উপলব্ধ স্পেস বাড়াতে হবে।
প্রথম, একটি ব্র্যান্ড নিউ মিডিয়াম ইনস্ট্যান্স দিয়ে শুরু করি যেটি একটি একক ৫GB শার্ড নিয়ে গঠিত। আমি এই ইনস্ট্যান্সকে কিছু টেস্ট ডেটা দিয়ে পপুলেট করব "ocean" নামক একটি ডেটাবেসে। টেস্ট ডেটা এবং কিছু ইনডেক্স যোগ করার পর (এই আর্টিকেলের উদ্দেশ্যে, আমি উদ্দেশ্যপूর্নে কিছু অতিরিক্ত ইনডেক্স যোগ করলাম যা আমি জানতাম টেস্ট ডেটা সেটের সাপেক্ষে বড় সাইজের হবে), এই ইনস্ট্যান্সের স্পেস ইউজেজ দেখতে এমন:
৩১৫MiB ডেটা এবং ২৫৪MiB ইনডেক্স মানে আমরা ৫ GiB শার্ডের মধ্যে ২.১ GiB ব্যবহার করছি কীভাবে? ব্যাখ্যা করার জন্য, আসুন শুরু করি MongoDB কীভাবে ডেটা ডিস্কে স্টোর করে এক্সটেন্টস-এর একটি সিরিজ হিসেবে। যেহেতু আমাদের ObjectRocket ইনস্ট্যান্সগুলো smallfiles অপশন দিয়ে চলে, প্রথম এক্সটেন্ট ১৬MB হিসেবে অ্যালোকেট হয়। এই এক্সটেন্টগুলো আকারে ডাবল হয় ৫১২MB পর্যন্ত পৌঁছানোর পর, এরপর প্রতিটি এক্সটেন্ট ৫১২MB ফাইল হিসেবে অ্যালোকেট হয়। তাই আমাদের উদাহরণ "ocean" ডেটাবেসের ফাইল স্ট্রাকচার নিচের মত:
$ ls -lh ocean/
total 1.5G
-rw------- 1 mongodb mongodb 16M Aug 20 22:30 ocean.0
-rw------- 1 mongodb mongodb 32M Aug 20 20:44 ocean.1
-rw------- 1 mongodb mongodb 64M Aug 20 22:23 ocean.2
-rw------- 1 mongodb mongodb 128M Aug 20 22:30 ocean.3
-rw------- 1 mongodb mongodb 256M Aug 20 22:30 ocean.4
-rw------- 1 mongodb mongodb 512M Aug 20 22:30 ocean.5
-rw------- 1 mongodb mongodb 512M Aug 20 22:30 ocean.6
-rw------- 1 mongodb mongodb 16M Aug 20 22:30 ocean.ns
drwxr-xr-x 2 mongodb mongodb 4.0K Aug 20 22:30 _tmp
এই এক্সটেন্টগুলো ডেটা এবং ইনডেক্স দুটোই স্টোর করে আমাদের ডেটাবেসের জন্য। MongoDB-তে, যেহেতু যেকোনো ডেটা একটি এক্সটেন্টে লেখা হয়, পরবর্তী লজিক্যাল এক্সটেন্ট অ্যালোকেট হয়ে যায়। তাই, উপরের স্ট্রাকচারের সাথে, ocean.6-এ কখনোই ডেটা নেই এই মুহূর্তে, কিন্তু ocean.5 ফুল হলে সেটার জন্য প্রি-অ্যালোকেট করা হয়েছে। যেন কোনো ডেটা ocean.6-এ লেখা হয়, একটি নতুন ৫১২MB এক্সটেন্ট, ocean.7, আবার প্রি-অ্যালোকেট হয়ে যাবে। যখন ডেটা MongoDB ডেটাবেস থেকে ডিলিট হয়, স্পেস রিলিজ হয় না যতক্ষণ না আপনি কম্প্যাক্ট করেন — তাই সময়ের সাথে সাথে, এই ডেটা ফাইলগুলো ফ্র্যাগমেন্টেড হয়ে যেতে পারে ডেটা ডিলিট হওয়ার কারণে (অথবা যদি একটি ডকুমেন্ট তার আসল স্টোরেজ লোকেশন আউটগ্রো করে কারণ অতিরিক্ত কী যোগ হয়)। একটি কম্প্যাকশন এই ডেটা ফাইলগুলোর ডিফ্র্যাগমেন্টেশন করে কারণ কম্প্যাকশন время, ডেটা রেপ্লিকেট হয় রেপ্লিকা সেটের অন্য একটি মেম্বার থেকে এবং ডেটা ফাইলগুলো স্ক্র্যাচ থেকে পুনরায় তৈরি হয়।
একটি অতিরিক্ত ১৬MB ফাইল নেমস্পেস স্টোর করে, এটি ocean.ns ফাইল। প্রতিটি ডেটাবেসের জন্য এই একই প্যাটার্ন ঘটে MongoDB ইনস্ট্যান্সে। আমাদের "ocean" ডেটাবেসের বাইরেও, দুটি অতিরিক্ত সিস্টেম ডেটাবেস রয়েছে আমাদের শার্ডে: "admin" এবং "local"। "admin" ডেটাবেস সব ডেটাবেস ইউজারের ইউজার ইনফরমেশন স্টোর করে (২.৬.এক্স-এর আগে, এই ডেটাবেস শুধু অ্যাডমিন ইউজারদের জন্য ব্যবহৃত হতো)। যদিও admin ডেটাবেস ছোট, আমাদের এখনও একটি ১৬MB এক্সটেন্ট, একটি প্রি-অ্যালোকেটেড ৩২MB এক্সটেন্ট, এবং একটি ১৬MB নেমস্পেস ফাইল রয়েছে এই ডেটাবেসের জন্য।
দ্বিতীয় সিস্টেম ডেটাবেস হলো "local" ডেটাবেস। ObjectRocket-এ আমরা যেকোনো শার্ড অফার করি সেটি একটি থ্রি-মেম্বার রেপ্লিকা সেট। এই রেপ্লিকাগুলো সিঙ্কে রাখতে, MongoDB একটি লগ মেইনটেইন করে, जिसे oplog বলা হয়, প্রতিটি আপডেটের। এটি প্রতিটি রেপ্লিকাতে সিঙ্কে রাখা হয় এবং সেকেন্ডারি রেপ্লিকাগুলোতে কোন পরিবর্তন করতে হবে সেটি ট্র্যাক করতে ব্যবহৃত হয়। এই oplog "local" ডেটাবেসের মধ্যে একটি ক্যাপড কলেকশন হিসেবে এক্সিস্ট করে। ObjectRocket-এ আমরা oplog-এর সাইজ কনফিগার করি সাধারণত শার্ড সাইজের ১০% — আমাদের ৫GB শার্ডের কেসে, oplog কনফিগার করা হয়েছে ৫০০MB হিসেবে। তাই "local" ডেটাবেস একটি ১৬MB এক্সটেন্ট, একটি ৫১২MB এক্সটেন্ট, এবং একটি ১৬MB নেমস্পেস ফাইল নিয়ে গঠিত।
চূড়ান্তে, আমাদের উদাহরণ শার্ডে একটি আরও হাউসকিপিং এলাকা রয়েছে, জার্নাল। জার্নাল ১-৩ ফাইল নিয়ে গঠিত যা প্রায় ১২৮MB প্রতিটি সাইজের। যখনই একটি রাইট হয়, MongoDB প্রথম আপডেটটি সিকোয়েনশিয়ালি জার্নালে লেখে। তারপর পিরিয়ডিক্যালি একটি ব্যাকগ্রাউন্ড থ্রেড এই আপডেটগুলোর ফ্লাশ করে আসল ডেটা ফাইলগুলোর মধ্যে (যে এক্সটেন্টগুলো আমি আগে 언급 করেছি), সাধারণত প্রতি ৬০ সেকেন্ডে একবার। এই ডবল-রাইটের কারণ হলো সিকোয়েনশিয়ালি জার্নালে লেখা প্রায়শই খুব খুব ফাস্টर তার চেয়ে সিকিং যা আসল ডেটা ফাইলগুলোর লিখতে হয়। পরিবর্তনগুলো তাত্ক্ষণিকভাবে জার্নালে লিখে, MongoDB ডেটা রিকভারি নিশ্চিত করতে পারে ক্র্যাশের ঘটনায় যেকোনো রাইটের জন্য অপেক্ষা করা ছাড়া পরিবর্তন আসল ডেটা ফাইলগুলোর লেখা হওয়া পর্যন্ত। আমাদের বর্তমান প্রাইমারি রেপ্লিকার কেসে, আমি দেখি আমাদের দুটি জার্নাল ফাইল এক্টিভ রয়েছে:
$ ls -lh journal/
total 273M
-rw------- 1 mongodb mongodb 149M Aug 20 22:26 j._1
-rw------- 1 mongodb mongodb 124M Aug 20 22:30 j._2
MongoDB এই ফাইলগুলো অটোমেটিক্যালি রোটেট করে আপডেটের ফ্রিকোয়েন্সি বনাম ব্যাকগ্রাউন্ড ফ্লাশ টু ডিস্কের ফ্রিকোয়েন্সি देखकर।
এখন যেহেতু আমি কভার করেছি MongoDB কীভাবে ডিস্ক স্পেস ব্যবহার করে, এটি ObjectRocket ড্যাশবোর্ড থেকে যা স্পেস ইউজেজ বার দেখানো হয়েছে তার সাথে কীভাবে সম্পর্কিত?
- NS ভ্যালু, ৪৮MB — তিনটি ডেটাবেসের তিনটি ১৬MB নেমস্পেস ফাইলের সমষ্টি যা আমি উল্লেখ করেছি, ocean, admin, এবং local।
- Data ভ্যালু, ৩১৫MiB — সব ডেটাবেসের জন্য (সিস্টেম ডেটাবেস সহ)
db.stats()-এ রিপোর্ট করা dataSize ভ্যালুর সমষ্টি। - Index ভ্যালু, ২৫৩.৯MiB — সব ডেটাবেসের জন্য (সিস্টেম ডেটাবেস সহ)
db.stats()-এ রিপোর্ট করা indexSize ভ্যালুর সমষ্টি। - Storage ভ্যালু, ৬৮৭.২MiB — সব ডেটাবেসের জন্য ডেটা প্লাস ইনডেক্সের সমষ্টি প্লাস ডিলিট থেকে যেকোনো unclaimed স্পেস।
- Total File ভ্যালু, ২.০ GiB — আমরা প্রাইমারি রেপ্লিকাতে টোটাল কত ডিস্ক ব্যবহার করছি। Storage ভ্যালু এবং NS ভ্যালু যা কভার করে তার বাইরে, এটিতে যেকোনো প্রি-অ্যালোকেটেড এক্সটেন্টও অন্তর্ভুক্ত কিন্তু জার্নাল দ্বারা ব্যবহৃত স্পেস নয়।
এই মেট্রিক্স দিয়ে, আমরা কিছু সিম্পল ক্যালকুলেশন করতে পারি নির্ধারণ করতে এই ইনস্ট্যান্স কি ফ্র্যাগমেন্টেড পর্যাপ্ত যাতে কম্প্যাকশন দরকার। ফ্র্যাগমেন্টেশন يسبب হারানো স্পেস ক্যালকুলেট করতে নিচের ফর্মুলা ব্যবহার করুন:
100% − (Data + Indexes) / Storage
আমাদের উদাহরণ ইনস্ট্যান্সের কেসে, এটি ১৭% আসে (100% − (315MiB Data + 253.9MiB Index) / 687.2MiB Storage = 17%)। আমি রিকমেন্ড করব আপনার ইনস্ট্যান্স কম্প্যাক্ট করার জন্য যখন ফ্র্যাগমেন্টেশন ২০%-এর কাছাকাছি পৌঁছাবে।
আরেকটি ক্যালকুলেশন আমরা করতে পারি আমাদের ওভারঅল স্পেস ইউজেজ ভিত্তিক করে শার্ড যোগ করতে হবে কিনা। আপনার ওভারঅল স্পেস ইউজেজ ক্যালকুলেট করতে নিচের ফর্মুলা করুন:
(Total File / (Plan Size * number of shards)) * 100%
আমাদের উদাহরণ ইনস্ট্যান্সের জন্য, এটি ৪০% আসে ((2 GiB / 5 GiB * 1 shard) * 100% = 40%)। আমরা সাধারণত রিকমেন্ড করি একটি শার্ড যোগ করার জন্য যখন ওভারঅল স্পেস ইউজেজ ৮০%-এর কাছাকাছি পৌঁছায়। আপনি যদি আপনার স্পেস ইউজেজ ৮০% পর্যন্ত পৌঁছাতে দেখেন, সাপোর্টের সাথে যোগাযোগ করুন এবং আমরা আপনার ইনস্ট্যান্সে একটি শার্ড যোগ করতে সাহায্য করব।
