আমি টেবিলে ভারী আপডেট / অ্যাক্সেস করেছি যেখানে আমি সিরিয়ালযুক্ত জাভা অবজেক্টগুলি সঞ্চয় করি। তারা ২-৩ ঘন্টা টেবিলে থাকে (সেই সময়ের মধ্যেও আপডেট করা হয়) এবং তারপরে সরানো হয়। টেবিলের আকার 300MB এর কাছাকাছি। আমি এটি খুব খুব প্রায়ই ভ্যাকুয়ামযুক্ত স্পট করেছি এবং ভাবছি যে পরিবর্তনটি fillfactorসাহায্য করবে কিনা ?
উত্তর:
এখানে মূল শব্দগুলি হ'ল:
পয়েন্ট ১ হ'ল কম ফিল ফ্যাক্টরের জন্য ইঙ্গিত, যখন ২ বিপরীত। যদি একাধিক সারির সংস্করণ একই ডেটা পৃষ্ঠায় সঞ্চয় করা থাকে তবে এটি কার্য সম্পাদনে সহায়তা করে। হট আপডেটগুলি তা অর্জন করবে। এখানে বা এখানে পড়ুন । তারা তথ্য পৃষ্ঠাতে কিছু আন্দোলিত রুম প্রয়োজন - মৃত tuples বা স্থান একটি দ্বারা সংরক্ষিত মত fillfactor<100 কিন্তু তারা শুধুমাত্র তাদের জিনিস করতে পারেন কোন সূচক আপডেট কলামের কোনো জড়িত , যা আপনার ক্ষেত্রে জন্য সত্য হতে হবে।
এখানে আর একটি গুরুত্বপূর্ণ বিষয় হ'ল টিউপল আকার (আপনার পৃষ্ঠার আকারের তুলনায় (যা সর্বাধিক 8 কেবি)। এই সম্পর্কিত উত্তরের আরও বিশদ:
যদি টিউপলের আকার 4 কেবি বা তার বেশি হয় তবে ফিল ফ্যাক্টর হ্রাস করা নিরর্থক হবে, যেহেতু কোনও ডেটা পৃষ্ঠায় একাধিক টিপল কখনও থাকতে পারে না। আপনি এটিকে এটিকে ছেড়ে যেতে পারেন 100(যা যাইহোক ডিফল্ট)। যাইহোক, কিছু ডেটা প্রকারগুলি "টোস্টেড" এবং লাইনটি আউট-লাইন সঞ্চিত হয় যদি তারা আকারের সীমা অতিক্রম করে, তাই মূল সম্পর্কের কাঁটাচামচায় যে পরিমাণ টিপলের প্রয়োজন হয় তা বিরল।
আপনি যা করেন না কেন, প্রায়শই চালানো VACUUM হবে । এবং এটি সাধারণত একটি ভাল জিনিস, আমি এটি সম্পর্কে চিন্তা করব না। আপনি প্রচুর মরা টিপলস তৈরি করেন। VACUUMমৃত সারিগুলি সনাক্ত করে যা কোনও খোলা লেনদেনের জন্য আর দৃশ্যমান নয়। ম্যানুয়াল:
মানক ফর্মটি
VACUUMসারণী এবং সূচিগুলিতে মৃত সারি সংস্করণগুলি সরিয়ে দেয় এবং ভবিষ্যতের পুনরায় ব্যবহারের জন্য উপলব্ধ স্থান চিহ্নিত করে ।
বোল্ড জোর আমার।
আপনি সঙ্গে খেলা করতে পারেন প্রতি টেবিল সেটিংস autovacuum জন্য প্রায়ই শুধুমাত্র এই টেবিলের জন্য এটি কম (বা তার বেশি) ট্রিগার:
ডিফল্ট থ্রেশহোল্ড এবং স্কেল ফ্যাক্টরগুলি নেওয়া হয়
postgresql.conf, তবে তাদের টেবিল-টেবিলের ভিত্তিতে ওভাররাইড করা সম্ভব ;
বোল্ড জোর আমার। বিশেষত সাথে autovacuum_vacuum_thresholdএবংautovacuum_vacuum_scale_factor । VACUUMঅনেক কম চালানো আসলে খুব কম হওয়ার পরিবর্তে একটি ভাল ধারণা হতে পারে fillfacter। এটি অ্যাক্সেস নিদর্শনগুলির উপর নির্ভর করে। যদি সমস্ত টিপল লাইভ থাকে, বলুন, 3 ঘন্টা এবং প্রতিটি বেশ কয়েকবার আপডেট হয় তবে আমি এখনও fillfactor50 এর মতো কিছুতে কমিয়ে দেব You আপনাকে পরীক্ষা করতে হবে এবং মিষ্টি স্পটটি খুঁজে পেতে হবে।
আপনার ডেটা যেহেতু শুরু হতে পারে তা অস্থির বলে মনে হচ্ছে: একটি UNLOGGEDটেবিল ব্যবহার করুন :
আনলগযুক্ত টেবিলগুলিতে লিখিত ডেটা রাইটিং-ফরোয়ার্ড লগে ( অধ্যায় 29 দেখুন ) লিখিত হয় না , যা এগুলি সাধারণ টেবিলের তুলনায় যথেষ্ট দ্রুত করে তোলে । তবে এগুলি ক্র্যাশ-নিরাপদ নয় : একটি আনলগড টেবিল ক্র্যাশ বা অশুচি শাটডাউন করার পরে স্বয়ংক্রিয়ভাবে কেটে যাবে। আনলগ করা টেবিলের সামগ্রীগুলি স্ট্যান্ডবাই সার্ভারগুলিতেও প্রতিলিপি করা হয় না।
বোল্ড জোর আমার। আপনার সার্ভার ক্রাশ হয়ে যেতে পারে এবং এর পরেও আপনার ডেটা দরকার থাকলে এটি ব্যবহার করবেন না। তবে আমরা যদি ওয়েব অ্যাপ্লিকেশনগুলির জন্য সেশন ডেটা সম্পর্কে কথা বলি তবে এটি প্রদানের জন্য একটি গ্রহণযোগ্য মূল্য হতে পারে।
বা আরও বেশি মূলগত: আপনি যদি কোনও আরডিবিএমএস সরবরাহ করে সমস্ত বৈশিষ্ট্য এবং সুরক্ষা ব্যতীত না করতে পারেন তবে রেডিসের মতো কী-মান স্টোর ব্যবহার করুন ।
আমি কী-মূল্যের ডিবিএমএসের পরামর্শ দেব, তবে আমি এটি আগ্রহের জন্য সেখানে ফেলে দিচ্ছি।
INSERT & মুছে ফেলা বিবরণীর পরিবর্তে কেবল আপডেট করুন DATE
টেবিল কাঠামো কিছু হবে
ID integer -- sequential ID
Used boolean -- default FALSE
Object -- whatever type is appropriate
বিভাজন এবং সারি চালগুলি এড়াতে অবজেক্ট-হোল্ডিং কলামটি নির্দিষ্ট দৈর্ঘ্যের হবে। আপনার অবজেক্টগুলিকে সামঞ্জস্য করতে এবং ডিস্কে কোনও পৃষ্ঠা কার্যকরভাবে পূরণ করার জন্য এই কলামটি আকার করুন।
আপনার টেবিলটি যতগুলি সারি প্রয়োজন হবে এবং আরও কয়েকটি দিয়ে পূর্বে পূরণ করুন।
যখন কোনও বস্তুটি লিখতে হবে তখন ব্যবহৃত = মিথ্যা এবং সেই সারিটি আপডেট করুন a যখন কোনও বস্তুটি বিনষ্ট হতে হয়, সেটাকে "মিথ্যা" হিসাবে সেট করুন। এখানে কোনও আবর্জনা তৈরি করা হয়নি এবং তাই কোনও আবর্জনা সংগ্রহ করা হয়নি।
অবশ্যই পরিচালনা করার জন্য অনেকগুলি, অনেকগুলি ব্যতিক্রম শর্ত রয়েছে (সারি ওভারফ্লো, টেবিলের ওভারফ্লো, আইডি ব্যবহারের ক্ষেত্রে রেস শর্ত ইত্যাদি) তবে কোনওটিই দুর্লভ নয়।