Ingestion के लिए WAL और Checkpoints का समायोजन
I/O रुकावटों के बिना उच्च write rates बनाए रखने के लिए WAL settings और unlogged tables को समायोजित करें।
Ingestion के लिए WAL और Checkpoints का समायोजन, CoddyKit पर PostgreSQL प्रदर्शन और क्वेरी अनुकूलन का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह PostgreSQL प्रदर्शन और क्वेरी अनुकूलन सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
इंजेशन के लिए WAL क्यों महत्वपूर्ण है
PostgreSQL में आपके द्वारा COMMIT किया गया हर बदलाव डेटा फ़ाइलों को अपडेट करने से पहले Write-Ahead Log (WAL) में लिखा जाता है। इससे टिकाऊपन और क्रैश रिकवरी सुनिश्चित होती है, लेकिन भारी बल्क लोड के दौरान WAL I/O का बड़ा स्रोत बन जाता है।
- हर
INSERTयाCOPYWAL रिकॉर्ड बनाता है। - समय-समय पर एक चेकपॉइंट गंदे पेज को साझा बफ़र से डिस्क पर फ्लश करता है।
- यदि चेकपॉइंट बहुत बार सक्रिय हों, तो आपको दोगुना I/O देना पड़ता है और रुकावटें आती हैं।
बिना I/O उछाल के उच्च लेखन दर बनाए रखने के लिए WAL और चेकपॉइंट व्यवहार की ट्यूनिंग महत्वपूर्ण है।
वर्तमान WAL सेटिंग का निरीक्षण
कुछ भी बदलने से पहले देखें कि आपका सर्वर किन सेटिंग के साथ चल रहा है। प्रासंगिक विकल्प pg_settings में होते हैं और उन्हें SHOW से क्वेरी किया जा सकता है।
इंजेशन से संबंधित सबसे महत्वपूर्ण पैरामीटर max_wal_size, checkpoint_timeout, checkpoint_completion_target और wal_compression हैं।
SELECT name, setting, unit
FROM pg_settings
WHERE name IN (
'max_wal_size',
'min_wal_size',
'checkpoint_timeout',
'checkpoint_completion_target',
'wal_compression'
);max_wal_size बढ़ाना
चेकपॉइंट या तो checkpoint_timeout बीतने पर सक्रिय होता है या WAL की मात्रा max_wal_size तक पहुँचने पर। बड़े लोड के दौरान डिफ़ॉल्ट मान (अक्सर 1 GB) बार-बार पहुँच जाता है, जिससे लगातार चेकपॉइंट होते रहते हैं।
max_wal_sizeबढ़ाने से चेकपॉइंट के बीच WAL अधिक समय तक जमा हो सकता है।- कम चेकपॉइंट होने पर गंदे पेज बार-बार लिखे जाने के बजाय एकत्रित होकर एक बार लिखे जाते हैं।
इंजेशन अवधि के लिए 8–32 GB जैसे मान सामान्य हैं।
ALTER SYSTEM SET max_wal_size = '16GB';
SELECT pg_reload_conf();चेकपॉइंट I/O को फैलाना
checkpoint_completion_target नियंत्रित करता है कि PostgreSQL चेकपॉइंट लेखनों को फैलाने के लिए अंतराल के कितने भाग का उपयोग करता है। 0.9 का मान मतलब है कि अगले चेकपॉइंट तक उपलब्ध समय के 90% में लेखन फैलाया जाता है, जिससे अचानक आने वाला I/O उछाल टलता है।
लंबे checkpoint_timeout के साथ यह अनियमित चेकपॉइंट तूफ़ानों को सहज, लगातार लेखन प्रवाह में बदल देता है।
ALTER SYSTEM SET checkpoint_timeout = '30min';
ALTER SYSTEM SET checkpoint_completion_target = 0.9;
SELECT pg_reload_conf();WAL रिकॉर्ड को संपीड़ित करना
चेकपॉइंट के बाद जब पूर्ण-पृष्ठ इमेज लिखी जाती हैं (किसी पेज में पहला बदलाव), तो वे WAL को बहुत बड़ा बना देती हैं। wal_compression इन पूर्ण-पृष्ठ इमेज को संपीड़ित करता है, जिससे थोड़े CPU के बदले WAL की मात्रा और डिस्क I/O काफी कम हो जाते हैं।
- आधुनिक PostgreSQL में आप एल्गोरिदम चुन सकते हैं, जैसे
lz4याzstd। - कम WAL लिखे जाने का अर्थ तेज़ प्रतिकृति और आकार-आधारित ट्रिगर से कम चेकपॉइंट भी है।
ALTER SYSTEM SET wal_compression = 'lz4';
SELECT pg_reload_conf();Unlogged तालिकाएँ: WAL को पूरी तरह छोड़ें
एक unlogged table बिल्कुल भी WAL नहीं लिखती। ETL पाइपलाइन में staging तालिकाओं के लिए इससे थ्रूपुट काफी बढ़ सकता है, क्योंकि लेखन की सबसे बड़ी लागत ही हट जाती है।
- डेटा अब भी डिस्क पर लिखा जाता है, लेकिन टिकाऊ रूप से लॉग नहीं किया जाता।
- समझौता: क्रैश के बाद तालिका अपने-आप खाली कर दी जाती है और स्टैंडबाय सर्वर पर प्रतिकृत नहीं होती।
फिर से बनाई जा सकने वाली staging डेटा के लिए यह आदर्श है; सिस्टम ऑफ रिकॉर्ड के लिए कभी नहीं।
CREATE UNLOGGED TABLE staging_events (
id bigint,
payload jsonb,
loaded_at timestamptz DEFAULT now()
);Staging से अंतिम तालिका का पैटर्न
एक विश्वसनीय ETL design कच्ची पंक्तियों को तेज़ unlogged staging तालिका में लोड करता है, उन्हें रूपांतरित करता है और फिर साफ़ किए गए परिणाम को टिकाऊ अंतिम तालिका में ले जाता है।
- बल्क
COPYपूरी गति से unlogged तालिका में लिखा जाता है। - अंतिम
INSERT ... SELECTसत्यापित डेटा के लिए केवल एक बार WAL लिखता है।
जहाँ टिकाऊपन महत्वपूर्ण नहीं है वहाँ आपको गति मिलती है, और जहाँ महत्वपूर्ण है वहाँ सुरक्षा।
INSERT INTO events (id, payload, loaded_at)
SELECT id, payload, loaded_at
FROM staging_events
WHERE payload IS NOT NULL;
TRUNCATE staging_events;Unlogged तालिका को टिकाऊ बनाना
यदि लोड पूरा होने के बाद staging तालिका को टिकाऊ बनाना हो, तो पंक्तियों की प्रतिलिपि बनाने के बजाय उसे वहीं परिवर्तित किया जा सकता है। इसे LOGGED पर सेट करने से तालिका फिर से लिखी जाती है और उसके लिए WAL लॉगिंग शुरू हो जाती है।
- यह रूपांतरण पूरी तालिका के लिए WAL बनाता है, इसलिए इसे अंत में एक ही बार करें।
- अगले लोड से पहले फिर से
UNLOGGEDपर जाने से प्रति-पंक्ति WAL दोबारा बचता है।
ALTER TABLE staging_events SET LOGGED;COPY, पंक्ति-दर-पंक्ति INSERT से बेहतर है
WAL की ट्यूनिंग के बाद भी, आप डेटा कैसे लोड करते हैं यह महत्वपूर्ण है। COPY हजारों अलग-अलग INSERT स्टेटमेंट की तुलना में पंक्तियों को बहुत कम और बड़े WAL रिकॉर्ड में बैच करता है तथा हर स्टेटमेंट की पार्स और योजना बनाने की अतिरिक्त लागत से बचाता है।
COPY को unlogged staging तालिका के साथ मिलाने पर आप सबसे अधिक टिकाऊ इंजेशन दर प्राप्त करते हैं।
COPY staging_events (id, payload)
FROM '/data/events.csv'
WITH (FORMAT csv, HEADER true);चेकपॉइंट दबाव की निगरानी
यह जानने के लिए कि आपकी ट्यूनिंग सफल रही या नहीं, चेकपॉइंट आँकड़ों पर नज़र रखें। मुख्य संकेत requested (आकार से सक्रिय) चेकपॉइंट और timed चेकपॉइंट का अनुपात है।
- बहुत से
requestedचेकपॉइंट का अर्थ है कि आपके लोड के लिएmax_wal_sizeअब भी बहुत छोटा है। - मुख्यतः
timedचेकपॉइंट का अर्थ है कि WAL की मात्रा निर्धारित सीमा के भीतर है।
नए संस्करणों में ये काउंटर pg_stat_checkpointer में होते हैं; पुराने संस्करणों में pg_stat_bgwriter का उपयोग होता है।
SELECT num_timed, num_requested,
buffers_written, write_time, sync_time
FROM pg_stat_checkpointer;लोड के बाद रीसेट करना
आक्रामक इंजेशन सेटिंग लोड अवधि में उपयोगी होती हैं, लेकिन बाद में रिकवरी समय और डिस्क व्यर्थ करती हैं। बैच पूरा होने पर संतुलित मान बहाल करें और एक साफ़ चेकपॉइंट ज़बरन चलाएँ, ताकि अगली क्रैश रिकवरी तेज़ हो।
max_wal_sizeऔरcheckpoint_timeoutको स्थिर अवस्था के मानों पर वापस कम करें।- सब कुछ तुरंत फ्लश करने के लिए मैन्युअल
CHECKPOINTचलाएँ।
ALTER SYSTEM SET max_wal_size = '2GB';
ALTER SYSTEM SET checkpoint_timeout = '5min';
SELECT pg_reload_conf();
CHECKPOINT;त्वरित जाँच
आप 200 मिलियन पंक्तियों को ऐसी staging तालिका में बल्क-लोड कर रहे हैं जिसे बाद में फिर से बनाया जा सकता है और जिसका सत्यापन करके टिकाऊ तालिका में कॉपी किया जाएगा। लोड के दौरान WAL लेखन की मात्रा को सीधे तौर पर सबसे अधिक कौन-सा विकल्प घटाता है?
पुनरावलोकन
I/O रुकावटों के बिना उच्च लेखन दर बनाए रखने के लिए:
- max_wal_size और checkpoint_timeout बढ़ाएँ ताकि चेकपॉइंट कम बार सक्रिय हों, और लेखनों को फैलाने के लिए checkpoint_completion_target को 0.9 के पास रखें।
- पूर्ण-पृष्ठ इमेज का आकार घटाने के लिए wal_compression सक्षम करें।
- फिर से बनाई जा सकने वाली डेटा के लिए WAL छोड़ने हेतु UNLOGGED staging तालिकाओं का उपयोग करें, फिर सत्यापित पंक्तियों को टिकाऊ तालिका में ले जाएँ।
- पंक्ति-दर-पंक्ति इंसर्ट की तुलना में COPY को प्राथमिकता दें।
- requested और timed चेकपॉइंट की निगरानी
pg_stat_checkpointerसे करें और लोड के बाद संतुलित मान बहाल करें।
एआई शिक्षक के साथ SQL सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 22
- पाठ
- 88
अक्सर पूछे जाने वाले प्रश्न
क्या “Ingestion के लिए WAL और Checkpoints का समायोजन” पाठ निःशुल्क है?
हाँ — PostgreSQL प्रदर्शन और क्वेरी अनुकूलन अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “Ingestion के लिए WAL और Checkpoints का समायोजन” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“Ingestion के लिए WAL और Checkpoints का समायोजन” में मैं क्या सीखूँगा?
I/O रुकावटों के बिना उच्च write rates बनाए रखने के लिए WAL settings और unlogged tables को समायोजित करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ PostgreSQL प्रदर्शन और क्वेरी अनुकूलन का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या PostgreSQL प्रदर्शन और क्वेरी अनुकूलन शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर PostgreSQL प्रदर्शन और क्वेरी अनुकूलन शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।
“Ingestion के लिए WAL और Checkpoints का समायोजन” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- COPY और Multi-Row INSERT की Throughput तुलना
- Load के दौरान Indexes और Constraints को स्थगित करना
- Ingestion के लिए WAL और Checkpoints का समायोजन
- ON CONFLICT के साथ बड़े पैमाने पर Upserts