PostgreSQL आणि JDBC सर्व रस पिळून काढतात. व्लादिमीर सिटनिकोव्ह

मी सुचवितो की तुम्ही व्लादिमीर सिटनिकोव्हच्या 2016 च्या सुरुवातीच्या अहवालाचा उतारा वाचा “PostgreSQL आणि JDBC सर्व रस पिळून काढत आहेत”

शुभ दुपार माझे नाव व्लादिमीर सिटनिकोव्ह आहे. मी 10 वर्षांपासून NetCracker साठी काम करत आहे. आणि मी मुख्यतः उत्पादकता मध्ये आहे. Java शी संबंधित प्रत्येक गोष्ट, SQL शी संबंधित प्रत्येक गोष्ट मला आवडते.

आणि जेव्हा आम्ही डेटाबेस सर्व्हर म्हणून PostgreSQL वापरण्यास सुरुवात केली तेव्हा कंपनीमध्ये आम्ही काय अनुभवले याबद्दल मी आज बोलेन. आणि आम्ही बहुतेक Java सह काम करतो. पण आज मी तुम्हाला जे सांगणार आहे ते फक्त Java बद्दल नाही. सराव दर्शविल्याप्रमाणे, हे इतर भाषांमध्ये देखील आढळते.

आपण बोलू:

• डेटा सॅम्पलिंग बद्दल.
• डेटा जतन करण्याबद्दल.
• आणि कामगिरीबद्दल देखील.
• आणि तेथे दफन केलेल्या पाण्याखालील रेकबद्दल.

चला एका साध्या प्रश्नाने सुरुवात करूया. आम्ही प्राथमिक कीच्या आधारे टेबलमधून एक पंक्ती निवडतो.

डेटाबेस त्याच होस्टवर स्थित आहे. आणि या सर्व शेतीला 20 मिलिसेकंद लागतात.

हे 20 मिलीसेकंद खूप आहेत. जर तुमच्याकडे अशा 100 विनंत्या असतील, तर तुम्ही या विनंत्यांमधून प्रति सेकंद स्क्रोल करण्यात वेळ घालवता, म्हणजे आम्ही वेळ वाया घालवत आहोत.

आम्हाला हे करायला आवडत नाही आणि बेस आम्हाला यासाठी काय ऑफर करतो ते पहा. डेटाबेस आम्हाला क्वेरी कार्यान्वित करण्यासाठी दोन पर्याय देते.

पहिला पर्याय म्हणजे एक साधी विनंती. त्यात चांगले काय आहे? खरं म्हणजे आम्ही ते घेतो आणि पाठवतो आणि आणखी काही नाही.

https://github.com/pgjdbc/pgjdbc/pull/478

डेटाबेसमध्ये प्रगत क्वेरी देखील आहे, जी अधिक अवघड आहे, परंतु अधिक कार्यक्षम आहे. तुम्ही स्वतंत्रपणे पार्सिंग, एक्झिक्युशन, व्हेरिएबल बाइंडिंग इत्यादीसाठी विनंती पाठवू शकता.

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

आणि आपण काय करू शकतो साधी क्वेरी आणि विस्तारित क्वेरी.

प्रत्येक पध्दतीमध्ये विशेष काय आहे?

एक-वेळच्या अंमलबजावणीसाठी एक साधी क्वेरी चांगली आहे. एकदा केले आणि विसरले. आणि समस्या अशी आहे की ते बायनरी डेटा फॉरमॅटला सपोर्ट करत नाही, म्हणजे ते काही उच्च-कार्यक्षमता प्रणालींसाठी योग्य नाही.

विस्तारित क्वेरी - तुम्हाला पार्सिंगवर वेळ वाचविण्यास अनुमती देते. हे आम्ही केले आणि वापरण्यास सुरुवात केली. हे खरोखर, खरोखर आम्हाला मदत केली. केवळ पार्सिंगवर बचत होत नाही. डेटा ट्रान्सफरवर बचत होते. बायनरी स्वरूपात डेटा हस्तांतरित करणे अधिक कार्यक्षम आहे.

चला सरावाकडे वळूया. हे एक सामान्य अनुप्रयोग असे दिसते. हे जावा इत्यादी असू शकते.

आम्ही विधान तयार केले. आदेशाची अंमलबजावणी केली. जवळ तयार केले. इथे चूक कुठे आहे? काय अडचण आहे? हरकत नाही. सर्व पुस्तकांमध्ये हेच सांगितले आहे. हे असेच लिहावे. तुम्हाला जास्तीत जास्त कामगिरी हवी असेल तर असे लिहा.

परंतु सरावाने दर्शविले आहे की हे कार्य करत नाही. का? कारण आपल्याकडे ‘क्लोज’ पद्धत आहे. आणि जेव्हा आपण हे करतो, तेव्हा डेटाबेसच्या दृष्टिकोनातून असे दिसून येते की हे डेटाबेससह काम करणाऱ्या धूम्रपानासारखे आहे. आम्ही "पार्स एक्झिक्यूट डिललोकेट" म्हणालो.

ही सर्व अतिरिक्त निर्मिती आणि विधानांची उतराई का? कोणालाही त्यांची गरज नाही. परंतु प्रीपेर्ड स्टेटमेंट्समध्ये जे घडते ते म्हणजे जेव्हा आपण ते बंद करतो तेव्हा ते डेटाबेसवरील सर्व काही बंद करतात. हे आपल्याला हवे आहे असे नाही.

आम्हाला निरोगी लोकांप्रमाणे बेससह काम करायचे आहे. आम्ही आमचे विधान एकदा घेतले आणि तयार केले, नंतर आम्ही ते अनेक वेळा कार्यान्वित केले. खरं तर, बर्याच वेळा - हे अनुप्रयोगांच्या संपूर्ण आयुष्यात एकदाच आहे - ते विश्लेषित केले गेले आहेत. आणि आम्ही वेगवेगळ्या RESTs वर समान स्टेटमेंट आयडी वापरतो. हे आमचे ध्येय आहे.

आपण हे कसे साध्य करू शकतो?

हे अगदी सोपे आहे - विधाने बंद करण्याची आवश्यकता नाही. आम्ही ते असे लिहितो: “तयार करा” “कार्यान्वीत करा”.

जर आपण असे काहीतरी लॉन्च केले तर हे स्पष्ट आहे की काहीतरी कुठेतरी ओव्हरफ्लो होईल. ते स्पष्ट नसल्यास, तुम्ही ते वापरून पाहू शकता. ही सोपी पद्धत वापरणारा बेंचमार्क लिहू. विधान तयार करा. आम्ही ते ड्रायव्हरच्या काही आवृत्तीवर लाँच करतो आणि लक्षात आले की ते त्वरीत क्रॅश होते आणि त्यात असलेली सर्व मेमरी नष्ट होते.

हे स्पष्ट आहे की अशा त्रुटी सहजपणे दुरुस्त केल्या जातात. मी त्यांच्याबद्दल बोलणार नाही. परंतु मी म्हणेन की नवीन आवृत्ती खूप वेगाने कार्य करते. पद्धत मूर्ख आहे, परंतु तरीही.

योग्यरित्या कसे कार्य करावे? यासाठी आपल्याला काय करावे लागेल?

प्रत्यक्षात, अनुप्रयोग नेहमी विधाने बंद करतात. सर्व पुस्तकांमध्ये ते म्हणतात ते बंद करा, नाहीतर मेमरी लीक होईल.

आणि PostgreSQL ला प्रश्न कसे कॅशे करायचे हे माहित नाही. प्रत्येक सत्राने स्वतःसाठी ही कॅशे तयार करणे आवश्यक आहे.

आणि आम्ही पार्सिंग करण्यात वेळ वाया घालवू इच्छित नाही.

आणि नेहमीप्रमाणे आमच्याकडे दोन पर्याय आहेत.

पहिला पर्याय म्हणजे आम्ही ते घेतो आणि म्हणतो की PgSQL मध्ये सर्वकाही गुंडाळा. तेथे एक कॅशे आहे. ते सर्वकाही कॅश करते. तो उत्तम बाहेर चालू होईल. आम्ही हे पाहिले. आमच्याकडे 100500 विनंत्या आहेत. काम करत नाही. विनंत्यांना मॅन्युअली प्रक्रियांमध्ये बदलण्यास आम्ही सहमत नाही. नाही, नाही.

आमच्याकडे दुसरा पर्याय आहे - ते घ्या आणि ते स्वतःच कापून टाका. आम्ही स्त्रोत उघडतो आणि कटिंग सुरू करतो. आम्ही पाहिले आणि पाहिले. असे दिसून आले की हे करणे इतके अवघड नाही.

https://github.com/pgjdbc/pgjdbc/pull/319

हे ऑगस्ट 2015 मध्ये दिसून आले. आता एक अधिक आधुनिक आवृत्ती आहे. आणि सर्व काही छान आहे. हे इतके चांगले कार्य करते की आम्ही अनुप्रयोगात काहीही बदलत नाही. आणि आम्ही PgSQL च्या दिशेने विचार करणे देखील थांबवले, म्हणजे आमच्यासाठी सर्व ओव्हरहेड खर्च जवळजवळ शून्यावर कमी करण्यासाठी हे पुरेसे होते.

त्यानुसार, प्रत्येक एक-वेळच्या विनंतीवर डेटाबेसमधील मेमरी वाया जाऊ नये म्हणून सर्व्हर-तयार विधाने 5 व्या अंमलबजावणीवर सक्रिय केली जातात.

तुम्ही विचारू शकता - संख्या कुठे आहेत? तुम्हाला काय मिळत आहे? आणि येथे मी नंबर देणार नाही, कारण प्रत्येक विनंतीची स्वतःची असते.

आमच्या क्वेरी अशा होत्या की आम्ही OLTP क्वेरीचे विश्लेषण करण्यासाठी सुमारे 20 मिलीसेकंद खर्च केले. अंमलबजावणीसाठी 0,5 मिलीसेकंद, पार्सिंगसाठी 20 मिलीसेकंद होते. विनंती – 10 KiB मजकूर, योजनेच्या 170 ओळी. ही OLTP विनंती आहे. हे 1, 5, 10 ओळींची विनंती करते, कधीकधी अधिक.

पण आम्हाला 20 मिलीसेकंद वाया घालवायचे नव्हते. आम्ही ते 0 पर्यंत कमी केले. सर्व काही छान आहे.

तुम्ही इथून काय घेऊन जाऊ शकता? जर तुमच्याकडे जावा असेल तर तुम्ही ड्रायव्हरची आधुनिक आवृत्ती घ्या आणि आनंद करा.

जर तुम्ही वेगळी भाषा बोलत असाल तर विचार करा - कदाचित तुम्हालाही याची गरज आहे? कारण अंतिम भाषेच्या दृष्टिकोनातून, उदाहरणार्थ, जर PL 8 किंवा तुमच्याकडे LibPQ असेल, तर तुम्ही अंमलबजावणीवर, पार्सिंगवर नाही वेळ घालवत आहात हे तुमच्यासाठी स्पष्ट नाही आणि हे तपासण्यासारखे आहे. कसे? सर्व काही विनामूल्य आहे.

त्याशिवाय काही त्रुटी आणि काही वैशिष्ठ्ये आहेत. आणि आम्ही आत्ता त्यांच्याबद्दल बोलू. बहुतेक ते औद्योगिक पुरातत्वशास्त्र, आम्हाला काय सापडले, आम्हाला काय मिळाले याबद्दल असेल.

जर विनंती डायनॅमिकली व्युत्पन्न केली असेल. असे घडत असते, असे घडू शकते. कोणीतरी स्ट्रिंग्स एकत्र चिकटवतो, परिणामी SQL क्वेरी येते.

तो वाईट का आहे? हे वाईट आहे कारण प्रत्येक वेळी आपण वेगळ्या स्ट्रिंगसह समाप्त होतो.

आणि या वेगळ्या स्ट्रिंगचा हॅशकोड पुन्हा वाचावा लागेल. हे खरोखर एक CPU कार्य आहे - विद्यमान हॅशमध्ये देखील एक लांब विनंती मजकूर शोधणे इतके सोपे नाही. म्हणून, निष्कर्ष सोपे आहे - विनंत्या तयार करू नका. त्यांना एका व्हेरिएबलमध्ये साठवा. आणि आनंद करा.

पुढील समस्या. डेटा प्रकार महत्त्वाचे आहेत. असे ORM आहेत जे म्हणतात की कोणत्या प्रकारचे NULL आहे हे महत्त्वाचे नाही, काही प्रकारचे असू द्या. जर Int, तर आपण म्हणतो setInt. आणि जर NULL असेल तर ते नेहमी VARCHAR असू द्या. आणि शेवटी NULL म्हणजे काय फरक पडतो? डेटाबेस स्वतः सर्वकाही समजेल. आणि हे चित्र चालत नाही.

सराव मध्ये, डेटाबेस अजिबात काळजी करत नाही. जर तुम्ही प्रथमच सांगितले की ही संख्या आहे, आणि दुसऱ्या वेळी तुम्ही ती VARCHAR असल्याचे सांगितले, तर सर्व्हर-तयार विधाने पुन्हा वापरणे अशक्य आहे. आणि या प्रकरणात, आपल्याला आपले विधान पुन्हा तयार करावे लागेल.

तुम्ही तीच क्वेरी अंमलात आणत असल्यास, तुमच्या कॉलममधील डेटा प्रकार गोंधळलेले नाहीत याची खात्री करा. आपण NULL साठी लक्ष ठेवणे आवश्यक आहे. आम्ही PreparedStatements वापरण्यास सुरुवात केल्यानंतर ही एक सामान्य त्रुटी आहे

ठीक आहे, चालू केले. कदाचित त्यांनी ड्रायव्हरला घेतले. आणि उत्पादकता घसरली. गोष्टी वाईट झाल्या.

हे कसे घडते? हे एक बग किंवा वैशिष्ट्य आहे? दुर्दैवाने, हे बग आहे की वैशिष्ट्य हे समजणे शक्य नव्हते. परंतु या समस्येचे पुनरुत्पादन करण्यासाठी एक अतिशय सोपी परिस्थिती आहे. तिने पूर्णपणे अनपेक्षितपणे आमच्यावर हल्ला केला. आणि त्यात अक्षरशः एका टेबलवरून नमुना घेणे समाविष्ट आहे. आमच्याकडे अर्थातच अशा आणखी विनंत्या होत्या. नियमानुसार, त्यांनी दोन किंवा तीन टेबल्स समाविष्ट केल्या आहेत, परंतु अशी प्लेबॅक परिस्थिती आहे. तुमच्या डेटाबेसमधून कोणतीही आवृत्ती घ्या आणि ती प्ले करा.

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

मुद्दा असा आहे की आपल्याकडे दोन स्तंभ आहेत, त्यापैकी प्रत्येक अनुक्रमित आहे. एका NULL स्तंभात दहा लाख पंक्ती आहेत. आणि दुसऱ्या स्तंभात फक्त 20 ओळी आहेत. जेव्हा आपण बाउंड व्हेरिएबल्सशिवाय कार्यान्वित करतो, तेव्हा सर्वकाही चांगले कार्य करते.

जर आपण बाउंड व्हेरिएबल्ससह कार्यान्वित करू लागलो, म्हणजे आपण "?" किंवा आमच्या विनंतीसाठी "$1", आम्हाला शेवटी काय मिळेल?

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

प्रथम अंमलबजावणी अपेक्षेप्रमाणे आहे. दुसरा थोडा वेगवान आहे. काहीतरी कॅश केले होते. तिसरा, चौथा, पाचवा. मग मोठा आवाज - आणि असे काहीतरी. आणि सर्वात वाईट गोष्ट अशी आहे की हे सहाव्या फाशीवर होते. प्रत्यक्ष अंमलबजावणीची योजना काय आहे हे समजून घेण्यासाठी नक्की सहा फाशी करणे आवश्यक आहे हे कोणाला माहीत होते?

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

आपण याबद्दल काय करू शकता? येथे, अर्थातच, काहीही गृहीत धरणे अधिक कठीण आहे. एक सोपा उपाय आहे जो आपण वापरतो. हे +0 आहे, ऑफसेट 0. तुम्हाला असे उपाय नक्कीच माहित आहेत. आम्ही फक्त ते घेतो आणि विनंतीमध्ये "+0" जोडतो आणि सर्व काही ठीक आहे. मी नंतर दाखवतो.

आणि दुसरा पर्याय आहे - योजना अधिक काळजीपूर्वक पहा. डेव्हलपरने फक्त विनंती लिहिणे आवश्यक नाही तर 6 वेळा "विश्लेषण स्पष्ट करा" देखील म्हटले पाहिजे. जर ते 5 असेल तर ते कार्य करणार नाही.

आणि तिसरा पर्याय आहे - pgsql-hackers ला पत्र लिहा. मी लिहिले, तथापि, हे एक बग आहे की वैशिष्ट्य आहे हे अद्याप स्पष्ट झालेले नाही.

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

हा एक बग किंवा वैशिष्ट्य आहे की नाही याचा विचार करत असताना, त्याचे निराकरण करूया. चला आमची विनंती घेऊ आणि "+0" जोडा. सर्व काही ठीक आहे. दोन चिन्हे आणि तुम्हाला ते कसे आहे किंवा ते काय आहे याचा विचार करण्याची गरज नाही. अगदी साधे. आम्ही डेटाबेसला या स्तंभावरील अनुक्रमणिका वापरण्यास मनाई केली आहे. आमच्याकडे “+0” स्तंभावर अनुक्रमणिका नाही आणि तेच आहे, डेटाबेस निर्देशांक वापरत नाही, सर्व काही ठीक आहे.

हा 6 स्पष्टीकरणाचा नियम आहे. आता चालू आवृत्त्यांमध्ये जर तुमच्याकडे बंधनकारक व्हेरिएबल्स असतील तर तुम्हाला ते 6 वेळा करावे लागेल. जर तुमच्याकडे बाउंड व्हेरिएबल्स नसेल, तर आम्ही हे करतो. आणि शेवटी ही विनंती अयशस्वी ठरते. ती काही अवघड गोष्ट नाही.

असे वाटते की, किती शक्य आहे? इथे बग, तिकडे बग. खरं तर, बग सर्वत्र आहे.

चला जवळून बघूया. उदाहरणार्थ, आमच्याकडे दोन स्कीमा आहेत. टेबल S सह स्कीम A आणि टेबल S सह आकृती B. क्वेरी - टेबलमधून डेटा निवडा. या प्रकरणात आम्हाला काय मिळेल? आमच्याकडे एक त्रुटी असेल. आमच्याकडे वरील सर्व गोष्टी असतील. नियम असा आहे - बग सर्वत्र आहे, आपल्याकडे वरील सर्व गोष्टी असतील.

आता प्रश्न आहे: "का?" असे दिसते की असे दस्तऐवजीकरण आहे की आमच्याकडे स्कीमा असल्यास, "शोध_पथ" व्हेरिएबल आहे जे आम्हाला टेबल कुठे शोधायचे हे सांगते. असे दिसते की व्हेरिएबल आहे.

काय अडचण आहे? समस्या अशी आहे की सर्व्हर-तयार विधाने शोध_पथ कोणीतरी बदलू शकतात असा संशय येत नाही. हे मूल्य डेटाबेससाठी स्थिर राहते. आणि काही भाग नवीन अर्थ घेऊ शकत नाहीत.

अर्थात, हे तुम्ही चाचणी करत असलेल्या आवृत्तीवर अवलंबून आहे. तुमची सारणी किती गंभीरपणे भिन्न आहेत यावर अवलंबून आहे. आणि आवृत्ती 9.1 फक्त जुन्या प्रश्नांची अंमलबजावणी करेल. नवीन आवृत्त्या बग पकडू शकतात आणि तुम्हाला एक बग असल्याचे सांगू शकतात.

शोध_पथ + सर्व्हर-तयार विधाने = सेट करा
कॅश्ड प्लॅन परिणाम प्रकार बदलू नये

त्यावर उपचार कसे करावे? एक साधी कृती आहे - ते करू नका. अनुप्रयोग चालू असताना शोध_पथ बदलण्याची गरज नाही. आपण बदलल्यास, नवीन कनेक्शन तयार करणे चांगले आहे.

तुम्ही चर्चा करू शकता, म्हणजे उघडा, चर्चा करा, जोडा. कदाचित आम्ही डेटाबेस विकसकांना हे पटवून देऊ शकतो की जेव्हा कोणी मूल्य बदलते तेव्हा डेटाबेसने क्लायंटला याबद्दल सांगावे: “पाहा, तुमचे मूल्य येथे अद्यतनित केले गेले आहे. कदाचित तुम्हाला विधाने रीसेट करण्याची आणि ती पुन्हा तयार करण्याची आवश्यकता आहे?" आता डेटाबेस गुप्तपणे वागतो आणि स्टेटमेंट्स आत कुठेतरी बदलल्याचा अहवाल देत नाही.

आणि मी पुन्हा जोर देईन - हे असे काहीतरी आहे जे जावासाठी वैशिष्ट्यपूर्ण नाही. तीच गोष्ट आपण PL/pgSQL मध्ये एक ते एक पाहू. पण त्याचे पुनरुत्पादन तिथे केले जाईल.

चला आणखी काही डेटा निवड करून पाहू या. आम्ही निवडतो आणि निवडतो. आमच्याकडे एक दशलक्ष पंक्ती असलेली टेबल आहे. प्रत्येक ओळ एक किलोबाइट आहे. अंदाजे एक गीगाबाइट डेटा. आणि आमच्याकडे जावा मशीनमध्ये 128 मेगाबाइट्सची कार्यरत मेमरी आहे.

आम्ही, सर्व पुस्तकांमध्ये शिफारस केल्यानुसार, प्रवाह प्रक्रिया वापरतो. म्हणजेच, आम्ही रिझल्टसेट उघडतो आणि तिथून हळूहळू डेटा वाचतो. चालेल का? आठवणीतून पडेल का? थोडे वाचाल का? चला डेटाबेसवर विश्वास ठेवूया, पोस्टग्रेसवर विश्वास ठेवूया. आमचा विश्वास बसत नाही. आपण आउटऑफ मेमरी पडू का? OutOfMemory चा अनुभव कोणी घेतला? त्यानंतर ते दुरुस्त करण्यात कोणी व्यवस्थापित केले? कोणीतरी त्याचे निराकरण करण्यात व्यवस्थापित केले.

तुमच्याकडे दशलक्ष पंक्ती असल्यास, तुम्ही फक्त निवडून निवडू शकत नाही. ऑफसेट/लिमिट आवश्यक आहे. या पर्यायासाठी कोण आहे? आणि autoCommit सह खेळण्याच्या बाजूने कोण आहे?

येथे, नेहमीप्रमाणे, सर्वात अनपेक्षित पर्याय योग्य असल्याचे बाहेर वळते. आणि जर तुम्ही अचानक autoCommit बंद केले तर ते मदत करेल. अस का? विज्ञानाला याबद्दल माहिती नाही.

परंतु डीफॉल्टनुसार, पोस्टग्रेस डेटाबेसशी कनेक्ट केलेले सर्व क्लायंट संपूर्ण डेटा आणतात. PgJDBC या बाबतीत अपवाद नाही; ते सर्व पंक्ती निवडते.

FetchSize थीमवर भिन्नता आहे, म्हणजे तुम्ही स्वतंत्र विधानाच्या पातळीवर असे म्हणू शकता की येथे, कृपया 10, 50 पर्यंत डेटा निवडा. परंतु जोपर्यंत तुम्ही ऑटोकमिट बंद करत नाही तोपर्यंत हे कार्य करत नाही. ऑटोकमिट बंद केले - ते कार्य करण्यास प्रारंभ करते.

परंतु कोडमधून जाणे आणि सेटफेचसाईज सर्वत्र सेट करणे गैरसोयीचे आहे. म्हणून, आम्ही एक सेटिंग तयार केली आहे जी संपूर्ण कनेक्शनसाठी डीफॉल्ट मूल्य सांगेल.

आम्ही तेच म्हणालो. पॅरामीटर कॉन्फिगर केले आहे. आणि आम्हाला काय मिळाले? जर आम्ही लहान रक्कम निवडली, उदाहरणार्थ, आम्ही एका वेळी 10 पंक्ती निवडल्या, तर आमच्याकडे खूप मोठे ओव्हरहेड खर्च आहेत. म्हणून, हे मूल्य सुमारे शंभरवर सेट केले पाहिजे.

तद्वतच, अर्थातच, तुम्हाला ते बाइट्समध्ये कसे मर्यादित करायचे हे अद्याप शिकावे लागेल, परंतु रेसिपी अशी आहे: डीफॉल्टरोफेचसाइज शंभरपेक्षा जास्त सेट करा आणि आनंदी रहा.

चला डेटा घालण्यासाठी पुढे जाऊया. समाविष्ट करणे सोपे आहे, विविध पर्याय आहेत. उदाहरणार्थ, INSERT, VALUES. हा एक चांगला पर्याय आहे. तुम्ही "इन्सर्ट सिलेक्ट" म्हणू शकता. व्यवहारात तीच गोष्ट आहे. कामगिरीत फरक नाही.

पुस्तके म्हणतात की तुम्हाला बॅच स्टेटमेंट कार्यान्वित करणे आवश्यक आहे, पुस्तके म्हणतात की तुम्ही अनेक कंसांसह अधिक जटिल कमांड कार्यान्वित करू शकता. आणि पोस्टग्रेसमध्ये एक अद्भुत वैशिष्ट्य आहे - तुम्ही कॉपी करू शकता, म्हणजे ते जलद करू शकता.

आपण ते मोजल्यास, आपण पुन्हा काही मनोरंजक शोध लावू शकता. आम्हाला हे कसे कार्य करायचे आहे? आम्ही अनावश्यक आज्ञा पार्स करू नये आणि कार्यान्वित करू नये अशी आमची इच्छा आहे.

सराव मध्ये, TCP आम्हाला हे करण्याची परवानगी देत ​​नाही. क्लायंट विनंती पाठवण्यात व्यस्त असल्यास, डेटाबेस आम्हाला प्रतिसाद पाठवण्याच्या प्रयत्नात विनंत्या वाचत नाही. अंतिम परिणाम असा आहे की क्लायंट विनंती वाचण्यासाठी डेटाबेसची वाट पाहतो आणि डेटाबेस प्रतिसाद वाचण्यासाठी क्लायंटची वाट पाहतो.

आणि म्हणूनच क्लायंटला वेळोवेळी सिंक्रोनाइझेशन पॅकेट पाठविण्यास भाग पाडले जाते. अतिरिक्त नेटवर्क परस्परसंवाद, वेळेचा अतिरिक्त अपव्यय.

आणि जितके जास्त आपण ते जोडू तितके वाईट होईल. ड्रायव्हर खूप निराशावादी आहे आणि त्यांना अनेकदा जोडतो, प्रत्येक 200 ओळींमध्ये एकदा, ओळींच्या आकारावर अवलंबून असते इ.

https://github.com/pgjdbc/pgjdbc/pull/380

असे होते की आपण फक्त एक ओळ दुरुस्त करता आणि सर्वकाही 10 वेळा वेगवान होईल. असे घडत असते, असे घडू शकते. का? नेहमीप्रमाणे, असा स्थिरांक आधीच कुठेतरी वापरला गेला आहे. आणि "128" मूल्याचा अर्थ बॅचिंग वापरणे नाही.

जावा मायक्रोबेंचमार्क हार्नेस

हे अधिकृत आवृत्तीमध्ये समाविष्ट केलेले नाही हे चांगले आहे. प्रकाशन सुरू होण्यापूर्वी शोधले. मी दिलेले सर्व अर्थ आधुनिक आवृत्त्यांवर आधारित आहेत.

चला त्यावर प्रयत्न करूया. आम्ही InsertBatch सोपे मोजतो. आम्ही InsertBatch अनेक वेळा मोजतो, म्हणजे समान गोष्ट, परंतु अनेक मूल्ये आहेत. अवघड चाल. प्रत्येकजण हे करू शकत नाही, परंतु ही एक सोपी चाल आहे, कॉपी करण्यापेक्षा खूपच सोपी.

तुम्ही कॉपी करू शकता.

आणि आपण हे संरचनांवर करू शकता. वापरकर्ता डीफॉल्ट प्रकार घोषित करा, ॲरे पास करा आणि थेट टेबलवर घाला.

तुम्ही लिंक उघडल्यास: pgjdbc/ubenchmsrk/InsertBatch.java, हा कोड GitHub वर आहे. तेथे कोणकोणत्या विनंत्या व्युत्पन्न केल्या जातात ते तुम्ही पाहू शकता. काही फरक पडत नाही.

आम्ही लॉन्च केले. आणि आम्हाला पहिली गोष्ट समजली की बॅच न वापरणे केवळ अशक्य आहे. सर्व बॅचिंग पर्याय शून्य आहेत, म्हणजे एक-वेळच्या अंमलबजावणीच्या तुलनेत अंमलबजावणीची वेळ व्यावहारिकदृष्ट्या शून्य आहे.

आम्ही डेटा टाकतो. हे एक अतिशय साधे टेबल आहे. तीन स्तंभ. आणि आम्ही येथे काय पाहतो? आम्ही पाहतो की हे तिन्ही पर्याय अंदाजे तुलना करता येतील. आणि कॉपी अर्थातच अधिक चांगली आहे.

जेव्हा आपण तुकडे घालतो तेव्हा असे होते. जेव्हा आम्ही एक VALUES मूल्य, दोन VALUES मूल्ये, तीन VALUES मूल्ये किंवा स्वल्पविरामाने विभक्त केलेले 10 सूचित केले. हे आता फक्त क्षैतिज आहे. 1, 2, 4, 128. हे पाहिले जाऊ शकते की बॅच इन्सर्ट, जे निळ्या रंगात काढलेले आहे, त्याला खूप चांगले वाटते. म्हणजेच, जेव्हा तुम्ही एका वेळी एक घाला किंवा तुम्ही एकावेळी चार टाकता तेव्हाही ते दुप्पट चांगले होते, फक्त कारण आम्ही VALUES मध्ये थोडे अधिक क्रॅम केले आहे. कमी EXECUTE ऑपरेशन्स.

लहान व्हॉल्यूमवर कॉपी वापरणे अत्यंत अप्रिय आहे. मी पहिल्या दोन वर काढले नाही. ते स्वर्गात जातात, म्हणजेच कॉपीसाठी हे हिरवे अंक.

तुमच्याकडे किमान शंभर पंक्ती डेटा असताना कॉपी वापरली पाहिजे. हे कनेक्शन उघडण्याचे ओव्हरहेड मोठे आहे. आणि, प्रामाणिकपणे, मी या दिशेने खोदले नाही. मी बॅच ऑप्टिमाइझ केली, परंतु कॉपी नाही.

आम्ही पुढे काय करू? आम्ही त्यावर प्रयत्न केले. आम्हाला समजले आहे की आम्हाला एकतर रचना किंवा अनेक अर्थ एकत्रित करणारे चतुर बाकथ वापरण्याची आवश्यकता आहे.

आजच्या अहवालातून तुम्ही काय काढले पाहिजे?

• PreparedStatement हे आमचे सर्वस्व आहे. हे उत्पादकतेसाठी बरेच काही देते. हे मलम मध्ये एक मोठा धपकन निर्माण करते.
• आणि तुम्हाला 6 वेळा स्पष्टीकरण विश्लेषण करावे लागेल.
• आणि आमच्या समस्याग्रस्त प्रश्नांची उर्वरित टक्केवारी दुरुस्त करण्यासाठी आम्हाला OFFSET 0, आणि +0 सारख्या युक्त्या पातळ कराव्या लागतील.

स्त्रोत: www.habr.com