PostgreSQL के लिए एक प्रदर्शन धोखा पत्र

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

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

व्याख्या करें

हमारे डेटाबेस के प्रदर्शन को बेहतर बनाने के तरीके को समझने के लिए हम जो पहला कदम उठा सकते हैं, उनमें से एक यह है कि किए गए प्रश्नों का विश्लेषण किया जाए।

PostgreSQL इसे प्राप्त होने वाली प्रत्येक क्वेरी के लिए एक क्वेरी योजना तैयार करता है। इस योजना को देखने के लिए, हम EXPLAIN का उपयोग करेंगे।

क्वेरी प्लान की संरचना प्लान नोड्स का एक ट्री है। पेड़ के निचले स्तर में नोड्स स्कैन नोड्स हैं। वे एक टेबल से कच्ची पंक्तियां लौटाते हैं। तालिका तक पहुँचने के विभिन्न तरीकों के लिए विभिन्न प्रकार के स्कैन नोड हैं। EXPLAIN आउटपुट में प्लान ट्री में प्रत्येक नोड के लिए एक लाइन होती है।

world=# EXPLAIN SELECT * FROM city t1,country t2 WHERE id>100 AND t1.population>700000 AND t2.population<7000000;
                               QUERY PLAN                                
--------------------------------------------------------------------------
Nested Loop  (cost=0.00..734.81 rows=50662 width=144)
  ->  Seq Scan on city t1  (cost=0.00..93.19 rows=347 width=31)
        Filter: ((id > 100) AND (population > 700000))
  ->  Materialize  (cost=0.00..8.72 rows=146 width=113)
        ->  Seq Scan on country t2  (cost=0.00..7.99 rows=146 width=113)
              Filter: (population < 7000000)
(6 rows)

यह कमांड दिखाता है कि हमारी क्वेरी में टेबल्स को कैसे स्कैन किया जाएगा। आइए देखें कि ये मूल्य क्या हैं जो हम अपने EXPLAIN में देख सकते हैं।

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

प्रदर्शन का सबसे महत्वपूर्ण हिस्सा अनुमानित विवरण निष्पादन लागत है, जो योजनाकार का अनुमान है कि विवरण को चलाने में कितना समय लगेगा। तुलना करते समय एक प्रश्न दूसरे के खिलाफ कितना प्रभावी है, हम व्यवहार में उनके लागत मूल्यों की तुलना करेंगे।

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

लागत को योजनाकार के लागत मापदंडों द्वारा निर्धारित मनमानी इकाइयों में मापा जाता है। पारंपरिक प्रथा डिस्क पेज फ़ेच की इकाइयों में लागत को मापने के लिए है; यानी, seq_page_cost पारंपरिक रूप से 1.0 पर सेट है और अन्य लागत पैरामीटर उसके सापेक्ष सेट किए गए हैं।

विश्लेषण करें

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

आइए इस टूल के उपयोग का एक उदाहरण देखें।

world=# EXPLAIN ANALYZE SELECT * FROM city t1,country t2 WHERE id>100 AND t1.population>700000 AND t2.population<7000000;
                                                     QUERY PLAN                                                      
----------------------------------------------------------------------------------------------------------------------
Nested Loop  (cost=0.00..734.81 rows=50662 width=144) (actual time=0.081..22.066 rows=51100 loops=1)
  ->  Seq Scan on city t1  (cost=0.00..93.19 rows=347 width=31) (actual time=0.069..0.618 rows=350 loops=1)
        Filter: ((id > 100) AND (population > 700000))
        Rows Removed by Filter: 3729
  ->  Materialize  (cost=0.00..8.72 rows=146 width=113) (actual time=0.000..0.011 rows=146 loops=350)
        ->  Seq Scan on country t2  (cost=0.00..7.99 rows=146 width=113) (actual time=0.007..0.058 rows=146 loops=1)
              Filter: (population < 7000000)
              Rows Removed by Filter: 93
Planning time: 0.136 ms
Execution time: 24.627 ms
(10 rows)

यदि हमें इस कारण का पता नहीं चलता है कि हमारे प्रश्नों में उनकी अपेक्षा से अधिक समय क्यों लगता है, तो हम अधिक जानकारी के लिए इस ब्लॉग को देख सकते हैं।

वैक्यूम

VACUUM प्रक्रिया डेटाबेस के भीतर कई रखरखाव कार्यों के लिए जिम्मेदार है, उनमें से एक मृत टुपल्स द्वारा कब्जा किए गए भंडारण को पुनर्प्राप्त करना है। PostgreSQL के सामान्य संचालन में, अद्यतन द्वारा हटाए गए या अप्रचलित टुपल्स को उनकी तालिका से भौतिक रूप से हटाया नहीं जाता है; वे तब तक मौजूद रहते हैं जब तक VACUUM का प्रदर्शन नहीं किया जाता। इसलिए, VACUUM को समय-समय पर करना आवश्यक है, विशेष रूप से बार-बार अद्यतन की जाने वाली तालिकाओं में।

यदि वैक्यूम बहुत अधिक समय या संसाधन ले रहा है, तो इसका मतलब है कि हमें इसे और अधिक बार करना चाहिए, ताकि प्रत्येक ऑपरेशन में सफाई के लिए कम हो।

किसी भी स्थिति में आपको VACUUM को अक्षम करने की आवश्यकता हो सकती है, उदाहरण के लिए बड़ी मात्रा में डेटा लोड करते समय।

VACUUM बस स्थान को पुनः प्राप्त करता है और इसे पुन:उपयोग के लिए उपलब्ध कराता है। कमांड का यह रूप तालिका के सामान्य पढ़ने और लिखने के समानांतर काम कर सकता है, क्योंकि एक विशेष लॉक प्राप्त नहीं होता है। हालांकि, अतिरिक्त स्थान ऑपरेटिंग सिस्टम (ज्यादातर मामलों में) में वापस नहीं किया जाता है; यह केवल उसी तालिका में पुन:उपयोग के लिए उपलब्ध है।

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

VACUUM ANALYZE प्रत्येक चयनित तालिका के लिए एक VACUUM और फिर एक ANALYZE करता है। यह नियमित रखरखाव स्क्रिप्ट के संयोजन का एक व्यावहारिक तरीका है।

ANALYZE डेटाबेस में तालिकाओं की सामग्री पर आंकड़े एकत्र करता है और परिणामों को pg_statistic में संग्रहीत करता है। इसके बाद, क्वेरी प्लानर इन आँकड़ों का उपयोग प्रश्नों के लिए सबसे कुशल निष्पादन योजनाओं को निर्धारित करने में मदद के लिए करता है।

कॉन्फ़िगरेशन पैरामीटर

इन मापदंडों को संशोधित करने के लिए हमें $ PGDATA / postgresql.conf फ़ाइल को संपादित करना होगा। हमें यह ध्यान में रखना चाहिए कि उनमें से कुछ को हमारे डेटाबेस को फिर से शुरू करने की आवश्यकता है।

अधिकतम_कनेक्शन

हमारे डेटाबेस में एक साथ कनेक्शन की अधिकतम संख्या निर्धारित करता है। ऐसे मेमोरी संसाधन हैं जिन्हें प्रति क्लाइंट कॉन्फ़िगर किया जा सकता है, इसलिए अधिकतम संख्या में क्लाइंट उपयोग की गई मेमोरी की अधिकतम मात्रा का सुझाव दे सकते हैं।

superuser_reserved_connections

max_connection की सीमा तक पहुँचने के मामले में, ये कनेक्शन सुपरयूज़र के लिए आरक्षित हैं।

साझा_बफ़र

साझा मेमोरी बफ़र्स के लिए डेटाबेस सर्वर द्वारा उपयोग की जाने वाली मेमोरी की मात्रा सेट करता है। यदि आपके पास 1 GB या अधिक RAM वाला एक समर्पित डेटाबेस सर्वर है, तो Shared_buffers के लिए एक उचित प्रारंभिक मान आपके सिस्टम की मेमोरी का 25% है। Shared_buffers के लिए बड़े कॉन्फ़िगरेशन के लिए आम तौर पर max_wal_size में एक समान वृद्धि की आवश्यकता होती है, ताकि लंबी अवधि में बड़ी मात्रा में नए या संशोधित डेटा लिखने की प्रक्रिया का विस्तार किया जा सके।

temp_buffers

प्रत्येक सत्र के लिए उपयोग किए जाने वाले अस्थायी बफ़र्स की अधिकतम संख्या निर्धारित करता है। ये स्थानीय सत्र बफ़र हैं जिनका उपयोग केवल अस्थायी तालिकाओं तक पहुँचने के लिए किया जाता है। एक सत्र अस्थायी बफ़र्स को आवश्यकतानुसार temp_buffers द्वारा दी गई सीमा तक असाइन करेगा।

work_mem

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

PostgreSQL के पुराने संस्करणों में इस विकल्प को Sort_mem कहा जाता था।

रखरखाव_कार्य_मेम

मेमोरी की अधिकतम मात्रा निर्दिष्ट करता है जो रखरखाव संचालन उपयोग करेगा, जैसे कि VACUUM, CREATE INDEX, और ALTER TABLE ADD FOREIGN KEY। चूंकि इनमें से केवल एक ऑपरेशन एक ही समय में एक सत्र द्वारा निष्पादित किया जा सकता है, और एक इंस्टॉलेशन में आमतौर पर उनमें से कई एक साथ नहीं चलते हैं, यह वर्क_मेम से बड़ा हो सकता है। बड़े कॉन्फ़िगरेशन VACUUM और डेटाबेस पुनर्स्थापना के लिए प्रदर्शन में सुधार कर सकते हैं।

जब ऑटोवैक्यूम निष्पादित किया जाता है, तो इस मेमोरी को कई बार ऑटोवैक्यूम_मैक्स_वर्कर्स पैरामीटर कॉन्फ़िगर किया जा सकता है, इसलिए हमें इसे ध्यान में रखना चाहिए, या अन्यथा, इसे अलग से प्रबंधित करने के लिए ऑटोवैक्यूम_वर्क_मेम पैरामीटर को कॉन्फ़िगर करें।

fsync

यदि fsync सक्षम है, तो PostgreSQL यह सुनिश्चित करने का प्रयास करेगा कि अद्यतन डिस्क पर भौतिक रूप से लिखे गए हैं। यह सुनिश्चित करता है कि ऑपरेटिंग सिस्टम या हार्डवेयर क्रैश के बाद डेटाबेस क्लस्टर को एक सुसंगत स्थिति में वापस लाया जा सकता है।

Fsync को अक्षम करने से आम तौर पर प्रदर्शन में सुधार होता है, यह बिजली की विफलता या सिस्टम क्रैश की स्थिति में डेटा हानि का कारण बन सकता है। इसलिए, fsync को निष्क्रिय करने की सलाह तभी दी जाती है जब आप बाहरी डेटा से अपने संपूर्ण डेटाबेस को आसानी से फिर से बना सकें।

checkpoint_segments (PostgreSQL <9.5)

स्वचालित WAL नियंत्रण बिंदुओं के बीच रिकॉर्ड फ़ाइल खंडों की अधिकतम संख्या (प्रत्येक खंड सामान्य रूप से 16 मेगाबाइट है)। इस पैरामीटर को बढ़ाने से दोषों को ठीक करने के लिए आवश्यक समय की मात्रा बढ़ सकती है। बहुत अधिक ट्रैफ़िक वाले सिस्टम में, यदि इसे बहुत कम मान पर सेट किया जाता है, तो यह प्रदर्शन को प्रभावित कर सकता है। कई डेटा संशोधनों के साथ सिस्टम पर checkpoint_segments का मान बढ़ाने की अनुशंसा की जाती है।

साथ ही, WAL फ़ाइलों को PGDATA के अलावा किसी अन्य डिस्क पर सहेजना एक अच्छा अभ्यास है। यह लेखन संतुलन और हार्डवेयर विफलता के मामले में सुरक्षा दोनों के लिए उपयोगी है।

PostgreSQL 9.5 के अनुसार कॉन्फ़िगरेशन चर "checkpoint_segments" को हटा दिया गया था, और इसे "max_wal_size" और "min_wal_size" द्वारा बदल दिया गया था

max_wal_size (PostgreSQL>=9.5)

अधिकतम आकार WAL को नियंत्रण बिंदुओं के बीच बढ़ने की अनुमति है। विशेष परिस्थितियों में WAL का आकार max_wal_size से अधिक हो सकता है। इस पैरामीटर को बढ़ाने से दोषों को ठीक करने के लिए आवश्यक समय की मात्रा बढ़ सकती है।

min_wal_size (PostgreSQL>=9.5)

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

wal_sync_method

डिस्क पर WAL अद्यतनों को बाध्य करने के लिए प्रयुक्त विधि। अगर fsync अक्षम है, तो इस सेटिंग का कोई प्रभाव नहीं पड़ता है।

wal_buffers

WAL डेटा के लिए उपयोग की गई साझा मेमोरी की मात्रा जो अभी तक डिस्क पर नहीं लिखी गई है। डिफ़ॉल्ट सेटिंग शेयर्ड_बफ़र्स का लगभग 3% है, जो 64KB से कम या WAL सेगमेंट (आमतौर पर 16MB) के आकार से अधिक नहीं है। इस मान को कम से कम कुछ एमबी पर सेट करने से कई समवर्ती लेनदेन वाले सर्वर पर लेखन प्रदर्शन में सुधार हो सकता है।

प्रभावी_कैश_आकार

इस मान का उपयोग क्वेरी प्लानर द्वारा उन योजनाओं को ध्यान में रखने के लिए किया जाता है जो स्मृति में फिट हो भी सकती हैं और नहीं भी। इसे एक सूचकांक का उपयोग करने के लागत अनुमानों में ध्यान में रखा जाता है; एक उच्च मूल्य यह अधिक संभावना बनाता है कि सूचकांक स्कैन का उपयोग किया जाता है और कम मूल्य यह अधिक संभावना बनाता है कि अनुक्रमिक स्कैन का उपयोग किया जाएगा। एक उचित मूल्य RAM का 50% होगा।

default_statistics_target

PostgreSQL अपने डेटाबेस में प्रत्येक तालिका से आंकड़े एकत्र करता है ताकि यह तय किया जा सके कि उन पर प्रश्नों को कैसे निष्पादित किया जाएगा। डिफ़ॉल्ट रूप से, यह बहुत अधिक जानकारी एकत्र नहीं करता है, और यदि आपको अच्छी निष्पादन योजनाएँ नहीं मिल रही हैं, तो आपको इस मान को बढ़ाना चाहिए और फिर डेटाबेस में ANALYZE को फिर से चलाना चाहिए (या AUTOVACUUM की प्रतीक्षा करें)।

सिंक्रोनस_प्रतिबद्ध

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

लॉगिंग

लॉग करने के लिए कई प्रकार के डेटा हैं जो उपयोगी हो सकते हैं या नहीं। आइए उनमें से कुछ देखें:

• log_min_error_statement:न्यूनतम लॉगिंग स्तर सेट करता है।
• log_min_duration_statement:सिस्टम में धीमी क्वेरी को रिकॉर्ड करने के लिए उपयोग किया जाता है।
• log_line_prefix:प्रत्येक लॉग लाइन की शुरुआत में जानकारी का पालन करता है।
• log_statement:आप कोई नहीं, डीडीएल, एमओडी, सभी के बीच चयन कर सकते हैं। "सभी" का उपयोग करने से प्रदर्शन संबंधी समस्याएं हो सकती हैं।

डिज़ाइन

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

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

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

हार्डवेयर

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

• मेमोरी:हमारे पास जितनी अधिक रैम होगी, उतना ही अधिक मेमोरी डेटा हम संभाल सकते हैं, और इसका मतलब है कि बेहतर प्रदर्शन। डिस्क पर लिखने और पढ़ने की गति मेमोरी की तुलना में बहुत धीमी होती है, इसलिए, हमारे पास जितनी अधिक जानकारी होगी, हमारे पास उतना ही बेहतर प्रदर्शन होगा।
• CPU:शायद यह कहने का ज्यादा मतलब नहीं है, लेकिन हमारे पास जितना अधिक CPU होगा, उतना अच्छा होगा। किसी भी मामले में यह हार्डवेयर के मामले में सबसे महत्वपूर्ण नहीं है, लेकिन अगर हमारे पास एक अच्छा सीपीयू हो, तो हमारी प्रोसेसिंग क्षमता में सुधार होगा और यह सीधे हमारे डेटाबेस को प्रभावित करता है।
• हार्ड डिस्क:हमारे पास कई प्रकार की डिस्क हैं जिनका हम उपयोग कर सकते हैं, SCSI, SATA, SAS, IDE। हमारे पास सॉलिड स्टेट डिस्क भी हैं। हमें गुणवत्ता / कीमत की तुलना करनी चाहिए, जिसका उपयोग हमें इसकी गति की तुलना करने के लिए करना चाहिए। लेकिन डिस्क का प्रकार केवल विचार करने वाली चीज नहीं है, हमें यह भी देखना होगा कि उन्हें कैसे कॉन्फ़िगर किया जाए। यदि हम अच्छा प्रदर्शन चाहते हैं, तो हम RAID10 का उपयोग कर सकते हैं, WALs को RAID के बाहर किसी अन्य डिस्क पर रखते हुए। RAID5 का उपयोग करने की अनुशंसा नहीं की जाती है क्योंकि डेटाबेस के लिए इस प्रकार के RAID का प्रदर्शन अच्छा नहीं है।

निष्कर्ष

इस ब्लॉग में उल्लिखित बिंदुओं को ध्यान में रखते हुए, हम डेटाबेस के व्यवहार को सत्यापित करने के लिए एक बेंचमार्क निष्पादित कर सकते हैं।

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

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