আপনারা যারা মঙ্গোডিবি ব্যবহার করতে নতুন তাদের জন্য, মঙ্গোডিবি স্পেস ব্যবহার বেশ বিভ্রান্তিকর বলে মনে হতে পারে। এই প্রবন্ধে, আমি ব্যাখ্যা করব কীভাবে MongoDB স্থান বরাদ্দ করে এবং কীভাবে আমাদের অবজেক্ট রকেট ড্যাশবোর্ডে স্থান ব্যবহারের তথ্য ব্যাখ্যা করতে হয় সে সম্পর্কে সিদ্ধান্ত নেওয়ার জন্য আপনাকে কখন আপনার ইনস্ট্যান্স কমপ্যাক্ট করতে হবে বা আপনার উদাহরণে উপলব্ধ স্থান বাড়াতে একটি শার্ড যোগ করতে হবে।
প্রথমে, একটি একক 5GB শার্ড সমন্বিত একটি একেবারে নতুন মাঝারি উদাহরণ দিয়ে শুরু করা যাক। আমি "সমুদ্র" নামের একটি ডাটাবেসে কিছু পরীক্ষার ডেটা দিয়ে এই উদাহরণটি পূরণ করতে যাচ্ছি। কিছু পরীক্ষার ডেটা যোগ করার পরে এবং কয়েকটি সূচী তৈরি করার পরে এই উদাহরণের জন্য স্থানের ব্যবহার কেমন দেখায় তা এখানে রয়েছে (এই নিবন্ধটির উদ্দেশ্যে, আমি ইচ্ছাকৃতভাবে অতিরিক্ত সূচক যুক্ত করেছি যা আমি জানতাম পরীক্ষার ডেটা সেটের তুলনায় আকারে মোটামুটি বড় হবে):
কীভাবে 315MiB ডেটা এবং 254MiB সূচকের মানে আমরা আমাদের 5 GiB শার্ডের মধ্যে 2.1 GiB ব্যবহার করছি? ব্যাখ্যা করার জন্য, চলুন শুরু করা যাক কিভাবে MongoDB ডিস্কে ডেটা সঞ্চয় করে বিস্তৃতির একটি সিরিজ হিসাবে। যেহেতু আমাদের অবজেক্ট রকেট দৃষ্টান্তগুলি ছোট ফাইল বিকল্পের সাথে চালিত হয়, প্রথম সীমাটি 16MB হিসাবে বরাদ্দ করা হয়। এই সীমাগুলি 512MB না পৌঁছানো পর্যন্ত আকারে দ্বিগুণ হয়, তারপরে প্রতিটি সীমা একটি 512MB ফাইল হিসাবে বরাদ্দ করা হয়। সুতরাং আমাদের উদাহরণ "সমুদ্র" ডাটাবেসের একটি ফাইল গঠন নিম্নরূপ:
$ 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-তে লেখা হয়, একটি নতুন 512MB পরিমাণ, ocean.7, আবার পূর্ব-বরাদ্দ করা হবে। যখন একটি MongoDB ডাটাবেস থেকে ডেটা মুছে ফেলা হয়, তখন আপনি কম্প্যাক্ট না হওয়া পর্যন্ত স্থানটি ছেড়ে দেওয়া হয় না — তাই সময়ের সাথে সাথে, এই ডেটা ফাইলগুলি ডেটা মুছে ফেলার সাথে সাথে খণ্ডিত হয়ে যেতে পারে (অথবা যদি একটি নথি তার মূল স্টোরেজ অবস্থানকে ছাড়িয়ে যায় কারণ অতিরিক্ত কী যোগ করা হয়)। একটি কমপ্যাকশন এই ডেটা ফাইলগুলিকে ডিফ্র্যাগমেন্ট করে কারণ একটি কম্প্যাকশনের সময়, প্রতিলিপি সেটের অন্য সদস্যের কাছ থেকে ডেটা প্রতিলিপি করা হয় এবং ডেটা ফাইলগুলি স্ক্র্যাচ থেকে পুনরায় তৈরি করা হয়।
একটি অতিরিক্ত 16MB ফাইল নামস্থান সংরক্ষণ করে, এটি হল ocean.ns ফাইল। এই একই প্যাটার্ন একটি MongoDB উদাহরণে প্রতিটি ডাটাবেসের জন্য ঘটে। আমাদের "সমুদ্র" ডাটাবেস ছাড়াও, আমাদের শার্ডে দুটি অতিরিক্ত সিস্টেম ডেটাবেস রয়েছে:"অ্যাডমিন" এবং "স্থানীয়"। "অ্যাডমিন" ডাটাবেস সমস্ত ডাটাবেস ব্যবহারকারীদের জন্য ব্যবহারকারীর তথ্য সঞ্চয় করে (2.6.x এর আগে, এই ডাটাবেসটি শুধুমাত্র অ্যাডমিন ব্যবহারকারীদের জন্য ব্যবহার করা হত)। যদিও অ্যাডমিন ডাটাবেসটি ছোট, তবুও আমাদের কাছে এই ডাটাবেসের জন্য একটি 16MB সীমা, একটি পূর্ব-বরাদ্দ 32MB সীমা এবং একটি 16MB নামস্থান ফাইল রয়েছে৷
দ্বিতীয় সিস্টেম ডাটাবেস হল "স্থানীয়" ডাটাবেস। আমরা অবজেক্ট রকেট এ অফার করি প্রতিটি শার্ড একটি তিন-সদস্যের রেপ্লিকা সেট। এই প্রতিলিপিগুলিকে সিঙ্কে রাখার জন্য, MongoDB প্রতিটি আপডেটের একটি লগ বজায় রাখে, যাকে অপলগ বলা হয়। এটি প্রতিটি প্রতিলিপিতে সিঙ্কে রাখা হয় এবং গৌণ প্রতিলিপিগুলিতে করা প্রয়োজন এমন পরিবর্তনগুলি ট্র্যাক করতে ব্যবহৃত হয়। এই অপলগ "স্থানীয়" ডাটাবেসের মধ্যে একটি ক্যাপড সংগ্রহ হিসাবে বিদ্যমান। অবজেক্ট রকেট-এ আমরা অপলগের আকার সাধারণত শার্ড আকারের 10% হতে কনফিগার করি — আমাদের 5GB শার্ডের ক্ষেত্রে, অপলগটি 500MB হিসাবে কনফিগার করা হয়। এইভাবে "স্থানীয়" ডাটাবেস একটি 16MB ব্যাপ্তি, একটি 512MB ব্যাপ্তি এবং একটি 16MB নামস্থান ফাইল নিয়ে গঠিত৷
অবশেষে, আমাদের উদাহরণ শার্ডে আরও একটি হাউসকিপিং এরিয়া রয়েছে, জার্নাল। জার্নাল হল 1-3টি ফাইলের একটি সেট যার প্রতিটির আকার প্রায় 128MB। যখনই একটি লেখা হয়, MongoDB প্রথমে জার্নালে ধারাবাহিকভাবে আপডেটটি লেখে। তারপরে পর্যায়ক্রমে একটি ব্যাকগ্রাউন্ড থ্রেড এই আপডেটগুলিকে প্রকৃত ডেটা ফাইলগুলিতে ফ্লাশ করে (যা আমি আগে উল্লেখ করেছি), সাধারণত প্রতি 60 সেকেন্ডে একবার। এই ডাবল-রাইটের কারণ হল জার্নালে ক্রমানুসারে লেখা প্রায়ই অনেক বেশি, প্রকৃত ডেটা ফাইলগুলিতে লেখার জন্য প্রয়োজনীয় চাওয়ার চেয়ে অনেক দ্রুত। জার্নালে পরিবর্তনগুলি অবিলম্বে লেখার মাধ্যমে, 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 এই ফাইলগুলিকে স্বয়ংক্রিয়ভাবে ঘোরায়।
তাই এখন যেহেতু আমি মোঙ্গোডিবি কীভাবে ডিস্ক স্পেস ব্যবহার করে তা কভার করেছি, আমি আগে দেখিয়েছি এমন অবজেক্ট রকেট ড্যাশবোর্ডের স্পেস ব্যবহার বারে যা দেখানো হয়েছে তার সাথে এটি কীভাবে মিলে যায়?
- NS মান, 48MB — আমি উল্লিখিত তিনটি ডাটাবেসের জন্য তিনটি 16MB নেমস্পেস ফাইলের সমষ্টি, মহাসাগর, প্রশাসক এবং স্থানীয়৷
- ডেটা মান, 315MiB —
db.stats()-এ ডেটা সাইজের জন্য রিপোর্ট করা মানের সমষ্টি সমস্ত ডাটাবেসের জন্য (সিস্টেম ডাটাবেস সহ)। - সূচক মান, 253.9MiB, —
db.stats()-এ indexSize-এর জন্য রিপোর্ট করা মানের সমষ্টি সমস্ত ডাটাবেসের জন্য (সিস্টেম ডাটাবেস সহ)। - স্টোরেজ মান, 687.2MiB — সমস্ত ডাটাবেসের জন্য ডেটা প্লাস ইনডেক্সের যোগফল এবং মুছে ফেলা থেকে যে কোনও দাবি না করা স্থান।
- মোট ফাইলের মান, 2.0 GiB — আমরা প্রাথমিক রেপ্লিকাতে মোট কতটা ডিস্ক ব্যবহার করছি। স্টোরেজ মান এবং এনএস মান দ্বারা আচ্ছাদিত স্থানের বাইরে, এর মধ্যে যেকোনও আগে থেকে বরাদ্দকৃত পরিধি অন্তর্ভুক্ত থাকে তবে জার্নাল দ্বারা ব্যবহৃত স্থান নয়
এই মেট্রিক্সের পরিপ্রেক্ষিতে, এই দৃষ্টান্তটি একটি কম্প্যাকশনের প্রয়োজনের জন্য যথেষ্ট খণ্ডিত কিনা তা নির্ধারণ করতে আমরা কিছু সাধারণ গণনা করতে পারি। খণ্ডিতকরণের কারণে যে স্থানটি হারিয়ে যেতে পারে তা গণনা করতে, নিম্নলিখিতটি ব্যবহার করুন:
100% – (ডেটা + ইনডেক্স) / স্টোরেজ
আমাদের উদাহরণের ক্ষেত্রে, এটি 17% (100% - (315MiB ডেটা + 253.9MiB সূচক) / 687.2MiB স্টোরেজ =17%) পর্যন্ত কাজ করে। যখন ফ্র্যাগমেন্টেশন 20% এর কাছাকাছি পৌঁছে তখন আমি আপনার উদাহরণ কমপ্যাক্ট করার সুপারিশ করব।
আরেকটি গণনা যা আমরা করতে পারি তা হল আমাদের সামগ্রিক স্থান ব্যবহারের উপর ভিত্তি করে এই উদাহরণে একটি শার্ড যোগ করতে হবে কিনা। আপনার সামগ্রিক স্থান ব্যবহার গণনা করতে নিম্নলিখিতগুলি করুন:
(মোট ফাইল / (প্ল্যান সাইজ * শার্ডের সংখ্যা)) * 100%
আমাদের উদাহরণের জন্য, এটি 40% পর্যন্ত কাজ করে (2 GiB / 5 GiB * 1 শার্ড) * 100% =40%)। যখন সামগ্রিক স্থান ব্যবহার 80% এর কাছাকাছি হয় তখন আমরা সাধারণত একটি শার্ড যোগ করার পরামর্শ দিই। যদি আপনি লক্ষ্য করেন যে আপনার স্থান ব্যবহার 80% এ পৌঁছেছে, তাহলে সহায়তার সাথে যোগাযোগ করুন এবং আমরা আপনাকে আপনার উদাহরণে একটি শার্ড যোগ করতে সহায়তা করতে পারি।
