इंडेक्स के बारे में भूलने को कैसे रोकें और परीक्षणों में निष्पादन योजना की जांच शुरू करें

कुछ समय पहले, एक अप्रिय कहानी मेरे साथ घटित हुई, जिसने एक गीथूब पर एक छोटी सी परियोजना के लिए एक ट्रिगर के रूप में कार्य किया और इस लेख का परिणाम हुआ।

एक सामान्य दिन, एक सामान्य रिलीज: हमारे क्यूए इंजीनियर द्वारा सभी कार्यों को ऊपर और नीचे की जाँच की जाती है, इसलिए पवित्र गाय की शांति के साथ हम मंच पर "रोल" करते हैं। अनुप्रयोग अच्छा व्यवहार करता है, लॉग में - मौन। हम स्विच (चरण <-> ठेस) करने का निर्णय लेते हैं। हम स्विच करते हैं, उपकरणों को देखें ...

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

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

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

मैं निगरानी रखता हूं (मैं JavaMelody का उपयोग करता हूं ), मुझे ये अनुरोध मिलते हैं। मैं पीजीडीमिन शुरू करता हूं, मैं पुन: पेश करता हूं। वास्तव में लंबा है। मैं "व्याख्या" जोड़ता हूं, मैं निष्पादन योजना को देखता हूं ... यह है, हम अनुक्रमित के बारे में भूल गए।

कोड समीक्षा पर्याप्त क्यों नहीं है?

उस घटना ने मुझे बहुत कुछ सिखाया। हां, मैंने एक घंटे के लिए "आग को बुझाया", सीधे किसी तरह से ठेस पर सही सूचकांक बनाना (CONCURRENTLY विकल्प के बारे में मत भूलना):

CREATE INDEX CONCURRENTLY IF NOT EXISTS ix_pets_name ON pets_table (name_column); 

सहमत, यह डाउनटाइम के साथ एक तैनाती के लिए समान था। मैं जिस एप्लिकेशन पर काम कर रहा हूं, उसके लिए यह अस्वीकार्य है।

मैंने निष्कर्ष निकाला और कोड की समीक्षा के लिए चेकलिस्ट में एक विशेष बोल्ड पॉइंट जोड़ा: यदि मैं देखता हूं कि विकास प्रक्रिया के दौरान रिपॉजिटरी वर्गों में से एक को जोड़ा गया / बदल दिया गया - मैं एक स्क्रिप्ट की उपस्थिति के लिए sql माइग्रेशन की जांच करता हूं जो वहां सूचकांक बनाता है और बदलता है। यदि वह नहीं है, तो मैं लेखक को एक प्रश्न लिख रहा हूं: क्या वह सुनिश्चित है कि यहां सूचकांक की आवश्यकता नहीं है?

यह संभावना है कि थोड़ा डेटा होने पर सूचकांक की आवश्यकता नहीं है, लेकिन अगर हम एक तालिका के साथ काम करते हैं जिसमें पंक्तियों की संख्या लाखों में गिना जाता है, तो एक सूचकांक त्रुटि घातक हो सकती है और लेख की शुरुआत में कहानी सेट हो सकती है।

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

1. एप्लिकेशन लॉन्च करता है
2. लॉग में परिवर्तित (HQL -> SQL) क्वेरी की तलाश है
3. PGAdmin या कोई अन्य डेटाबेस व्यवस्थापन उपकरण खोलता है
4. स्थानीय डेटाबेस में उत्पन्न होता है, इसलिए किसी को भी अपने प्रयोगों से परेशान नहीं करना है, परीक्षणों के लिए स्वीकार्य डेटा की एक राशि (न्यूनतम 10K - 10KK)
5. अनुरोध पूरा करता है
6. निष्पादन योजना का अनुरोध करता है
7. ध्यान से इसका अध्ययन करता है और उचित निष्कर्ष निकालता है
8. इंडेक्स को जोड़ता / संशोधित करता है, यह सुनिश्चित करता है कि निष्पादन योजना इसे सूट करती है
9. पीआर में सदस्यता समाप्त करने का अनुरोध करता है
10. विशेषज्ञ जोखिमों और अनुरोध की गंभीरता का आकलन करते हुए, मैं इसके कार्यों की दोबारा जांच कर सकता हूं

बहुत सी नियमित क्रियाएं और मानवीय कारक, लेकिन कुछ समय के लिए मैं संतुष्ट था, और मैं इसके साथ रहता था।

घर के रास्ते पर

वे कहते हैं कि रास्ते में संगीत / पॉडकास्ट सुने बिना काम से जाना कभी-कभी बहुत उपयोगी होता है। इस समय, केवल जीवन के बारे में सोचकर, आप दिलचस्प निष्कर्ष और विचारों पर आ सकते हैं।

एक दिन मैं घर चला गया और सोचा कि उस दिन क्या हुआ था। कुछ समीक्षा हुई, मैंने प्रत्येक को एक चेकलिस्ट के साथ जाँच की और ऊपर वर्णित कार्यों की एक श्रृंखला की। मैं उस समय इतना थक गया, मैंने सोचा, यह क्या मुसीबत है? क्या स्वचालित रूप से ऐसा करना असंभव है? .. मैंने एक त्वरित कदम उठाया, जल्दी से इस विचार को "कट" करना चाहता था।

समस्या का बयान

निष्पादन योजना में डेवलपर के लिए सबसे महत्वपूर्ण क्या है?
बेशक, एक सूचकांक की कमी के कारण बड़ी मात्रा में डेटा पर seq स्कैन।

इस प्रकार, यह एक परीक्षण करने के लिए आवश्यक था कि:

1. एक डेटाबेस पर ठेस के समान कॉन्फ़िगरेशन के साथ प्रदर्शन किया
2. एक JPA रिपॉजिटरी (हाइबरनेट) द्वारा बनाई गई डेटाबेस क्वेरी को स्वीकार करता है
3. यह निष्पादन योजना हो जाता है
4. Parsit निष्पादन योजना, इसे जाँच के लिए सुविधाजनक डेटा संरचना में रखना
5. मुखर तरीकों का एक सुविधाजनक सेट का उपयोग करना, अपेक्षाओं की जांच करता है। उदाहरण के लिए, उस seq स्कैन का उपयोग नहीं किया जाता है।

एक प्रोटोटाइप बनाकर इस परिकल्पना का जल्द परीक्षण करना आवश्यक था।

समाधान वास्तुकला

पहली समस्या जिसे हल किया जाना था, वह एक वास्तविक डेटाबेस पर परीक्षण का प्रक्षेपण था जो संस्करण और सेटिंग्स पर ठेस पर इस्तेमाल होने वाले से मेल खाता है।

Docker & TestContainers के लिए धन्यवाद, वे इस समस्या को हल करते हैं।

SqlInterceptor, ExecutionPlanQuery, ExecutionPlanParse, और AssertService इंटरफेस है कि मैं वर्तमान में Postgres के लिए लागू किया है। अन्य डेटाबेस के लिए योजनाओं को लागू करना है। यदि आप भाग लेना चाहते हैं - स्वागत है। कोड कोटलिन में लिखा है।

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

CheckInx घटकों की बातचीत का विवरण

ProxyDataSource

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

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

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

मैं DataSourceWrapper (बीनपोस्टप्रोसेसर) क्लास का उपयोग करके स्रोत डेटा स्रोत को प्रतिस्थापित करता हूं।

SqlInterceptor

वास्तव में, इसकी शुरुआत () विधि अपने श्रोता को प्रॉक्सीडेटा स्रोत में सेट करती है और आंतरिक डेटा सूची में उन्हें संग्रहीत करते हुए अनुरोधों को रोकना शुरू कर देती है। क्रमशः स्टॉप () विधि, स्थापित श्रोता को हटा देती है।

ExecutionPlanQuery

यहां, मूल अनुरोध निष्पादन योजना के लिए अनुरोध में तब्दील हो जाता है। Postgres के मामले में, यह क्वेरी कीवर्ड "EXPLAIN" के लिए एक अतिरिक्त है।

इसके अलावा, इस क्वेरी को टेस्टकनेक्टर्स से एक ही डेटाबेस पर निष्पादित किया जाता है और एक "रॉ" निष्पादन योजना (लाइनों की सूची) वापस कर दी जाती है।

ExecutionPlanParser

कच्चे निष्पादन योजना के साथ काम करना असुविधाजनक है। इसलिए, मैं इसे एक पेड़ में नोड्स (प्लाननोड) से पार्स करता हूं।

आइए एक वास्तविक निष्पादनप्लान के उदाहरण का उपयोग करते हुए PlanNode फ़ील्ड का विश्लेषण करें:

 Index Scan using ix_pets_age on pets  (cost=0.29..8.77 rows=1 width=36) Index Cond: (age < 10) Filter: ((name)::text = 'Jack'::text) 

AssertService

पार्सर द्वारा लौटाए गए डेटा संरचना के साथ सामान्य रूप से काम करना पहले से ही संभव है। CheckInxAssertService, ऊपर वर्णित PlanNode ट्री के चेक का एक सेट है। यह आपको अपने स्वयं के लैंबडास सेट करने या पूर्वनिर्धारित का उपयोग करने की अनुमति देता है, मेरी राय में, सबसे लोकप्रिय वाले। उदाहरण के लिए, ताकि आपकी क्वेरी में Seq स्कैन न हो, या आप यह सुनिश्चित करना चाहते हैं कि किसी विशिष्ट इंडेक्स का उपयोग नहीं किया गया है / उपयोग नहीं किया गया है।

CoverageLevel

बहुत महत्वपूर्ण Enum, मैं इसे अलग से वर्णन करूंगा:

इसके बाद, हम कुछ उपयोग उदाहरणों को देखेंगे।

CheckInx का उपयोग करके टेस्ट उदाहरण

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

आप इस तरह एक परीक्षण हो सकता है:

 @Test fun testFindByLocation() {  // ARRANGE  val location = "Moscow"  //   ,      10-20.  //   TestNG      @BeforeClass  IntRange(1, 10000).forEach {      val pet = Pet()      pet.id = UUID.randomUUID()      pet.age = it      pet.location = "Saint Petersburg"      pet.name = "Jack-$it"      repository.save(pet)  }  // ACT  //     sqlInterceptor.startInterception()  //    val pets = repository.findByLocation(location)  //    sqlInterceptor.stopInterception()  // ASSERT  //         assertEquals(1, sqlInterceptor.statements.size.toLong())  // ,    ix_pets_location    (Index Scan)  checkInxAssertService.assertCoverage(CoverageLevel.HALF, "ix_pets_location", sqlInterceptor.statements[0])  //        ,      Seq Scan,        checkInxAssertService.assertCoverage(CoverageLevel.HALF, sqlInterceptor.statements[0])  // ...  ,      checkInxAssertService.assertPlan(plan) {          it.coverageLevel.level < CoverageLevel.FULL.level      } } 

कार्यान्वयन योजना निम्नानुसार हो सकती है:

 Index Scan using ix_pets_location on pets pet0_  (cost=0.29..4.30 rows=1 width=46) Index Cond: ((location)::text = 'Moscow'::text) 

... या इस तरह अगर हम सूचकांक के बारे में भूल गए (परीक्षण लाल हो गए):

 Seq Scan on pets pet0_  (cost=0.00..19.00 rows=4 width=84) Filter: ((location)::text = 'Moscow'::text) 

मेरी परियोजना में, मैं ज्यादातर सरलतम मुखर का उपयोग करता हूं, जो कहता है कि निष्पादन योजना में कोई Seq स्कैन नहीं है:

 checkInxAssertService.assertCoverage(CoverageLevel.HALF, sqlInterceptor.statements[0]) 

ऐसे परीक्षण की उपस्थिति से पता चलता है कि मैंने कम से कम, कार्यान्वयन योजना का अध्ययन किया।
यह परियोजना प्रबंधन को और अधिक स्पष्ट करता है, और कोड की दस्तावेज़ीकरण और पूर्वानुमानशीलता बढ़ जाती है।

परियोजना के लिए कनेक्शन

अपनी परियोजना में, मैंने इस तरह के परीक्षणों को एक अलग समूह को आवंटित किया, इसे गहन एकीकरण परीक्षण कहा।

चेक्सिंक्स-बर्तनों का उपयोग करना कनेक्ट करना और शुरू करना काफी आसान है। चलो निर्माण स्क्रिप्ट के साथ शुरू करते हैं।

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

 repositories { // ...  maven { url 'https://jitpack.io' } } 

अगला, निर्भरता जोड़ें:

 dependencies { // ...  implementation 'com.github.tinkoffcreditsystems:checkinx-utils:0.2.0' } 

हम कॉन्फ़िगरेशन को जोड़कर कनेक्शन पूरा करते हैं। वर्तमान में केवल पोस्टग्रैज का समर्थन किया गया है।

 @Profile("test") @ImportAutoConfiguration(classes = [PostgresConfig::class]) @Configuration open class CheckInxConfig 

टेस्ट प्रोफाइल पर ध्यान दें। अन्यथा, आप अपने उत्पादों में ProxyDataSource पाएंगे।

PostgresConfig कई सेम जोड़ता है:

1. DataSourceWrapper
2. PostgresInterceptor
3. PostgresExecutionPlanParser
4. PostgresExecutionPlanQuery
5. CheckInxAssertServiceImpl

यदि आपको किसी प्रकार के अनुकूलन की आवश्यकता है जो वर्तमान एपीआई प्रदान नहीं करता है, तो आप हमेशा अपने कार्यान्वयन के साथ बीन में से एक को बदल सकते हैं।

ज्ञात मुद्दे

कभी-कभी एक DataSourceWrapper मूल डेटा स्रोत को स्प्रिंग CGLIB प्रॉक्सी के कारण बदलने में विफल रहता है। इस मामले में, एक DataSource बीनपोस्टप्रोसेसर के लिए नहीं आता है, लेकिन ScopedProxyFactoryBean और टाइप चेकिंग के साथ समस्याएं हैं।

सबसे आसान समाधान परीक्षणों के लिए मैन्युअल रूप से HikariDataSource बनाना होगा। तब आपका विन्यास इस प्रकार होगा:

 @Profile("test") @ImportAutoConfiguration(classes = [PostgresConfig::class]) @Configuration open class CheckInxConfig {  @Primary  @Bean  @ConfigurationProperties("spring.datasource")  open fun dataSource(): DataSource {      return DataSourceBuilder.create()          .type(HikariDataSource::class.<i>java</i>)          .build()  }  @Bean  @ConfigurationProperties("spring.datasource.configuration")  open fun dataSource(properties: DataSourceProperties): HikariDataSource {      return properties.initializeDataSourceBuilder()          .type(HikariDataSource::class.<i>java</i>)          .build()  } } 

विकास की योजनाएँ

1. मैं यह समझना चाहूंगा कि क्या मेरे अलावा किसी को इसकी आवश्यकता है? ऐसा करने के लिए, एक सर्वेक्षण बनाएं। मुझे ईमानदारी से जवाब देने में खुशी होगी।
2. देखें कि आपको वास्तव में क्या जरूरत है और मुखर तरीकों की मानक सूची का विस्तार करें।
3. अन्य डेटाबेस के लिए कार्यान्वयन लिखें।
4. SqlInterceptor.statements [0] का निर्माण बहुत स्पष्ट नहीं दिखता है, मैं इसे सुधारना चाहता हूं।

मुझे खुशी होगी कि अगर कोई कोटलिन में अभ्यास करके इसमें शामिल होना चाहता है और कुछ क्रेडिट हासिल करना चाहता है।

निष्कर्ष

मुझे यकीन है कि टिप्पणियां होंगी: यह भविष्यवाणी करना असंभव है कि क्वेरी प्लानर कैसे ठेस पर व्यवहार करेगा, यह सब एकत्रित आंकड़ों पर निर्भर करता है ।

दरअसल, एक योजनाकार। पहले एकत्र किए गए आँकड़ों का उपयोग करते हुए, यह परीक्षण किए जा रहे से अलग एक योजना बना सकता है। अर्थ थोड़ा अलग है।

योजनाकार का कार्य सुधार करना है, बिगड़ना नहीं, अनुरोध। इसलिए, बिना किसी स्पष्ट कारण के, वह अचानक सेक स्कैन का उपयोग नहीं करेगा, लेकिन आप अनजाने में कर सकते हैं।

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

संदर्भ

1. https://github.com/TinkoffCreditSystems/checkinx-utils
2. https://github.com/dsemyriazhko/checkinx-demo
3. https://github.com/ttddyy/datasource-proxy
4. https://mvnrepository.com/artifact/org.testcontainers/postgresql
5. https://github.com/javamelody/javamelody/wiki