আমার প্রশ্নের 2 অংশ আছে।
- PostgreSQL এ কোনও ডাটাবেসের প্রাথমিক আকার নির্দিষ্ট করার কোনও উপায় আছে কি?
- যদি তা না থাকে, সময়ের সাথে সাথে ডাটাবেস বাড়লে আপনি কীভাবে খণ্ডন করবেন?
আমি সম্প্রতি এমএসএসকিউএল থেকে পোস্টগ্র্রেসে স্থানান্তরিত করেছি এবং ডাটাবেস তৈরি করার সময় এমএসএসকিউএল জগতে আমরা যে কাজ করেছি তার মধ্যে একটি হল ডাটাবেস এবং লেনদেন লগের প্রাথমিক আকার নির্দিষ্ট করা। এটি খণ্ডিতকরণ এবং বর্ধমান কার্যকারিতা হ্রাস করেছে, বিশেষত যদি ডাটাবেসের "স্বাভাবিক" আকারটি আগেই জানা থাকে।
আকার বাড়ার সাথে সাথে আমার ডাটাবেসের কর্মক্ষমতা হ্রাস পাবে। উদাহরণস্বরূপ, যে কাজের চাপটি আমি এটিকে দিচ্ছি তাতে 10 মিনিট সময় লাগে। ডাটাবেস বাড়ার সাথে সাথে এই সময়টি বাড়তে থাকে। একটি ভ্যাকুয়াম করা, ভ্যাকুয়াম ফুল এবং ভ্যাকুয়াম ফুল অ্যানালাইজ সমস্যাটি সমাধান করার জন্য উপস্থিত হয় না। পারফরম্যান্স সমস্যাটি কী সমাধান করে তা ডাটাবেস বন্ধ করা, ড্রাইভটিকে বিভাজন করে দেওয়া এবং তারপরে একটি ভ্যাকুয়াম ফুল অ্যানালাইজ করা আমার পরীক্ষার পারফরম্যান্সটি মূল 10 মিনিটে ফিরে আসে। এটি আমাকে সন্দেহ করতে পরিচালিত করে যে টুকরো টুকরো করা যা আমার ব্যথার কারণ।
আমি পোস্টগ্রিসে টেবিলস্পেস / ডাটাবেস স্পেস সংরক্ষণের কোনও রেফারেন্স খুঁজে পাইনি। হয় আমি ভুল পরিভাষা ব্যবহার করছি এবং এভাবে কিছুই খুঁজে পাচ্ছি না, বা পোস্টগ্র্রেসে ফাইল সিস্টেমের খণ্ডন প্রশমিত করার আলাদা উপায় আছে।
কোন পয়েন্টার?
সমাধান
সরবরাহ করা উত্তরগুলি আমাকে সন্দেহ করতে শুরু করেছে তা নিশ্চিত করতে সহায়তা করেছে। পোস্টগ্রাইএসকিউএল একাধিক ফাইল জুড়ে ডাটাবেস সংরক্ষণ করে এবং এটিই টুকরা টুকরো টুকরো করে চিন্তার ছাড়াই ডাটাবেসটিকে বাড়তে দেয়। ডিফল্ট আচরণ হ'ল এই ফাইলগুলিকে টেবিলের ডেটা দিয়ে কাটাতে প্যাক করা, যা টেবিলগুলির পক্ষে ভাল যা খুব কমই পরিবর্তিত হয় তবে প্রায়শই আপডেট হওয়া টেবিলগুলির জন্য এটি খারাপ।
পোস্টগ্রাইএসকিউএল এমবিসিসি ব্যবহার করে টেবিলের ডেটাগুলিতে সমবর্তী অ্যাক্সেস সরবরাহ করে। এই স্কিমের অধীনে প্রতিটি আপডেট সারির একটি নতুন সংস্করণ তৈরি করে যা আপডেট হয়েছিল (এটি টাইম স্ট্যাম্প বা সংস্করণ নম্বর দিয়ে হতে পারে, কে জানে?)। পুরানো ডেটা তাত্ক্ষণিকভাবে মোছা হয়নি, তবে মুছে ফেলার জন্য চিহ্নিত করা হয়েছে। যখন ভ্যাকুয়াম অপারেশন করা হয় তখন প্রকৃত মুছে ফেলা হয়।
এটি কীভাবে ফিল ফ্যাক্টরের সাথে সম্পর্কিত? 100 এর টেবিল ডিফল্ট ফিল ফ্যাক্টরটি টেবিল পৃষ্ঠাগুলি সম্পূর্ণরূপে প্যাক করে, যার ফলশ্রুতিতে আপডেট করা সারিগুলি রাখার জন্য টেবিল পৃষ্ঠার মধ্যে কোনও স্থান নেই, অর্থাৎ আপডেট হওয়া সারিগুলি মূল সারি থেকে আলাদা টেবিল পৃষ্ঠায় স্থাপন করা হবে। এটি পারফরম্যান্সের জন্য খারাপ, যেমন আমার অভিজ্ঞতা দেখায়। আমার সংক্ষিপ্ত টেবিলগুলি খুব ঘন ঘন আপডেট হওয়ার সাথে সাথে (1500 সারি / সেকেন্ড পর্যন্ত), আমি 20 এর ফিল ফ্যাক্টর সেট করতে পছন্দ করেছি, সারণির 20% সন্নিবেশ করা সারি ডেটার জন্য এবং 80% আপডেট ডেটার জন্য থাকবে for এটি অতিরিক্ত মাত্রায় মনে হতে পারে, আপডেট হওয়া সারিগুলির জন্য প্রচুর পরিমাণে স্থান সংরক্ষিত থাকার অর্থ হল যে আপডেট হওয়া সারিগুলি মূল পৃষ্ঠার একই পৃষ্ঠায় থাকে এবং অটোভ্যাকুয়াম ডিমন অপ্রচলিত সারিগুলি সরাতে চালানোর সময় কোনও টেবিল পৃষ্ঠা পূর্ণ হয় না।
আমার ডাটাবেসটিকে "ঠিক" করতে, আমি নিম্নলিখিতগুলি করেছি।
- আমার সংক্ষিপ্ত টেবিলগুলির ফিল ফ্যাক্টরটি 20 এ সেট করুন T আপনি তৈরির সময় টেবিল তৈরির জন্য প্যারামিটারটি পাস করার মাধ্যমে, বা অল্টার টেবিলের মাধ্যমে সত্যের পরে এটি করতে পারেন। আমি নিম্নলিখিত plpgsql কমান্ড জারি করেছি:
ALTER TABLE "my_summary_table" SET (fillfactor = 20); - এটি একটি ভ্যাকুয়াম পূর্ণ ইস্যু করেছে, কারণ এটি টেবিল ফাইলটির সম্পূর্ণ নতুন সংস্করণ লিখেছে এবং এভাবে জড়িত হয়ে নতুন ফিল ফ্যাক্টরের সাথে একটি নতুন টেবিল ফাইলটি লিখে ।
আমার পরীক্ষাগুলি পুনরুদ্ধার করে, যখন অনেক মিলিয়ন সারি থাকা আমার প্রয়োজন তত পরিমাণে ডাটাবেস বৃহত্তর হলেও আমি কোনও কার্যকারিতা হ্রাস পাচ্ছি না।
টিএল; ডিআর - ফাইল বিভাজন কারণ ছিল না, এটি ছিল টেবিল স্পেস বিভাজন। আপনার নির্দিষ্ট ব্যবহারের ক্ষেত্রে উপযুক্ত হওয়ার জন্য এটি টেবিলের ফিল ফ্যাক্টরটি টুইট করে প্রশমিত করা হয়।