प्रो मानक 12.1 का विमोचन

पोस्टग्रैज प्रो प्रो डीबीएमएस को हमारे उत्पादों को उन उपयोगकर्ताओं तक तेजी से पहुंचाने के लिए डिज़ाइन किया गया है जो हम पोस्टग्रेसीक्यूएल के माध्यम से कर सकते हैं। वे सुविधाएँ जो अभी तक PostgreSQL में शामिल नहीं हैं, लेकिन वहाँ एक ठोस पथ पर हैं, हम पोस्टग्रैस प्रो स्टैंडर्ड में शामिल हैं। इसके अलावा, Postgres Pro Standard में कुछ एक्सटेंशन शामिल हैं जो हमारे ग्राहकों द्वारा मांगे जाते हैं, लेकिन मानक PostgreSQL वितरण में उपलब्ध नहीं हैं।

उपयोगकर्ताओं के अनुरोध पर और उनकी संतुष्टि के लिए, पोस्टग्रैस प्रो स्टैंडर्ड में कभी-कभी कुछ अपवाद होते हैं, कम तुच्छ सुविधाओं को शामिल किया जाता है, जो केवल पोस्टग्रैस प्रो एंटरप्राइज में एक अच्छी जगह में हैं। विशेष रूप से, यह PTRACK है, इसके बारे में नीचे।

सभी नहीं, लेकिन मानक में शामिल अतिरिक्त एक्सटेंशन और उपयोगिताओं का एक उचित हिस्सा, Postgres Professional द्वारा विकसित किया गया था। सभी पोस्टग्रैस प्रो पैच का आविष्कार और हमारे स्वयं के प्रयासों द्वारा लागू किया गया था। आइए डेटाबेस इंजन में हस्तक्षेप की आवश्यकता वाले सुधारों के साथ शुरू करें।

Postgres Pro Standard दो स्तरों पर PostgreSQL से अलग है: एक्सटेंशन और उपयोगिताओं का सेट जो कि विधानसभा में हैं, और कर्नेल ही। कर्नेल पर कुछ उपयोगी पैच लगाए गए हैं जो प्रदर्शन को अनुकूलित करते हैं (उदाहरण के लिए, एक नॉन-ब्रेकिंग लॉक डिटेक्टर) और पैच जो उपयोगिताओं और एक्सटेंशन की दक्षता को बढ़ाते हैं (उदाहरण के लिए, पूरी ताकत से pg_probackup काम करने के लिए, PTRACK 2.0 पैच लागू किया जाता है)। मानक और PostgreSQL के मुख्य संस्करण के बीच अंतर को सबसे बड़ी संभव संगतता के लिए कम से कम किया जाता है। मान लें कि pg_pathman एक्सटेंशन मानक का हिस्सा है, लेकिन इसे github से डाउनलोड किया जा सकता है, जो कि वेनिला पोस्टग्रैसक्यूएल पर निर्मित और स्थापित है, इसमें कोई संगतता समस्याएं नहीं होंगी।
आइए कर्नेल में परिवर्तनों के साथ शुरू करें।

ICU संस्करणों की जाँच

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

इसके अलावा, ICU के माध्यम से स्ट्रिंग की तुलना कभी-कभी libc के माध्यम से तेज होती है, और इसके लिए ज्ञात वर्णों की संख्या अधिक होती है। सामान्य तौर पर, एक उपयोगी पुस्तकालय। पोस्टग्रेज प्रो मानक पहले संस्करण (9.5) के बाद से इसके साथ काम कर रहा है। PostgreSQL में, ICU के साथ काम करना संस्करण 10 से संभव हो गया है।

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

लेकिन यह एक दर्द भरा कठिन निर्णय है। चर्चा और ग्राहकों के एक सर्वेक्षण के बाद, व्यवहार को नरम करने का निर्णय लिया गया। अब केवल COLLATION के संस्करण (नियमों को छाँटते) हैं। यदि डेटाबेस में उपयोग किए जाने वाले COLLATION के संस्करण बदल गए हैं, तो डेटाबेस DBMS शुरू होने पर एक चेतावनी जारी करता है, लेकिन यह बंद नहीं होता है। यह प्रत्येक सत्र की शुरुआत में उपयोगकर्ता को याद दिलाता है।

ताले, जुड़ने और ग्रुप बाय का अनुकूलन

गतिरोध पहचान तंत्र प्रदर्शन को ख़राब कर सकता है। मानक अब नहीं हो सकता है: कर्नेल पैच इसे बिना ब्रेक के काम करने की अनुमति देता है। सत्यापन तंत्र में बड़े सुधार के बाद, ये परेशानी केवल बड़ी संख्या में कोर और कनेक्शन पर दिखाई देती हैं।

उपयुक्त सूचकांकों की उपस्थिति में जोड़ों के परिणामों की संख्या का बेहतर अनुमान।

अब आप उपयुक्त इंडेक्स का उपयोग समूह और फ़ील्ड को सॉर्ट करने के लिए कर सकते हैं। यह फीचर पहली बार स्टैंडर्ड 11.1.1 और एंटरप्राइज 11.2.1 में शामिल किया गया था। हमारे मानक 12 में एक भी है।

पोस्टग्रेज प्रोफेशनल के सीटीओ फेडोर सिगेव ने समुदाय के लिए इन उपयोगी पैच की पेशकश की है, उन्हें माना जा रहा है और उम्मीद है कि संस्करण पीजी 13 में शामिल किया जाएगा।

हम उदाहरण के साथ ग्रुप बाय ऑपरेशन के अनुकूलन को स्पष्ट करते हैं: वे स्पष्ट और आसानी से प्रतिलिपि प्रस्तुत करने योग्य हैं।

इस पैच की बात यह है कि पोस्टग्रेज ने ग्रुप बीवाई में सूचीबद्ध क्षेत्रों के आदेश का अनुकूलन नहीं किया। और निष्पादन समय समूहीकरण के अनुक्रम (उसी क्वेरी परिणाम के साथ) पर निर्भर करता है। हैकर्स मेलिंग सूची पर चर्चा में विवरण हैं।

यदि संसाधित किए जाने वाले पहले कॉलम में मान अद्वितीय है, तो और कुछ की तुलना करने की आवश्यकता नहीं है। यदि आप दूसरे कॉलम से शुरू करते हैं, तो आपको तुलना करनी होगी।


परीक्षण के लिए हो रही है:

DROP TABLE IF EXISTS btg; SELECT i AS id, i/2 AS p, format('%60s', i%2) AS v INTO btg FROM generate_series(1, 1000000) i; 

पाठ फ़ील्ड v में, 60 रिक्त स्थान उत्पन्न होते हैं, इसके बाद नंबर 0 या 1. होते हैं, प्रविष्टियाँ इस तरह दिखती हैं:

 SELECT * FROM btg ORDER BY id DESC LIMIT 3; id | p | v ---------+--------+-------------------------------------------------------------- 1000000 | 500000 | 0 999999 | 499999 | 1 999998 | 499999 | 0 (3 rows) 

 VACUUM btg; ANALYSE btg; SET enable_hashagg=off; SET max_parallel_workers= 0; SET max_parallel_workers_per_gather = 0; 

परिणाम समूह:

 VACUUM btg; EXPLAIN ANALYZE SELECT count(*) FROM btg GROUP BY p, v; 

PostgreSQL योजना:

  QUERY PLAN ------------------------------------------------------ GroupAggregate (cost=204036.84..218981.05 rows=494421 width=73) (actual time=843.999..1194.985 rows=1000000 loops=1) Group Key: p, v -> Sort (cost=204036.84..206536.84 rows=1000000 width=65) (actual time=843.990..946.769 rows=1000000 loops=1) Sort Key: p, v Sort Method: external sort Disk: 73320kB -> Seq Scan on btg (cost=0.00..22346.00 rows=1000000 width=65) (actual time=0.158..151.645 rows=1000000 loops=1) Planning time: 0.317 ms Execution time: 1250.086 ms (8 rows) 

अब रिवर्स ऑर्डर में: v, और केवल तब p:

 EXPLAIN ANALYZE SELECT count(*) FROM btg GROUP BY v, p; QUERY PLAN ------------------------------------------------ GroupAggregate (cost=204036.84..218981.05 rows=494421 width=73) (actual time=2552.477..3353.890 rows=1000000 loops=1) Group Key: v, p -> Sort (cost=204036.84..206536.84 rows=1000000 width=65) (actual time=2552.469..3111.516 rows=1000000 loops=1) Sort Key: v, p Sort Method: external merge Disk: 76264kB -> Seq Scan on btg (cost=0.00..22346.00 rows=1000000 width=65) (actual time=0.082..126.578 rows=1000000 loops=1) Planning time: 0.060 ms Execution time: 3411.048 ms (8 rows) 

यह पता चला है कि रिवर्स काफ़ी धीमा है। ऐसा इसलिए है क्योंकि पहले फ़ील्ड v का मान छोटे प्रसार के साथ किया जाता है। आपको बचे हुए फ़ील्ड (यहाँ - फ़ील्ड पी) पर बहुत सारे चेक करने होंगे।

आइए देखें कि एक समान क्वेरी पैच के साथ कैसे काम करेगी जो प्रसंस्करण कॉलम के लिए इष्टतम क्रम का चयन करती है:

  QUERY PLAN ---------------------------------------------------------------- GroupAggregate (cost=237400.11..252417.09 rows=501698 width=73) (actual time=415.541..703.647 rows=1000000 loops=1) Group Key: p, v -> Sort (cost=237400.11..239900.11 rows=1000000 width=65) (actual time=415.533..507.785 rows=1000000 loops=1) Sort Key: p, v Sort Method: external merge Disk: 73488kB -> Seq Scan on btg (cost=0.00..22346.00 rows=1000000 width=65) (actual time=0.059..139.587 rows=1000000 loops=1) Planning Time: 0.123 ms Execution Time: 742.118 ms (8 rows) 

और रिवर्स ऑर्डर में:

  QUERY PLAN ------------------------------------------------------ GroupAggregate (cost=237400.11..252417.09 rows=501698 width=73) (actual time=414.322..714.593 rows=1000000 loops=1) Group Key: p, v -> Sort (cost=237400.11..239900.11 rows=1000000 width=65) (actual time=414.312..517.707 rows=1000000 loops=1) Sort Key: p, v Sort Method: external merge Disk: 76384kB -> Seq Scan on btg (cost=0.00..22346.00 rows=1000000 width=65) (actual time=0.071..129.835 rows=1000000 loops=1) Planning Time: 0.140 ms Execution Time: 753.031 ms (8 rows) 

योजना कहती है कि वहाँ और प्रसंस्करण आदेश समान है: क्रमबद्ध कुंजी: पी, वी। तदनुसार, समय लगभग समान है। अब तुलना करें कि जब सूचकांक का उपयोग किया जाता है तो क्या होता है।

 CREATE INDEX ON btg(p, v); SET enable_seqscan=off; SET enable_bitmapscan=off; VACUUM btg; EXPLAIN ANALYZE SELECT count(*) FROM btg GROUP BY v, p ; 

PostgreSQL में:

  QUERY PLAN --------------------------------------------------------- GroupAggregate (cost=0.55..74660.04 rows=494408 width=73) (actual time=0.013..391.317 rows=1000000 loops=1) Group Key: p, v -> Index Only Scan using btg_p_v_idx on btg (cost=0.55..62216.16 rows=999974 width=65) (actual time=0.009..120.298 rows=1000000 loops=1) Heap Fetches: 0 Planning time: 0.078 ms Execution time: 442.923 ms (6 rows) 

और रिवर्स ऑर्डर में:

  QUERY PLAN ------------------------------------------------------ GroupAggregate (cost=243904.22..258848.04 rows=494408 width=73) (actual time=2558.485..3352.240 rows=1000000 loops=1) Group Key: v, p -> Sort (cost=243904.22..246404.16 rows=999974 width=65) (actual time=2558.478..3110.242 rows=1000000 loops=1) Sort Key: v, p Sort Method: external merge Disk: 76264kB -> Index Only Scan using btg_p_v_idx on btg (cost=0.55..62216.16 rows=999974 width=65) (actual time=0.011..133.563 rows=1000000 loops=1) Heap Fetches: 0 Planning time: 0.093 ms Execution time: 3409.335 ms (9 rows) 

अब मानक में:

  QUERY PLAN -------------------------------------------------------------- GroupAggregate (cost=0.55..74196.82 rows=501685 width=73) (actual time=0.150..412.174 rows=1000000 loops=1) Group Key: p, v -> Index Only Scan using btg_p_v_idx on btg (cost=0.55..61680.16 rows=999974 width=65) (actual time=0.134..149.669 rows=1000000 loops=1) Heap Fetches: 0 Planning Time: 0.175 ms Execution Time: 448.635 ms (6 rows) 

और रिवर्स ऑर्डर में:

  QUERY PLAN ------------------------------------------------------------- GroupAggregate (cost=0.55..74196.82 rows=501685 width=73) (actual time=0.014..307.258 rows=1000000 loops=1) Group Key: p, v -> Index Only Scan using btg_p_v_idx on btg (cost=0.55..61680.16 rows=999974 width=65) (actual time=0.008..89.204 rows=1000000 loops=1) Heap Fetches: 0 Planning Time: 0.054 ms Execution Time: 337.766 ms (6 rows) 

समय फिर वही है, जो स्वाभाविक है: वास्तव में, क्रियाएं समान हैं।

बूट पर एक अशक्त बाइट की जगह

Postgres Pro डेटा में शून्य बाइट्स (0x00) को स्वीकार नहीं करता है, इसलिए COPY FROM के साथ उन्हें प्रतिस्थापित किया जाना चाहिए, अन्यथा एक त्रुटि होगी । CSV फ़ाइल से डेटा आयात करते समय ग्राहक को हुई यह वास्तविक समस्या है। इसका समाधान दिए गए ASCII वर्ण के साथ नल बाइट्स को बदलना है। यह COPY FROM को निष्पादित करते समय उपयोग किए जाने वाले QUOTE और DELIMITER वर्णों से अलग होना चाहिए; अन्यथा, परिणाम अप्रत्याशित हो सकता है। डिफ़ॉल्ट रूप से, चर nul_byte_replacement_on_import (string) '\ 0' का मान, यानी कोई प्रतिस्थापन नहीं किया जाता है।

WaitLSN

एलएसएन लॉग में एक अनुक्रमिक संख्या है , अर्थात, वाल (लॉग अनुक्रम संख्या) में स्थिति के लिए एक संकेतक है। WAITLSN कमांड निर्दिष्ट LSN खेलने के लिए प्रतीक्षा कर रही है। यदि आवेदन मास्टर और प्रतिकृति दोनों के साथ काम करता है, तो आपको यह सुनिश्चित करने की आवश्यकता है कि वे समय-समय पर समकालिक हैं। WAITLSN, PostgrePro में एक इंटरप्रोसेस मैकेनिज्म है जो सिंक्रोनाइज़ेशन के दौरान सिंक्रोनस को नियंत्रित करता है । डिफ़ॉल्ट रूप से, प्रतीक्षा समय असीमित है। आप Ctrl + C दबाकर या पोस्टग्रेज सर्वर को रोककर प्रतीक्षा को समाप्त कर सकते हैं। आप TIMEOUT संकेत जोड़कर भी टाइमआउट सेट कर सकते हैं, या NowAIT संकेत का उपयोग करके प्रतीक्षा किए बिना लक्ष्य LSN की स्थिति की जांच कर सकते हैं।
मान लीजिए कि एक आवेदन एक निश्चित कार्रवाई करता है, मास्टर पर डीबीएमएस से एलएसएन नंबर प्राप्त करता है और अब यह सुनिश्चित करना चाहता है कि प्रतिकृति पर किए गए कार्यों को मास्टर के साथ सिंक्रनाइज़ किया जाएगा, अर्थात। यह सुनिश्चित किया जा सकता है कि विज़ार्ड में दर्ज की गई यह प्रतिकृति पहले ही आ चुकी है और पढ़ने के लिए तैयार है। डिफ़ॉल्ट रूप से, यह आमतौर पर गारंटीकृत नहीं होता है। WAITLSN आपको इस इंटरैक्शन को नियंत्रित करने और डिफ़ॉल्ट रूप से, TIMEOUT और NowAIT तक INFINITELY से स्लीप मोड का चयन करने की अनुमति देता है।

पूर्व रिकवरी से चर चर ।conf

SIGHUP सिग्नल पर, PostgreSQL पुन: postgresql.conf पढ़ता है, लेकिन पुनर्प्राप्ति नहीं ।conf। मानक और उद्यम 10.4.1 में एक अपेक्षाकृत नया कर्नेल पैच पेश किया गया। फिर से वसूली और वसूली करने के लिए मजबूर ।conf। लेकिन Postgres 12 में कोई पुनर्प्राप्ति नहीं है ।conf फ़ाइल बिल्कुल भी नहीं है: इसमें से सभी चर postgresql.conf में स्थानांतरित हो जाते हैं। फिर भी, हालांकि पूरी फ़ाइल को फिर से पढ़ा जाता है, लेकिन पुनर्प्राप्ति से चर को SightUP द्वारा पुन: परिभाषित नहीं किया गया था, लेकिन पोस्टग्रेज के पुनरारंभ की आवश्यकता थी। मानक में, यह आवश्यक नहीं है: सब कुछ पढ़ा और फिर से परिभाषित किया गया है।

PTRACK सहायता

PTRACK 2.0 मानक और एंटरप्राइज़ संस्करणों के लिए 11 और उससे पहले का नया डिज़ाइन किया गया PTRACK तंत्र है। DBMS स्तर पर, यह कर्नेल पैच के लिए धन्यवाद काम करता है, और अब पैच में ptrack एक्सटेंशन जोड़ दिया गया है। PTRACK 2.0 डेटा पेज को ट्रैक करता है और इस जानकारी को पुनः प्राप्त करने के लिए एक इंटरफ़ेस प्रदान करता है। नैदानिक ​​प्रयोजनों के लिए इसका उपयोग किया जा सकता है, उदाहरण के लिए, एक निर्दिष्ट बिंदु के सापेक्ष "उत्परिवर्तित" समय में दृढ़ता से एक अनुमान प्राप्त करने के लिए, लॉग (एलएसएन) में अनुक्रमिक संख्या के रूप में सेट किया गया है, और वृद्धिशील बैकअप बनाने के लिए।

एक नियम के रूप में एक वृद्धिशील बैकअप प्रक्रिया का सबसे कठिन और "महंगा" हिस्सा, क्लस्टर में पृष्ठों के पूरे सेट से परिवर्तित पृष्ठों के सबसेट को अलग करना है। इस तथ्य के कारण कि सर्वर इस कार्य को ले सकता है और जल्दी से बदले हुए पृष्ठों के बारे में जानकारी प्रदान करता है, PTRACK का उपयोग करके वृद्धिशील बैकअप का समय काफी कम हो जाता है।

PTRACK 2.0 साझा मेमोरी में एक निर्दिष्ट आकार की हैश तालिका का उपयोग करता है, समय-समय पर ptrack.map फ़ाइल के साथ सिंक्रनाइज़ किया जाता है।

ऑपरेशन के आंतरिक तंत्र के एक बुनियादी परिवर्तन और पुराने संस्करणों के साथ असंगत उपयोगकर्ता इंटरफ़ेस के कारण, ptrack एक्सटेंशन केवल PostgresPro मानक और एंटरप्राइज़ के 12 वें संस्करण में उपलब्ध है, और पोस्टग्रे 12 पर पैच और एक्सटेंशन के रूप में उपलब्ध होगा।

विंडोज के लिए psql में एडिटिंग कमांड

WinEditLine का उपयोग करके विंडोज के लिए psql में इनपुट कमांड को एडिट करने के लिए उन्नत समर्थन लागू किया गया है। अब आप अलग-अलग वर्णमाला के वर्णों को एक साथ प्रदर्शित कर सकते हैं (विशेष रूप से, सिरिलिक को सामान्य रूप से गैर-रूसी विंडोज पर प्रदर्शित किया जाता है)।

एकीकृत पैकेज संरचना

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

अब एक्सटेंशन के बारे में:

dump_stat

यह 9.5 के रूप में जल्दी दिखाई दिया। डेटा को स्थानांतरित या पुनर्स्थापित करते समय, संचित आंकड़े आमतौर पर स्थानांतरित नहीं होते हैं। यदि आप इसे ANALYZE कमांड के साथ फिर से इकट्ठा करते हैं, तो इसे पूरे क्लस्टर के लिए निष्पादित किया जाएगा, और निर्दिष्ट डेटाबेस के लिए नहीं। इसके लिए बड़े डेटाबेस के लिए अतिरिक्त समय की आवश्यकता हो सकती है।

डंप_स्टैट एक्सटेंशन उन कार्यों को प्रदान करता है जो आपको pg_statistic तालिका की सामग्री को अनलोड करने और पुनर्स्थापित करने की अनुमति देता है। डेटा अपलोड / रिकवरी करते समय, आप संपूर्ण क्लस्टर के लिए ANALYZE कमांड को चलाने के बिना, एक नए सर्वर में मौजूदा आंकड़ों को स्थानांतरित करने के लिए डंप_स्टैट का उपयोग कर सकते हैं।

डंप_स्टैटिस्टिक फ़ंक्शन pg_statistic सिस्टम कैटलॉग की सामग्री को अनलोड करता है। यह pg_statistic में प्रत्येक tuple के लिए एक INSERT का उत्पादन करता है, सिवाय उन लोगों के जो सूचनाओं में तालिकाओं के बारे में आंकड़े शामिल करते हैं_schema और pg_catalog स्कीमा।

jsquery

याद रखें कि यह JSON (B) के साथ काम करने के लिए एक विस्तार है , जेएस नहीं। यह इन डेटा प्रकारों के प्रसंस्करण के लिए कार्यों का एक समूह प्रदान करता है। इंडेक्स, JSON (B) में खोज का उपयोग करके कुशल के लिए यह एक विशेष क्वेरी भाषा है। हब पर लेख में, आप JSON (B) के साथ काम करने के jsquery और वैकल्पिक तरीकों के कुछ उदाहरण देख सकते हैं, उदाहरण के लिए JSONPath (हमारी कंपनी के विकास दोनों)।

online_analyze

यह एक्सटेंशन उन फ़ंक्शन का एक सेट प्रदान करता है जो तुरंत उन आंकड़ों में अपडेट करते हैं जो INSERT, UPDATE, DELETE या SELECT INTO ऑपरेशंस के बाद निर्दिष्ट किए गए हैं। विस्तार के लेखक फेडोर सिगेव हैं।

Online_analyze मॉड्यूल का उपयोग करने के लिए, आपको साझा लाइब्रेरी लोड करनी होगी:

 LOAD 'online_analyze'; 

सांख्यिकी अपडेट को अनुकूलित किया जा सकता है। उदाहरण के लिए, तालिका के आकार का एक प्रतिशत या पंक्ति परिवर्तनों की न्यूनतम (थ्रेशोल्ड) संख्या निर्धारित करें, जिसके बाद आंकड़े तुरंत एकत्र किए जाएंगे।

pg_pathman

Postgres Professional में pg_pathman एक्सटेंशन को PostgreSQL कर्नेल की तुलना में पहले बनाया गया था और विभाजन बनाने के लिए कार्यों का एक पूरा पूरा सेट लागू किया गया था। इसलिए, वर्गों के साथ कई ऑपरेशन एक और दूसरे तंत्र के साथ किए जा सकते हैं। केवल यह सलाह दी जाती है कि घोषित विभाजन और pg_pathman द्वारा बनाए गए वर्गों को न मिलाएं।

हालाँकि, कई pg_pathman ऑपरेशन अभी भी तेज़ हैं और कुछ सुविधाएँ PostgreSQL में गायब हैं। उदाहरण के लिए, वर्गों का स्वत: निर्माण (काटना)। PostgreSQL में, आपको प्रत्येक अनुभाग की सीमाओं को निर्धारित करने की आवश्यकता है। यदि हम उन आंकड़ों को भरते हैं जिनके बारे में पहले से पता नहीं होता है कि वे कितने खंडों में हो सकते हैं और उन्हें बिखेर देना चाहिए, तो यह केवल अंतराल सेट करना और सॉफ़्टवेयर को स्वयं वर्गों में कटौती करने के लिए सुविधाजनक है - जितना आवश्यक हो। pg_pathman जानते हैं कि, PostgreSQL कैसे नहीं करता है। लेकिन, पीजी 11 के साथ शुरू होने पर, एक डिफ़ॉल्ट अनुभाग (डिफ़ॉल्ट) है, जहां आप उन सभी रिकॉर्डों को डंप कर सकते हैं जो निर्दिष्ट सीमाओं के साथ वर्गों में नहीं आते हैं।

PostgreSQL समुदाय के नेताओं के साथ एक बुनियादी समझौता है कि भविष्य में सबसे अच्छा, जबकि pg_pathman की अनूठी विशेषताएं मुख्य शाखा में आएंगी। लेकिन उस समय तक, pg_pathman आवेदन DB व्यवस्थापक और अनुप्रयोग प्रोग्रामर के लिए जीवन को आसान बना सकता है।

एक एक्सटेंशन बनाएं:

 CREATE EXTENSION pg_pathman; 

pg_pathman आपको अनुभागों में बड़ी तालिकाओं को तोड़ने की अनुमति देता है और एक सुविधाजनक एपीआई प्रदान करता है - अनुभाग बनाने और उनके साथ काम करने के लिए कार्यों का एक सेट। उदाहरण के लिए, फ़ंक्शन का उपयोग करना

 create_range_partitions(relation REGCLASS, expression TEXT, start_value ANYELEMENT, p_interval INTERVAL, p_count INTEGER DEFAULT NULL, partition_data BOOLEAN DEFAULT TRUE); 

हम पूछ सकते हैं

 SELECT create_range_partitions('log', 'dt', NULL::date, '1 month'::interval); 

जिसके बाद हम अनुभाग जोड़ते हैं:

 SELECT add_range_partition('log', NULL, '2017-01-01'::date, 'log_archive', 'ts0'); SELECT add_range_partition('log', '2017-01-01'::date, '2017-02-01'::date, 'log_1'); SELECT add_range_partition('log', '2017-02-01'::date, '2017-03-01'::date', log_2'); 

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

 SELECT create_range_partitions('log', 'dt', '2017-01-01'::date, '1 month'::interval); 

एक साधारण टेबल पर, यह इस तरह दिखेगा:

 CREATE TABLE pg_pathmania(id serial, val float); INSERT INTO pg_pathmania(val) SELECT random() * 1000 FROM generate_series(1, 1000); SELECT create_range_partitions('pg_pathmania', 'id', 0, 50); test_parti=# \d+ pg_pathmania Table "public.pg_pathmania" Column | Type | Collation | Nullable | Default | Storage | S tats target | Description --------+------------------+-----------+----------+-----------------------+---------+------+------ id | integer | | not null | nextval('pg_pathmania_id_seq'::regclass) | plain | | val | double precision | | | | plain | | Child tables: pg_pathmania_1, pg_pathmania_10, pg_pathmania_11, pg_pathmania_12, pg_pathmania_13, pg_pathmania_14, pg_pathmania_15, pg_pathmania_16, pg_pathmania_17, pg_pathmania_18, pg_pathmania_19, pg_pathmania_2, pg_pathmania_20, pg_pathmania_21, pg_pathmania_3, pg_pathmania_4, pg_pathmania_5, pg_pathmania_6, pg_pathmania_7, pg_pathmania_8, pg_pathmania_9 

PostgreSQL में, हमें अपनी टीम के साथ प्रत्येक अनुभाग बनाना होगा। ऐसे मामलों में, वे निश्चित रूप से एक स्क्रिप्ट लिखते हैं जो आवश्यक डीडीएल कोड को स्वचालित रूप से उत्पन्न करता है। आपको pg_pathman में स्क्रिप्ट लिखने की आवश्यकता नहीं है, सब कुछ पहले से ही है। लेकिन यह सबसे दिलचस्प नहीं है। हम एक रिकॉर्ड डालेंगे जो न केवल किसी भी मौजूदा अनुभाग में आईडी के द्वारा प्राप्त करता है, बल्कि सबसे पास में भी नहीं आता है:

 INSERT INTO pg_pathmania(id, val) VALUES (2000, 277.835794724524); 

दोबारा, तालिका की सामग्री को \ d + pg_pathmania के साथ जांचें:

 Child tables: pg_pathmania_1, pg_pathmania_10, ... pg_pathmania_39, pg_pathmania_4, pg_pathmania_40, pg_pathmania_41, 

यहाँ क्या हुआ: pg_pathman ने देखा कि id = 2000 के साथ रिकॉर्ड पहले से निर्मित अनुभागों में नहीं आता है, परिकलित किया गया है कि उन्हें कितने बनाने की आवश्यकता है, RANGE अंतराल जिसके साथ तालिका को पहले विभाजित किया गया था, को जानकर और उस अनुभाग को बनाया जहां नया रिकॉर्ड गिरता है, और निश्चित रूप से, पुराने खंडों की ऊपरी सीमा और नए खंड की निचली सीमा के बीच सभी खंड। यह बहुत सुविधाजनक है, और ऐसे मामलों में जहां अद्यतन डेटा के विभाजन क्षेत्र के मूल्यों की खराब भविष्यवाणी की जाती है, यह pg_pathman का एक गंभीर लाभ है।

pg_query_state

हमारे द्वारा विकसित किया गया यह विस्तार हमें सेवा प्रक्रिया में अनुरोधों की वर्तमान स्थिति का पता लगाने की अनुमति देता है। यह संस्करण 9.5 से अस्तित्व में है और ग्राहक के कई अनुरोधों के जन्म के कारण है।

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

उपयोगिताएँ:

pgBouncer

यह इतना लोकप्रिय कनेक्शन खींचने वाला है कि यहां इसके बारे में बात करना अजीब होगा। यह सिर्फ इतना है कि यह मानक का हिस्सा है, और इसे अलग से वैनिला पोस्टग्रेक्यूएल के मामले में स्थापित करना होगा।

pg_probackup

pg_probackup हमारे सबसे लोकप्रिय विकासों में से एक है। यह एक बैकअप और रिकवरी मैनेजर है जिसे मुख्य रूप से अनास्तासिया लुबेनिकोवा, ग्रिगरी स्मोलकिन और उपयोगकर्ता समुदाय द्वारा विकसित और अद्यतन किया जा रहा है।

Pg_probackup के प्रतियोगी लाभ: ब्लॉक ग्रैन्युलैरिटी (8KB), तीन वृद्धिशील बैकअप मोड (PAGE, DELTA, PTRACK) के साथ वृद्धिशील बैकअप, ऑन-डिमांड बैकअप अखंडता जाँच, PostgreSQL सत्यापन, बैकअप संपीड़न, आंशिक पुनर्प्राप्ति, आदि।

PTRACK वृद्धिशील प्रतिलिपि मोड, पुनर्निर्देशित तंत्र के भाग के समान नाम के विस्तार पर निर्भर करता है - PTRACK 2.0 - अब और भी तेज हो गया है और अब pg -probackup मोड का सबसे तेज और "सबसे सस्ता" तरीका है।

pg_repack

pg_repack एक लोकप्रिय उपयोगिता है, इसका संचालन VACUUM FULL या CLUSTER के समान है। यह न केवल टेबल को हटाता है, voids को हटाता है, बल्कि यह भी जानता है कि क्लस्टर किए गए अनुक्रमित के भौतिक क्रम को कैसे पुनर्स्थापित किया जाए। ग्राहक और रिक्त स्थान के विपरीत, यह इन कार्यों को "चलते-फिरते" करता है, बिना विशेष टेबल के ताले और आमतौर पर कुशलता से करता है। यह वेनिला संस्करण में शामिल नहीं है।

pg_variables

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

एक अस्थायी डेटा वेयरहाउस के रूप में, pg_variables एक्सटेंशन अस्थायी टेबल्स की तुलना में बहुत अधिक उत्पादक है (pgbench परीक्षण लेख में हैं), और यह अधिक सुविधाजनक है: डेटा सेट को "पैकेज - चर" जोड़ी द्वारा परिभाषित किया गया है, जिसे पैरामीटर के रूप में पारित किया जा सकता है, जो एक फ़ंक्शन से लौटा है, आदि। चर के साथ काम करने के लिए सेट / फ़ंक्शंस हैं। इसलिए, उदाहरण के लिए, आप कई चर स्टोर कर सकते हैं (पैकेज पैकेज का नाम है, और दशमलव बिंदु के बाद का भाव इस पैकेज में चर हैं:

 SELECT pgv_set_int('package','#'||n,n), n FROM generate_series(1,1000000) AS gs(n); 

चर के पास एक दिलचस्प संपत्ति है: बग या लाभ नहीं, लेकिन एक विशेषता: एक्सटेंशन के माध्यम से संग्रहीत डेटा लेनदेन के बाहर मौजूद है - वे एक लेनदेन को ठीक करने और रोलबैक के मामले में दोनों बचाए जाते हैं; इसके अलावा, एक अलग कमांड निष्पादित करते समय, आंशिक डेटा प्राप्त किया जा सकता है:

 SELECT pgv_insert('package', 'errs', row(n)) FROM generate_series(1,5) AS gs(n) WHERE 1.0/(n-3)<>0; ERROR: there is a record in the variable "errs" with same key test_parti=# SELECT * FROM pgv_select('package','errs') AS r(i int); i --- 1 2 (2 rows) 

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

निष्कर्ष में, कुछ और एक्सटेंशन:

sr_plan, बागवान

sr_plan क्वेरी योजनाओं को सहेजता है और पुनर्स्थापित करता है । इसे इस तरह शामिल करें:

 SET sr_plan.write_mode = true; 

उसके बाद, बाद के सभी प्रश्नों की योजना sr_plans तालिका में संग्रहीत की जाएगी, जब तक कि यह चर गलत पर सेट न हो जाए। सभी अनुरोधों की योजना, जिनमें बार-बार शामिल हैं, सहेजे जाते हैं।

प्लानर किसी क्वेरी को निष्पादित करते समय निर्दिष्ट सूचक को जोड़ने या डिस्कनेक्ट करने के लिए अनुसूचक के संकेत का समर्थन करता है। केवल दो GUC चर हैं: enable_index / desable_index:

 SET plantuner.disable_index='id_idx2'; 

पूर्ण-पाठ खोज के लिए एक्सटेंशन: साझा_इस्पेल, pg_tsparser

Share_ispell एक्सटेंशन, जो आपको साझा की गई मेमोरी में शब्दकोशों को रखने की अनुमति देता है, मानक में है और PostgreSQL में नहीं है। हमारे हंसेल-तानाशाह सेट में भाषाओं के लिए शब्दकोश हैं:

• hunspell_en_us,
• hunspell_fr,
• hunspell_nl_nl,
• hunspell_ru_ru

Pg_tsparser एक्सटेंशन एक वैकल्पिक पाठ खोज विश्लेषक है । यह एक्सटेंशन अंडरस्कोर में शामिल किए गए शब्दों के लिए मानक पाठ पार्सिंग रणनीति में बदलाव करता है, साथ ही अंक और अक्षर अंडरस्कोर से अलग हो जाते हैं। डिफ़ॉल्ट रूप से लौटे शब्द के अलग-अलग हिस्सों के अलावा, pg_tsparser संपूर्ण शब्द भी लौटाता है। यह तकनीकी दस्तावेज या इस तरह के लेखों के लिए बहुत महत्वपूर्ण है, जिसमें प्रोग्राम कोड पाया जाता है, और इसमें "pg_tsparser", "pg_probackup", "jsonb_build_object" जैसे शब्द होते हैं। यह पार्सर इन शब्दों को न केवल घटकों के एक सेट के रूप में मानता है, बल्कि एक एकल टोकन के रूप में भी है, और जिससे खोज की गुणवत्ता में सुधार होता है।

1 सी के लिए एक्सटेंशन

• Microsoft SQL सर्वर के साथ संगतता के लिए mchar एक वैकल्पिक डेटा प्रकार है;
• fulleq - Microsoft SQL सर्वर के साथ संगतता के लिए एक अतिरिक्त समानता ऑपरेटर प्रदान करता है;
• fasttrun — - , pg_class.

, PostgresPro Standard PostgreSQL. , , , , .