यह मेरे ब्लॉग "माई फेवरेट पोस्टग्रेएसक्यूएल एक्सटेंशन्स" का दूसरा भाग है, जिसमें मैंने आपको दो पोस्टग्रेएसक्यूएल एक्सटेंशन, पोस्टग्रेज_एफडडब्ल्यू और पीजी_पार्टमैन से परिचित कराया था। इस भाग में मैं तीन और खोजूंगा।
pgऑडिट
ब्याज का अगला PostgreSQL विस्तार विभिन्न सरकारी, वित्तीय और अन्य प्रमाणित निकायों जैसे ISO, BSI, और FISCAM, आदि द्वारा ऑडिटिंग आवश्यकताओं को पूरा करने के उद्देश्य से है। मानक लॉगिंग सुविधा जो PostgreSQL मूल रूप से प्रदान करता है log_statement के साथ =सभी निगरानी के लिए उपयोगी है, लेकिन यह ऑडिट का पालन करने या सामना करने के लिए आवश्यक विवरण प्रदान नहीं करता है। pgAudit एक्सटेंशन हुड के तहत क्या हुआ, इसके विवरण पर ध्यान केंद्रित करता है, जबकि एक डेटाबेस एक आवेदन अनुरोध को संतुष्ट कर रहा था।
एक ऑडिट ट्रेल या ऑडिट लॉग PostgreSQL द्वारा प्रदान की गई एक मानक लॉगिंग सुविधा द्वारा बनाया और अपडेट किया जाता है, जो विस्तृत सत्र और/या ऑब्जेक्ट ऑडिट लॉगिंग प्रदान करता है। pgAudit द्वारा बनाया गया ऑडिट ट्रेल ऑडिट सेटिंग्स के आधार पर आकार में बहुत बड़ा हो सकता है, इसलिए यह तय करने के लिए सावधानी बरतनी चाहिए कि पहले से क्या और कितनी ऑडिटिंग की आवश्यकता है। निम्न अनुभाग में एक संक्षिप्त डेमो दिखाता है कि कैसे pgAudit को कॉन्फ़िगर किया जाता है और उपयोग में लाया जाता है।
लॉग ट्रेल पीजीडीएटीए/लॉग लोकेशन में पाए जाने वाले पोस्टग्रेएसक्यूएल डेटाबेस क्लस्टर लॉग के भीतर बनाया गया है लेकिन ऑडिट लॉग संदेशों को "ऑडिट:" लेबल के साथ जोड़ा जाता है ताकि नियमित डेटाबेस पृष्ठभूमि संदेशों और ऑडिट लॉग के बीच अंतर किया जा सके। रिकॉर्ड।
डेमो
pgAudit का आधिकारिक दस्तावेज बताता है कि PostgreSQL के प्रत्येक प्रमुख संस्करण के लिए pgAudit का एक अलग संस्करण मौजूद है ताकि प्रत्येक PostgreSQL रिलीज में पेश की गई नई कार्यक्षमता का समर्थन किया जा सके। इस डेमो में PostgreSQL का संस्करण 11 है, इसलिए pgAudit का संस्करण 1.3.X शाखा से होगा। pgaudit.log सेट किया जाने वाला मूलभूत पैरामीटर है जो नियंत्रित करता है कि किस वर्ग के कथन लॉग किए जाएंगे। इसे सत्र स्तर के लिए SET के साथ या विश्व स्तर पर लागू करने के लिए postgresql.conf फ़ाइल के भीतर सेट किया जा सकता है।
postgres=# set pgaudit.log = 'read, write, role, ddl, misc';
SET
cat $PGDATA/pgaudit.log
pgaudit.log = 'read, write, role, ddl, misc'
db_replica=# show pgaudit.log;
pgaudit.log
------------------------------
read, write, role, ddl, misc
(1 row)
2020-01-29 22:51:49.289 AEDT 4710 db_replica postgres [local] psql LOG: AUDIT: SESSION,3,1,MISC,SHOW,,,show pgaudit.log;,<not logged>
db_replica=# create table t1 (f1 integer, f2 varchar);
CREATE TABLE
2020-01-29 22:52:08.327 AEDT 4710 db_replica postgres [local] psql LOG: AUDIT: SESSION,4,1,DDL,CREATE TABLE,,,"create table t1 (f1 integer, f2 varchar);",<not logged>
db_replica=# insert into t1 values (1,'one');
INSERT 0 1
db_replica=# insert into t1 values (2,'two');
INSERT 0 1
db_replica=# insert into t1 values (3,'three');
INSERT 0 1
2020-01-29 22:52:19.261 AEDT 4710 db_replica postgres [local] psql LOG: AUDIT: SESSION,5,1,WRITE,INSERT,,,"insert into t1 values (1,'one');",<not logged>
20-01-29 22:52:38.145 AEDT 4710 db_replica postgres [local] psql LOG: AUDIT: SESSION,6,1,WRITE,INSERT,,,"insert into t1 values (2,'two');",<not logged>
2020-01-29 22:52:44.988 AEDT 4710 db_replica postgres [local] psql LOG: AUDIT: SESSION,7,1,WRITE,INSERT,,,"insert into t1 values (3,'three');",<not logged>
db_replica=# select * from t1 where f1 >= 2;
f1 | f2
----+-------
2 | two
3 | three
(2 rows)
2020-01-29 22:53:09.161 AEDT 4710 db_replica postgres [local] psql LOG: AUDIT: SESSION,9,1,READ,SELECT,,,select * from t1 where f1 >= 2;,<not logged>
db_replica=# grant select on t1 to usr_replica;
GRANT
2020-01-29 22:54:25.283 AEDT 4710 db_replica postgres [local] psql LOG: AUDIT: SESSION,13,1,ROLE,GRANT,,,grant select on t1 to usr_replica;,<not logged>
db_replica=# alter table t1 add f3 date;
ALTER TABLE
2020-01-29 22:55:17.440 AEDT 4710 db_replica postgres [local] psql LOG: AUDIT: SESSION,23,1,DDL,ALTER TABLE,,,alter table t1 add f3 date;,<not logged>
db_replica=# checkpoint;
CHECKPOINT
2020-01-29 22:55:50.349 AEDT 4710 db_replica postgres [local] psql LOG: AUDIT: SESSION,33,1,MISC,CHECKPOINT,,,checkpoint;,<not logged>
db_replica=# vacuum t1;
VACUUM
2020-01-29 22:56:03.007 AEDT 4710 db_replica postgres [local] psql LOG: AUDIT: SESSION,34,1,MISC,VACUUM,,,vacuum t1;,<not logged>
db_replica=# show log_statement;
log_statement
---------------
none
2020-01-29 22:56:14.740 AEDT 4710 db_replica postgres [local] psql LOG: AUDIT: SESSION,36,1,MISC,SHOW,,,show log_statement;,<not logged>लॉग प्रविष्टियां, जैसा कि ऊपर डेमो में दिखाया गया है, केवल सर्वर पृष्ठभूमि लॉगफाइल पर लिखी जाती हैं जब पैरामीटर log_statement सेट किया जाता है, हालांकि इस मामले में इसे कॉन्फ़िगर नहीं किया गया है लेकिन ऑडिट संदेश गुण द्वारा लिखे गए हैं pgaudit.log पैरामीटर जैसा कि डेमो में दिखाया गया है। PostgreSQL के भीतर आपके सभी डेटाबेस ऑडिटिंग आवश्यकताओं को पूरा करने के लिए अधिक शक्तिशाली विकल्प उपलब्ध हैं, जिन्हें यहां pgaudit के आधिकारिक दस्तावेज़ीकरण का पालन करके या github repository.pg_repack
पर कॉन्फ़िगर किया जा सकता है।यह कई PostgreSQL इंजीनियरों के बीच एक पसंदीदा एक्सटेंशन है जो सीधे PostgreSQL क्लस्टर के प्रबंधन और सामान्य स्वास्थ्य को बनाए रखने में शामिल हैं। इसके कारण पर थोड़ी देर बाद चर्चा की जाएगी लेकिन यह एक्सटेंशन एक PostgreSQL डेटाबेस के भीतर डेटाबेस ब्लोट को हटाने की कार्यक्षमता प्रदान करता है, जो कि बहुत बड़े PostgreSQL डेटाबेस समूहों के बीच चिंताजनक चिंताओं में से एक है, जिसके लिए डेटाबेस री-ऑर्ग की आवश्यकता होती है।
चूंकि PostgreSQL डेटाबेस निरंतर और भारी WRITES (अपडेट और डिलीट) से गुजरता है, पुराने डेटा को हटाए जाने के रूप में चिह्नित किया जाता है जबकि पंक्ति का नया संस्करण डाला जाता है, लेकिन पुराना डेटा वास्तव में एक से मिटाया नहीं जाता है डेटा ब्लॉक। इसके लिए वैक्यूमिंग नामक एक आवधिक रखरखाव ऑपरेशन की आवश्यकता होती है, जो एक स्वचालित प्रक्रिया है जो पृष्ठभूमि में निष्पादित होती है जो सभी "हटाए गए के रूप में चिह्नित" पंक्तियों को साफ़ करती है। इस प्रक्रिया को कभी-कभी बोलचाल की भाषा में कचरा संग्रहण कहा जाता है।
वैक्यूमिंग प्रक्रिया आम तौर पर व्यस्त समय के दौरान डेटाबेस संचालन के लिए रास्ता देती है। डेटाबेस संचालन के पक्ष में वैक्यूमिंग के कम से कम प्रतिबंधात्मक तरीके से बड़ी संख्या में "हटाए गए के रूप में चिह्नित" पंक्तियों का परिणाम होता है, जिससे डेटाबेस "डेटाबेस ब्लोट" के रूप में संदर्भित अनुपात से बाहर हो जाते हैं। VACUUM FULL नामक एक सशक्त वैक्यूमिंग प्रक्रिया है, लेकिन इसके परिणामस्वरूप संसाधित होने वाले डेटाबेस ऑब्जेक्ट पर एक विशेष लॉक प्राप्त होता है, जिससे उस ऑब्जेक्ट पर डेटाबेस संचालन रुक जाता है।
pg_repack
इस कारण से pg_repack PostgreSQL DBA और इंजीनियरों के बीच एक हिट है, क्योंकि यह एक सामान्य वैक्यूमिंग प्रक्रिया का काम करता है लेकिन डेटाबेस पर एक विशेष लॉक प्राप्त न करके VACUUM FULL की दक्षता प्रदान करता है। वस्तु, संक्षेप में, यह ऑनलाइन काम करता है। यहां आधिकारिक दस्तावेज डेटाबेस को पुनर्गठित करने के अन्य तरीकों के बारे में अधिक बताते हैं लेकिन नीचे दिए गए एक त्वरित डेमो चीजों को बेहतर ढंग से समझने के लिए उचित प्रकाश में रखेगा। एक आवश्यकता है कि लक्ष्य तालिका में प्राथमिक कुंजी के रूप में परिभाषित कम से कम एक स्तंभ होना चाहिए, जो कि अधिकांश उत्पादन डेटाबेस सेटअप में एक सामान्य मानदंड है।
डेमो
मूल डेमो एक परीक्षण वातावरण में pg_repack की स्थापना और उपयोग को दर्शाता है। यह डेमो pg_repack के संस्करण 1.4.5 का उपयोग करता है जो इस ब्लॉग को प्रकाशित करते समय इस एक्सटेंशन का नवीनतम संस्करण है। एक डेमो टेबल t1 में शुरू में 80000 पंक्तियाँ होती हैं जो डिलीट के बड़े पैमाने पर ऑपरेशन से गुजरती हैं, जो टेबल की हर 5 वीं पंक्ति को हटा देती है। pg_repack का निष्पादन पहले और बाद में तालिका का आकार दिखाता है।
mydb=# CREATE EXTENSION pg_repack;
CREATE EXTENSION
mydb=# create table t1 (no integer primary key, f_name VARCHAR(20), l_name VARCHAR(20), d_o_b date);
CREATE TABLE
mydb=# insert into t1 (select generate_series(1,1000000,1),'a'||
mydb(# generate_series(1,1000000,1),'a'||generate_series(1000000,1,-1),
mydb(# cast( now() - '1 year'::interval * random() as date ));
INSERT 0 1000000
mydb=# SELECT pg_size_pretty( pg_total_relation_size('t1'));
pg_size_pretty
----------------
71 MB
(1 row)
mydb=# CREATE or replace FUNCTION delete5() RETURNS void AS $$
mydb$# declare
mydb$# counter integer := 0;
mydb$# BEGIN
mydb$#
mydb$# while counter <= 1000000
mydb$# loop
mydb$# delete from t1 where no=counter;
mydb$# counter := counter + 5;
mydb$# END LOOP;
mydb$# END;
mydb$# $$ LANGUAGE plpgsql;
CREATE FUNCTIONडिलीट5 फ़ंक्शन एक काउंटर का उपयोग करके t1 तालिका से 200000 पंक्तियों को हटा देता है जो 5 की गिनती बढ़ाता है
mydb=# select delete5();
delete5
------
(1 row)
mydb=# SELECT pg_size_pretty( pg_total_relation_size('t1'));
pg_size_pretty
----------------
71 MB
(1 row)
$ pg_repack -t t1 -N -n -d mydb -p 5433
INFO: Dry run enabled, not executing repack
INFO: repacking table "public.t1"
$ pg_repack -t t1 -n -d mydb -p 5433
INFO: repacking table "public.t1"
mydb=# SELECT pg_size_pretty( pg_total_relation_size('t1'));
pg_size_pretty
----------------
57 MB
(1 row)जैसा कि ऊपर दिखाया गया है, डिलीट5 फ़ंक्शन को निष्पादित करने के बाद तालिका का मूल आकार नहीं बदलता है, जो दर्शाता है कि तालिका में पंक्तियाँ अभी भी मौजूद हैं। pg_repack का निष्पादन t1 तालिका से उन 'हटाए गए के रूप में चिह्नित' पंक्तियों को साफ़ करता है जो t1 तालिका के आकार को घटाकर 57 एमबी कर देता है। pg_repack के बारे में एक और अच्छी बात -N फ्लैग के साथ ड्राई रन का विकल्प है, जिसके उपयोग से आप यह जांच सकते हैं कि वास्तविक रन के दौरान क्या निष्पादित किया जाएगा।
HypoPG
अगला दिलचस्प एक्सटेंशन मालिकाना डेटाबेस सर्वर के बीच अदृश्य इंडेक्स नामक एक लोकप्रिय अवधारणा के समान है। हाइपोपीजी एक्सटेंशन एक डीबीए को एक काल्पनिक सूचकांक (जो मौजूद नहीं है) को शुरू करने के प्रभाव को देखने में सक्षम बनाता है और क्या यह एक या अधिक प्रश्नों के प्रदर्शन में सुधार करेगा, और इसलिए इसका नाम हाइपोपीजी है।
एक काल्पनिक सूचकांक के निर्माण के लिए किसी सीपीयू या डिस्क संसाधनों की आवश्यकता नहीं होती है, हालांकि, यह एक कनेक्शन की निजी मेमोरी का उपभोग करता है। चूंकि काल्पनिक सूचकांक किसी भी डेटाबेस कैटलॉग टेबल में संग्रहीत नहीं होता है, इसलिए टेबल ब्लोट का कोई प्रभाव नहीं पड़ता है। यह इस कारण से है कि एक काल्पनिक सूचकांक का उपयोग एक व्याख्यात्मक विश्लेषण विवरण में नहीं किया जा सकता है, जबकि एक सादा व्याख्या यह आकलन करने का एक अच्छा तरीका है कि क्या किसी समस्यात्मक क्वेरी द्वारा संभावित सूचकांक का उपयोग किया जाएगा। हाइपोपीजी कैसे काम करता है, यह समझाने के लिए यहां एक त्वरित डेमो दिया गया है।
डेमो
मैं Generate_series का उपयोग करके 100000 पंक्तियों वाली एक तालिका बनाने जा रहा हूं और काल्पनिक अनुक्रमणिका के साथ और बिना लागत अनुमानों में अंतर दिखाने के लिए कुछ सरल प्रश्नों को निष्पादित करता हूं।
olap=# CREATE EXTENSION hypopg;
CREATE EXTENSION
olap=# CREATE TABLE stock (id integer, line text);
CREATE TABLE
olap=# INSERT INTO stock SELECT i, 'line ' || i FROM generate_series(1, 100000) i;
INSERT 0 100000
olap=# ANALYZE STOCK;
ANALYZE
olap=# EXPLAIN SELECT line FROM stock WHERE id = 1;
QUERY PLAN
---------------------------------------------------------
Seq Scan on stock (cost=0.00..1791.00 rows=1 width=10)
Filter: (id = 1)
(2 rows)
olap=# SELECT * FROM hypopg_create_index('CREATE INDEX ON stock (id)') ;
indexrelid | indexname
------------+-----------------------
25398 | <25398>btree_stock_id
(1 row)
olap=# EXPLAIN SELECT line FROM stock WHERE id = 1;
QUERY PLAN
------------------------------------------------------------------------------------
Index Scan using <25398>btree_stock_id on stock (cost=0.04..8.06 rows=1 width=10)
Index Cond: (id = 1)
(2 rows)
olap=# EXPLAIN ANALYZE SELECT line FROM stock WHERE id = 1;
QUERY PLAN
----------------------------------------------------------------------------------------------------
Seq Scan on stock (cost=0.00..1791.00 rows=1 width=10) (actual time=0.028..41.877 rows=1 loops=1)
Filter: (id = 1)
Rows Removed by Filter: 99999
Planning time: 0.057 ms
Execution time: 41.902 ms
(5 rows)
olap=# SELECT indexname, pg_size_pretty(hypopg_relation_size(indexrelid))
olap-# FROM hypopg_list_indexes() ;
indexname | pg_size_pretty
-----------------------+----------------
<25398>btree_stock_id | 2544 kB
(1 row)
olap=# SELECT pg_size_pretty(pg_relation_size('stock'));
pg_size_pretty
----------------
4328 kB
(1 row)उपरोक्त प्रदर्शनी दर्शाती है कि कैसे एक साधारण क्वेरी को अनुकूलित करने के लिए तालिका के "id" फ़ील्ड में एक इंडेक्स जोड़कर अनुमानित कुल लागत को 1791 से घटाकर 8.06 किया जा सकता है। यह यह भी साबित करता है कि जब क्वेरी को EXPLAIN ANALYZE के साथ निष्पादित किया जाता है तो इंडेक्स का वास्तव में उपयोग नहीं किया जाता है जो वास्तविक समय में क्वेरी को निष्पादित करता है। एक्सटेंशन के hypopg_list_indexes फ़ंक्शन का उपयोग करके यह पता लगाने का एक तरीका भी है कि इंडेक्स कितना डिस्क स्थान घेरता है।
हाइपोपीजी के पास काल्पनिक अनुक्रमणिका को प्रबंधित करने के लिए कुछ अन्य कार्य हैं और इसके अलावा, यह यह पता लगाने का एक तरीका भी प्रदान करता है कि क्या किसी तालिका को विभाजित करने से बड़े डेटासेट प्राप्त करने वाले प्रश्नों के प्रदर्शन में सुधार होगा। हाइपोपीजी एक्सटेंशन का एक काल्पनिक विभाजन विकल्प है और इसके अधिक का पालन आधिकारिक दस्तावेज के संदर्भ में किया जा सकता है।
निष्कर्ष
जैसा कि पहले भाग में बताया गया है, PostgreSQL पिछले कुछ वर्षों में विकसित हुआ है, केवल मूल स्रोत कोड के साथ-साथ प्लग एंड प्ले एक्सटेंशन दोनों में तेजी से विकास के साथ बड़ा, बेहतर और तेज होता जा रहा है। नए पोस्टग्रेएसक्यूएल का एक खुला स्रोत संस्करण उन आईटी दुकानों के लिए सबसे उपयुक्त हो सकता है जो अपने आईटी कैपेक्स और ओपेक्स को कम करने के लिए प्रमुख स्वामित्व डेटाबेस सर्वरों में से एक चला रहे हैं।
बहुत सारे PostgreSQL एक्सटेंशन हैं जो निगरानी से लेकर उच्च-उपलब्धता तक और स्केलिंग से लेकर बाइनरी डेटाफाइल्स को मानव पठनीय प्रारूप में डंप करने तक की सुविधाएँ प्रदान करते हैं। यह आशा की जाती है कि उपरोक्त प्रदर्शनों ने पोस्टग्रेएसक्यूएल डेटाबेस की अधिकतम क्षमता और शक्ति पर भारी प्रकाश डाला है।
