मेरे पास बहुत अद्यतन / एक्सेस की गई तालिका है जहां मैं धारावाहिक जावा वस्तुओं को संग्रहीत करता हूं। वे 2-3 घंटे के लिए तालिका में हैं (उस अवधि के दौरान भी अपडेट किया जा रहा है) और फिर हटा दिया गया। तालिका का आकार लगभग 300 एमबी है। मैंने देखा है कि यह बहुत, बहुत बार VACUUMed है और आश्चर्य है कि क्या बदलने से fillfactorमदद मिलेगी?
जवाबों:
यहाँ प्रमुख शब्द हैं:
बिंदु 1. एक कम भरण कारक के लिए संकेत है, जबकि 2. विपरीत है। यदि एक ही डेटा पृष्ठ पर कई पंक्ति संस्करण संग्रहीत हैं, तो यह प्रदर्शन में मदद करता है। गर्म अद्यतन है कि हासिल होगा। यहाँ या यहाँ पढ़ें । उन्हें डेटा पृष्ठ पर कुछ विग्लिंग रूम की आवश्यकता होती है - जैसे कि मृत टुपल्स या एक fillfactor<100 द्वारा आरक्षित स्थान। लेकिन वे केवल अपनी बात कर सकते हैं, यदि कोई भी इंडेक्स अपडेट किए गए कॉलम में से किसी को भी शामिल नहीं करता है , जो आपके मामले के लिए सही होना चाहिए।
यहां एक अन्य महत्वपूर्ण कारक टपल आकार होगा (आपके पृष्ठ आकार की तुलना में (जो कि सामान्यतः 8 केबी है)। इस संबंधित उत्तर में अधिक जानकारी:
यदि टपल का आकार 4 kb या अधिक है, तो भरण कारक को कम करना निरर्थक होगा, क्योंकि डेटा पृष्ठ पर एक से अधिक टपल कभी नहीं हो सकता है। आप इसे वैसे भी छोड़ सकते हैं 100(जो वैसे भी डिफ़ॉल्ट है)। हालांकि, कुछ डेटा प्रकार "टोस्टेड" होते हैं और यदि वे एक आकार सीमा से अधिक हैं, तो उन्हें आउट-ऑफ-लाइन संग्रहीत किया जाता है, इसलिए मुख्य संबंध कांटा में बहुत अधिक आवश्यकता वाले ट्यूप दुर्लभ हैं।
आप जो भी VACUUM करेंगे , अक्सर चलाया जाएगा । और यह आम तौर पर एक अच्छी बात है, मैं इसके बारे में चिंता नहीं करूंगा। आप बहुत सारे मृत टुपल्स बनाते हैं। VACUUMमृत पंक्तियों की पहचान करता है जो किसी भी खुले लेनदेन के लिए दृश्यमान नहीं हैं। नियम पुस्तिका:
VACUUMटेबल और इंडेक्स में डेड रो संस्करण को हटाने का मानक रूप और भविष्य के पुन: उपयोग के लिए उपलब्ध स्थान को चिह्नित करता है ।
बोल्ड जोर मेरा।
आप इसे केवल इस तालिका के लिए कम (या अधिक) ट्रिगर करने के लिए ऑटोवैक्यूम के लिए प्रति-टेबल सेटिंग्स के साथ खेल सकते हैं :
डिफ़ॉल्ट थ्रेसहोल्ड और स्केल कारक से लिया जाता है
postgresql.conf, लेकिन उन्हें टेबल-बाय-टेबल के आधार पर ओवरराइड करना संभव है ;
बोल्ड जोर मेरा। विशेष रूप से autovacuum_vacuum_thresholdऔर केautovacuum_vacuum_scale_factor साथ । VACUUMबहुत कम चलने के बजाय वास्तव में एक बहुत अच्छा विचार हो सकता है fillfacter। यह एक्सेस पैटर्न पर निर्भर करता है। यदि सभी ट्यूपल रहते हैं, कहते हैं, 3 घंटे और प्रत्येक को कई बार अपडेट किया जाता है, तो मैं अभी भी fillfactor50 जैसी किसी चीज को कम करूंगा। आपको मीठे स्थान का परीक्षण करना होगा और ढूंढना होगा।
यह सब एक तरफ, चूंकि आपका डेटा शुरू होने से अस्थिर लगता है: UNLOGGEDतालिका का उपयोग करें :
अनलॉक्ड टेबल पर लिखा गया डेटा राइट-फॉरवर्ड लॉग ( अध्याय 29 देखें ) को नहीं लिखा गया है , जो उन्हें सामान्य टेबलों की तुलना में काफी तेज बनाता है । हालाँकि, वे क्रैश-सेफ नहीं हैं : क्रैश या अशुद्ध शटडाउन के बाद एक अनलॉगेड टेबल स्वचालित रूप से छोटा हो जाता है। अनलॉग्ड टेबल की सामग्री भी स्टैंडबाय सर्वर पर दोहराई नहीं जाती है।
बोल्ड जोर मेरा। यदि आपका सर्वर क्रैश हो सकता है और तब भी आपको डेटा की आवश्यकता होगी, तो इसका उपयोग न करें। लेकिन अगर हम वेब एप्लिकेशन के सत्र डेटा के बारे में बात कर रहे हैं, तो यह भुगतान करने के लिए स्वीकार्य मूल्य हो सकता है।
या, और भी अधिक कट्टरपंथी: यदि आप RDBMS द्वारा प्रदान की गई सुविधाओं और सुरक्षा के बिना कर सकते हैं, तो Redis जैसे कुंजी-मूल्य वाले स्टोर का उपयोग करें ।
मैं एक मुख्य-मूल्य DBMS का सुझाव देता हूं, लेकिन मैं इसे वहां ब्याज के लिए फेंक देता हूं।
INSERT और DELETE स्टेटमेंट्स करने के बजाय, केवल UPDATE करें।
टेबल की संरचना कुछ इस तरह होगी
ID integer -- sequential ID
Used boolean -- default FALSE
Object -- whatever type is appropriate
विभाजन और पंक्ति चाल से बचने के लिए ऑब्जेक्ट-होल्डिंग कॉलम निश्चित लंबाई का होगा। अपनी वस्तुओं को समायोजित करने और डिस्क पर एक पृष्ठ को कुशलता से भरने के लिए इस कॉलम को आकार दें।
अपनी तालिका को उतनी ही पंक्तियों के साथ पूर्व-भरें, जितनी आपको आवश्यकता होगी और कुछ और।
जब किसी ऑब्जेक्ट को लिखा जाना है तो उस पंक्ति का उपयोग = गलत और अद्यतन के साथ एक पंक्ति ढूंढें। जब एक वस्तु को नष्ट किया जाना है, तो इसे "गलत" करने के लिए उपयोग किया जाता है। कोई कचरा नहीं बनाया गया है और इसलिए कोई कचरा संग्रह नहीं है।
बेशक, कई, कई अपवाद स्थितियां हैं (पंक्ति अतिप्रवाह, तालिका अतिप्रवाह, आईडी उपयोग पर दौड़ की स्थिति आदि) को संभालने के लिए, लेकिन कोई भी असंभव नहीं है।