कई अद्यतनों और PostgreSQL

Question

के साथ स्ट्रीम करें मैं PostgreSQL अनुकूलन के साथ काफी नौसिखिया हूं और इसके लिए जो कुछ भी उचित काम कर रहा हूं और जो कुछ भी नहीं है। इसलिए, मैं जानना चाहता हूं कि जब भी मैं अनुचित नौकरी के लिए PostgreSQL का उपयोग करने की कोशिश कर रहा हूं, या यह इसके लिए उपयुक्त है और मुझे सब कुछ ठीक से सेट करना चाहिए।

वैसे भी, मुझे बहुत सारे डेटा वाले डेटाबेस की आवश्यकता है जो अक्सर बदलती है।

उदाहरण के लिए, एक आईएसपी की कल्पना करें, जिसमें बहुत से ग्राहक हैं, प्रत्येक में एक सत्र (पीपीपी/वीपीएन/जो भी हो) है, दो स्व-वर्णन करने वाले अक्सर अद्यतन गुण bytes_received और bytes_sent के साथ। जहां प्रत्येक सत्र अद्वितीय ID के साथ एक पंक्ति का प्रतिनिधित्व करती है उन लोगों के साथ एक मेज, नहीं है:

CREATE TABLE sessions(
    id BIGSERIAL NOT NULL, 
    username CHARACTER VARYING(32) NOT NULL, 
    some_connection_data BYTEA NOT NULL, 
    bytes_received BIGINT NOT NULL, 
    bytes_sent BIGINT NOT NULL, 
    CONSTRAINT sessions_pkey PRIMARY KEY (id) 
) 

और के रूप में लेखांकन डेटा बहती है, इस तालिका उन जैसे बहुत-से अपडेट प्राप्त करता है:

-- There are *lots* of such queries! 
UPDATE sessions SET bytes_received = bytes_received + 53554, 
        bytes_sent = bytes_sent + 30676 
       WHERE id = 42 

जब हमें कई बार (जैसे हजारों) सत्रों के साथ बहुत सारे टेबल (जैसे 1-2 हजार सेकेंड) के अपडेट के साथ कभी खत्म नहीं होता है, शायद एमवीसीसी के लिए धन्यवाद, इससे पोस्टग्रेएसक्यूएल बहुत व्यस्त हो जाता है। क्या सब कुछ तेज करने के लिए कोई तरीका हैं, या पोस्टग्रेस इस कार्य के लिए बिल्कुल उपयुक्त नहीं है और मैं बेहतर ढंग से इस कार्य के लिए अनुपयुक्त मानता हूं और उन काउंटरों को मेमकैचब जैसे अन्य स्टोरेज में डालता हूं, केवल पोस्टग्रेज़ का उपयोग केवल स्थिर डेटा के लिए करता हूं? लेकिन मुझे इस डेटा पर बार-बार पूछताछ करने की क्षमता याद आती है, उदाहरण के लिए TOP10 डाउनलोडर्स ढूंढने के लिए, जो वास्तव में अच्छा नहीं है।

दुर्भाग्यवश, डेटा की मात्रा अधिक कम नहीं हो सकती है। आईएसपी लेखांकन उदाहरण सभी स्पष्टीकरण को सरल बनाने के लिए सोचा जाता है। असली समस्या किसी अन्य प्रणाली के साथ है, जो संरचना को समझाने के लिए कठिन है।

सुझावों के लिए धन्यवाद!

Answer 1

डेटाबेस बहुत सारे छोटे अपडेट एकत्र करने के लिए वास्तव में सबसे अच्छा टूल नहीं है, लेकिन जैसा कि मुझे आपकी पूछताछ और एसीआईडी ​​आवश्यकताएं नहीं हैं, मैं वास्तव में कुछ और अनुशंसा नहीं कर सकता। यदि यह स्वीकार्य दृष्टिकोण है तो zzzeek द्वारा सुझाए गए एप्लिकेशन साइड अपडेट एकत्रीकरण में अद्यतन लोड को कम करने में मदद मिल सकती है।

एक समान दृष्टिकोण है जो आपको कुछ प्रदर्शन लागत पर ताजा डेटा पूछने की स्थायित्व और क्षमता प्रदान कर सकता है। एक बफर तालिका बनाएं जो उन मानों में परिवर्तन एकत्र कर सकती है जिन्हें अद्यतन करने की आवश्यकता है और वहां परिवर्तन डालें। लेन-देन में नियमित अंतराल पर तालिका को किसी अन्य चीज़ का नाम दें और इसके स्थान पर एक नई तालिका बनाएं।फिर एक लेनदेन में सभी परिवर्तनों को कुल करें, मुख्य तालिका के अनुरूप अद्यतन करें और बफर तालिका को छोटा करें। इस तरह यदि आपको किसी भी डेटा के एक सतत और ताजा स्नैपशॉट की आवश्यकता है तो आप मुख्य तालिका से चयन कर सकते हैं और सक्रिय और नामित बफर टेबल से सभी परिवर्तनों में शामिल हो सकते हैं।

हालांकि यदि न तो स्वीकार्य है तो आप भारी अद्यतन भार के साथ बेहतर सौदा करने के लिए डेटाबेस को भी ट्यून कर सकते हैं।

अद्यतन को अनुकूलित करने के लिए सुनिश्चित करें कि PostgreSQL पंक्तियों के अद्यतन संस्करणों को संग्रहीत करने के लिए heap-only tuples का उपयोग कर सकता है। ऐसा करने के लिए सुनिश्चित करें कि अक्सर अपडेट किए गए कॉलम पर कोई अनुक्रमणिका नहीं है और fillfactor को डिफ़ॉल्ट 100% से कम कुछ में बदलें। आपको अपने आप पर एक उपयुक्त भरने का कारक समझने की आवश्यकता होगी क्योंकि यह वर्कलोड के विवरण और जिस मशीन पर चल रहा है, उसके विवरण पर भारी निर्भर करता है। Fillfactor को इतना कम होना चाहिए कि ऑटोवैक्यूम के पुराने गैर-दृश्यमान संस्करणों को साफ करने का मौका मिलने से पहले सभी अद्यतन उसी डेटाबेस पृष्ठ पर फिट हो जाएं। आप डाटाबेस और वैक्यूम ओवरहेड के घनत्व के बीच व्यापार करने के लिए ऑटोवैक्यूम सेटिंग्स को ट्यून कर सकते हैं। साथ ही, ध्यान दें कि सांख्यिकीय प्रश्नों सहित किसी भी लंबे लेनदेन, लेनदेन शुरू होने के बाद बदल गए tuples पर पकड़ लेंगे। , ट्यून करने के लिए क्या देखने के लिए pg_stat_user_tables देखें दृश्यn_tup_upd n_dead_tup को और n_live_tup को n_tup_hot_upd की विशेष रूप से संबंध।

भारी अद्यतन भी एक भारी लिखने के बाद लॉग (वाल) लोड बना देगा। डब्ल्यूएएल व्यवहार को ट्यून करना (docs for the settings) इससे कम मदद करेगा। विशेष रूप से, उच्च चेकपॉइंट_ सेगमेंट नंबर और उच्च चेकपॉइंट_टाउटआउट आपके आईओ लोड को स्मृति में होने वाले अधिक अपडेट की अनुमति देकर महत्वपूर्ण रूप से कम कर सकता है। यह देखने के लिए कि कितने चेकपॉइंट होते हैं क्योंकि चेक सीमाएं होती हैं क्योंकि चेकपॉइंट्स_टिमड बनाम चेकपॉइंट_रेक में pg_stat_bgwriter में संबंध हैं। अपने साझा_बफर को बढ़ाएं ताकि कामकाजी सेट मेमोरी में फिट हो सके। Buffers_checkpoint बनाम buffers_clean + buffers_backend देखें कि चेकपॉइंट आवश्यकताओं को पूरा करने के लिए कितने लिखा गया था बनाम बस स्मृति से बाहर चल रहा है।

Answer 2

आप सांख्यिकीय अद्यतनों को इकट्ठा करना चाहते हैं क्योंकि वे किसी प्रकार की मेमोरी कतार में होते हैं, या वैकल्पिक रूप से एक संदेश बस पर होते हैं यदि आप अधिक महत्वाकांक्षी हैं। एक प्राप्त प्रक्रिया तब आवधिक आधार पर इन सांख्यिकीय अद्यतनों को एकत्रित करती है - जो हर 5 सेकंड से हर घंटे तक कहीं भी हो सकती है - जो आप चाहते हैं उस पर निर्भर करती है। bytes_received और bytes_sent की गणना तब अपडेट की जाती है, जिनकी गणना कई अलग-अलग "अपडेट" संदेशों को एक साथ सम्मिलित करती है। इसके अतिरिक्त आपको एक ही लेन-देन में एकाधिक आईडी के लिए अपडेट स्टेटमेंट्स को बैच करना चाहिए, यह सुनिश्चित करना कि एक ही चीज करने वाले अन्य लेनदेन के खिलाफ डेडलॉक्स को रोकने के लिए प्राथमिक कुंजी के संबंध में अपडेट स्टेटमेंट जारी किए गए हैं।

इस तरह आप पीजी डेटाबेस पर कितना भार नियंत्रित करने के लिए बड़े हिस्सों में "बैच" गतिविधियां करते हैं, और कई समवर्ती गतिविधियों को एक धारा (या एकाधिक में भी क्रमबद्ध करते हैं, इस पर निर्भर करता है कि कितने धागे/प्रक्रिया अद्यतन जारी कर रहे हैं)। "अवधि" के आधार पर आप जो ट्रेडऑफ ट्यून करते हैं, वह कितना ताज़ा बनाम है कि कितना अद्यतन लोड होता है।