Apache Ignite मध्ये डेटा कॉम्प्रेशन. Sber चा अनुभव

मोठ्या प्रमाणात डेटासह काम करताना, डिस्क स्पेसच्या कमतरतेची समस्या कधीकधी उद्भवू शकते. या समस्येचे निराकरण करण्याचा एक मार्ग म्हणजे कॉम्प्रेशन, धन्यवाद, त्याच उपकरणांवर, आपण स्टोरेज व्हॉल्यूम वाढवू शकता. या लेखात, आपण Apache Ignite मध्ये डेटा कॉम्प्रेशन कसे कार्य करते ते पाहू. हा लेख केवळ उत्पादनामध्ये लागू केलेल्या डिस्क कॉम्प्रेशन पद्धतींचे वर्णन करेल. डेटा कॉम्प्रेशनच्या इतर पद्धती (नेटवर्कवर, मेमरीमध्ये), अंमलात आणल्या किंवा नसल्या तरी, कार्यक्षेत्राबाहेर राहतील.

तर, पर्सिस्टन्स मोड सक्षम केल्यामुळे, कॅशेमधील डेटामधील बदलांच्या परिणामी, इग्नाइट डिस्कवर लिहायला सुरुवात करते:

1. कॅशेची सामग्री
2. पुढे लॉग लिहा (यापुढे फक्त WAL)

WAL कॉम्प्रेशनसाठी गेल्या काही काळापासून एक यंत्रणा आहे, ज्याला WAL कॉम्पॅक्शन म्हणतात. नुकत्याच रिलीझ झालेल्या Apache Ignite 2.8 ने आणखी दोन यंत्रणा सादर केल्या आहेत ज्या तुम्हाला डिस्कवरील डेटा संकुचित करण्याची परवानगी देतात: कॅशेमधील सामग्री संकुचित करण्यासाठी डिस्क पृष्ठ कॉम्प्रेशन आणि काही WAL एंट्री कॉम्प्रेस करण्यासाठी WAL पृष्ठ स्नॅपशॉट कॉम्प्रेशन. खाली या तिन्ही यंत्रणांबद्दल अधिक तपशील.

डिस्क पृष्ठ कॉम्प्रेशन

या कसे कार्य करते

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

खालील फॉर्ममध्ये डिस्कवर डेटा संग्रहित केला जातो: प्रत्येक कॅशे गटाच्या प्रत्येक विभाजनासाठी एक वेगळी फाइल तयार केली जाते; या फाइलमध्ये, पृष्ठे एकामागून एक चढत्या अनुक्रमणिकेमध्ये दिसतात. पूर्ण पृष्ठ अभिज्ञापकामध्ये फाइलमधील कॅशे गट अभिज्ञापक, विभाजन क्रमांक आणि पृष्ठ अनुक्रमणिका समाविष्ट असते. अशा प्रकारे, पूर्ण पृष्ठ अभिज्ञापक वापरून, आम्ही प्रत्येक पृष्ठासाठी फाइल आणि ऑफसेट अनन्यपणे निर्धारित करू शकतो. तुम्ही Apache Ignite Wiki लेखात पेजिंग मेमरीबद्दल अधिक वाचू शकता: प्रज्वलित पर्सिस्टंट स्टोअर - हुड अंतर्गत.

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

परंतु प्रत्येक पृष्ठ स्वतंत्रपणे संकुचित करणे हा समस्येचे निराकरण नाही; आपल्याला परिणामी डेटा फायलींचा आकार कसा तरी कमी करणे आवश्यक आहे. जर पृष्ठाचा आकार यापुढे निश्चित केला नसेल, तर आम्ही यापुढे फाइलवर एकामागून एक पृष्ठे लिहू शकत नाही, कारण यामुळे अनेक समस्या निर्माण होऊ शकतात:

• पृष्ठ अनुक्रमणिका वापरून, आम्ही ते फाइलमध्ये असलेल्या ऑफसेटची गणना करू शकणार नाही.
• फाईलच्या शेवटी नसलेल्या पानांचे काय करायचे आणि त्यांचा आकार बदलायचा हे स्पष्ट नाही. जर पृष्ठाचा आकार कमी झाला, तर त्याने मोकळी केलेली जागा नाहीशी होते. जर पृष्ठाचा आकार वाढला, तर तुम्हाला त्यासाठी फाइलमध्ये नवीन स्थान शोधण्याची आवश्यकता आहे.
• जर एखादे पृष्‍ठ फाइल सिस्‍टम ब्लॉक आकाराच्या मल्टिपल नसलेल्या अनेक बाइट्सने हलत असेल, तर ते वाचणे किंवा लिहिण्‍यासाठी आणखी एका फाइल सिस्‍टम ब्लॉकला स्पर्श करणे आवश्‍यक आहे, ज्यामुळे कार्यप्रदर्शन खराब होऊ शकते.

या समस्यांचे स्वतःच्या स्तरावर निराकरण टाळण्यासाठी, Apache Ignite मधील डिस्क पेज कॉम्प्रेशन स्पॅर्स फाइल्स नावाची फाइल सिस्टम यंत्रणा वापरते. विरळ फाईल अशी आहे ज्यामध्ये काही शून्य-भरलेले प्रदेश "छिद्र" म्हणून चिन्हांकित केले जाऊ शकतात. या प्रकरणात, या छिद्रे संचयित करण्यासाठी कोणतेही फाइल सिस्टम ब्लॉक वाटप केले जाणार नाहीत, परिणामी डिस्क जागेवर बचत होईल.

हे तार्किक आहे की फाइल सिस्टम ब्लॉक मुक्त करण्यासाठी, छिद्राचा आकार फाइल सिस्टम ब्लॉकपेक्षा मोठा किंवा समान असणे आवश्यक आहे, जे पृष्ठ आकार आणि Apache Ignite वर अतिरिक्त मर्यादा घालते: कॉम्प्रेशनचा कोणताही परिणाम होण्यासाठी, पृष्ठाचा आकार फाईल सिस्टम ब्लॉकच्या आकारापेक्षा काटेकोरपणे मोठा असणे आवश्यक आहे. जर पृष्ठाचा आकार ब्लॉक आकाराच्या समान असेल, तर आम्ही कधीही एक ब्लॉक मुक्त करू शकणार नाही, कारण एक ब्लॉक मुक्त करण्यासाठी, संकुचित पृष्ठाने 0 बाइट व्यापले पाहिजेत. जर पृष्ठाचा आकार 2 किंवा 4 ब्लॉक्सच्या आकाराएवढा असेल, तर आमचे पृष्ठ अनुक्रमे किमान 50% किंवा 75% पर्यंत संकुचित केले असल्यास आम्ही आधीच किमान एक ब्लॉक मोकळा करू शकतो.

अशा प्रकारे, यंत्रणा कशी कार्य करते याचे अंतिम वर्णन: डिस्कवर पृष्ठ लिहिताना, पृष्ठ संकुचित करण्याचा प्रयत्न केला जातो. जर संकुचित पृष्ठाचा आकार एक किंवा अधिक फाइल सिस्टम ब्लॉक्सना मुक्त करण्यास परवानगी देतो, तर पृष्ठ संकुचित स्वरूपात लिहिले जाते आणि मुक्त केलेल्या ब्लॉक्सच्या जागी एक "छिद्र" बनविला जातो (सिस्टम कॉल कार्यान्वित केला जातो. fallocate() पंच होल ध्वजासह). संकुचित पृष्ठाचा आकार ब्लॉक्सना मुक्त करण्यास परवानगी देत ​​नसल्यास, पृष्ठ जसे आहे तसे जतन केले जाते, असंपीडित. सर्व पृष्ठ ऑफसेटची गणना पृष्ठाच्या आकाराने पृष्ठ अनुक्रमणिका गुणाकार करून, कॉम्प्रेशनशिवाय केली जाते. स्वतःहून पृष्ठांचे पुनर्स्थापना आवश्यक नाही. पृष्ठ ऑफसेट्स, जसे की कॉम्प्रेशनशिवाय, फाइल सिस्टम ब्लॉक्सच्या सीमांवर येतात.

सध्याच्या अंमलबजावणीमध्ये, Ignite फक्त Linux OS अंतर्गत विरळ फाइल्ससह कार्य करू शकते; त्यानुसार, या ऑपरेटिंग सिस्टमवर Ignite वापरताना डिस्क पृष्ठ कॉम्प्रेशन सक्षम केले जाऊ शकते.

कॉम्प्रेशन अल्गोरिदम जे डिस्क पृष्ठ कॉम्प्रेशनसाठी वापरले जाऊ शकतात: ZSTD, LZ4, Snappy. याव्यतिरिक्त, एक ऑपरेटिंग मोड (SKIP_GARBAGE) आहे, ज्यामध्ये उर्वरित डेटावर कम्प्रेशन न लावता पृष्ठावरील केवळ न वापरलेली जागा फेकली जाते, जी पूर्वी सूचीबद्ध केलेल्या अल्गोरिदमच्या तुलनेत CPU वरील भार कमी करते.

कार्यप्रदर्शन प्रभाव

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

हे करण्यासाठी, प्रवेश केल्यावर पृष्ठे कशी वाचली आणि लिहिली जातात हे आम्हाला लक्षात ठेवणे आवश्यक आहे:

• रीड ऑपरेशन करत असताना, ते प्रथम RAM मध्ये शोधले जाते; जर शोध अयशस्वी झाला, तर पृष्ठ त्याच थ्रेडद्वारे डिस्कवरून RAM मध्ये लोड केले जाते जे वाचन करते.
• जेव्हा लेखन ऑपरेशन केले जाते, तेव्हा RAM मधील पृष्ठ गलिच्छ म्हणून चिन्हांकित केले जाते, परंतु लेखन कार्य करत असलेल्या थ्रेडद्वारे पृष्ठ त्वरित डिस्कवर भौतिकरित्या जतन केले जात नाही. चेकपॉईंट प्रक्रियेत सर्व गलिच्छ पृष्ठे नंतर डिस्कवर स्वतंत्र थ्रेडमध्ये जतन केली जातात.

त्यामुळे रीड ऑपरेशन्सवर परिणाम होतो:

• पॉझिटिव्ह (डिस्क आयओ), रिड फाइल सिस्टम ब्लॉक्सच्या संख्येत घट झाल्यामुळे.
• नकारात्मक (CPU), विरळ फाइल्ससह कार्य करण्यासाठी ऑपरेटिंग सिस्टमला आवश्यक असलेल्या अतिरिक्त लोडमुळे. हे देखील शक्य आहे की अधिक जटिल विरळ फाइल संरचना जतन करण्यासाठी अतिरिक्त IO ऑपरेशन्स येथे स्पष्टपणे दिसून येतील (दुर्दैवाने, विरळ फाइल्स कशा कार्य करतात या सर्व तपशीलांशी मी परिचित नाही).
• निगेटिव्ह (CPU), पृष्ठे डीकंप्रेस करण्याची आवश्यकता असल्यामुळे.
• लेखन कार्यावर कोणताही परिणाम होत नाही.
• चेकपॉईंट प्रक्रियेवर प्रभाव (येथे सर्व काही वाचन ऑपरेशन्ससारखे आहे):
• पॉझिटिव्ह (डिस्क आयओ), लिखित फाइल सिस्टम ब्लॉक्सच्या संख्येत घट झाल्यामुळे.
• विरळ फाइल्ससह काम केल्यामुळे नकारात्मक (CPU, शक्यतो डिस्क IO).
• निगेटिव्ह (CPU), पेज कॉम्प्रेशनच्या गरजेमुळे.

स्केलची कोणती बाजू स्केलला टीप देईल? हे सर्व वातावरणावर बरेच अवलंबून असते, परंतु डिस्क पृष्ठ कम्प्रेशन बहुधा बहुतेक प्रणालींवर कार्यक्षमतेत ऱ्हास होऊ शकते यावर माझा विश्वास आहे. शिवाय, इतर डीबीएमएस वरील चाचण्या ज्या विरळ फायलींसह समान दृष्टीकोन वापरतात तेव्हा कम्प्रेशन सक्षम केल्यावर कार्यक्षमतेत घट दिसून येते.

सक्षम आणि कॉन्फिगर कसे करावे

वर नमूद केल्याप्रमाणे, डिस्क पेज कॉम्प्रेशनला सपोर्ट करणारी Apache Ignite ची किमान आवृत्ती 2.8 आहे आणि फक्त Linux ऑपरेटिंग सिस्टीम समर्थित आहे. खालीलप्रमाणे सक्षम आणि कॉन्फिगर करा:

• क्लास-पथमध्ये प्रज्वलित-कंप्रेशन मॉड्यूल असणे आवश्यक आहे. डीफॉल्टनुसार, ते libs/वैकल्पिक निर्देशिकेतील Apache Ignite वितरणामध्ये स्थित आहे आणि क्लास-पथमध्ये समाविष्ट केलेले नाही. तुम्ही डिरेक्टरीला एका स्तरावर libs वर हलवू शकता आणि नंतर जेव्हा तुम्ही ती ignite.sh द्वारे चालवाल तेव्हा ती आपोआप सक्षम होईल.
• चिकाटी सक्षम करणे आवश्यक आहे (द्वारे सक्षम DataRegionConfiguration.setPersistenceEnabled(true)).
• पृष्ठाचा आकार फाइल सिस्टम ब्लॉक आकारापेक्षा मोठा असणे आवश्यक आहे (तुम्ही ते वापरून सेट करू शकता DataStorageConfiguration.setPageSize() ).
• प्रत्येक कॅशेसाठी ज्याचा डेटा संकुचित करणे आवश्यक आहे, तुम्ही कॉम्प्रेशन पद्धत आणि (पर्यायी) कॉम्प्रेशन पातळी (पद्धती) कॉन्फिगर करणे आवश्यक आहे. CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).

WAL कॉम्पॅक्शन

या कसे कार्य करते

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

WAL मधील नोंदी तार्किक आणि भौतिक मध्ये विभागल्या जातात. बुलियन हे स्वतःच की आणि मूल्ये आहेत. भौतिक - पृष्ठ स्टोअरमधील पृष्ठांमधील बदल प्रतिबिंबित करते. तार्किक नोंदी इतर काही प्रकरणांसाठी उपयुक्त ठरू शकतात, भौतिक नोंदी केवळ क्रॅश झाल्यास पुनर्प्राप्तीसाठी आवश्यक असतात आणि नोंदी केवळ शेवटच्या यशस्वी चेकपॉईंटपासून आवश्यक असतात. येथे आम्ही तपशीलात जाणार नाही आणि हे असे का कार्य करते हे स्पष्ट करणार नाही, परंतु ज्यांना स्वारस्य आहे ते अपाचे इग्नाइट विकीवर आधीच नमूद केलेल्या लेखाचा संदर्भ घेऊ शकतात: प्रज्वलित पर्सिस्टंट स्टोअर - हुड अंतर्गत.

प्रति तार्किक रेकॉर्ड अनेकदा अनेक भौतिक रेकॉर्ड आहेत. म्हणजेच, उदाहरणार्थ, कॅशेमध्ये एक पुट ऑपरेशन पृष्ठ मेमरीमधील अनेक पृष्ठांवर परिणाम करते (स्वतः डेटा असलेले पृष्ठ, अनुक्रमणिका असलेली पृष्ठे, फ्री-लिस्ट असलेली पृष्ठे). काही सिंथेटिक चाचण्यांमध्ये, मला आढळले की भौतिक नोंदी WAL फाइलच्या 90% पर्यंत व्यापलेल्या आहेत. तथापि, ते फारच कमी वेळेसाठी आवश्यक आहेत (डीफॉल्टनुसार, चेकपॉइंट्समधील मध्यांतर 3 मिनिटे आहे). या डेटाची प्रासंगिकता गमावल्यानंतर त्यातून मुक्त होणे तर्कसंगत असेल. डब्ल्यूएएल कॉम्पॅक्शन मेकॅनिझम नेमके हेच करते: ते फिजिकल रेकॉर्ड्सपासून मुक्त होते आणि zip वापरून उर्वरित लॉजिकल रेकॉर्ड्स कॉम्प्रेस करते, तर फाइलचा आकार खूप लक्षणीयरीत्या कमी केला जातो (कधीकधी दहापटीने).

भौतिकदृष्ट्या, WAL मध्ये निश्चित आकाराचे (डिफॉल्टनुसार 10) अनेक विभाग असतात (डीफॉल्टनुसार 64MB), जे गोलाकार पद्धतीने ओव्हरराईट केले जातात. वर्तमान विभाग भरताच, पुढील विभाग वर्तमान म्हणून नियुक्त केला जातो आणि भरलेला विभाग वेगळ्या धाग्याद्वारे संग्रहणात कॉपी केला जातो. WAL कॉम्पॅक्शन आधीपासूनच संग्रहण विभागांसह कार्य करते. तसेच, एक वेगळा थ्रेड म्हणून, ते चेकपॉईंटच्या अंमलबजावणीवर लक्ष ठेवते आणि संग्रहण विभागांमध्ये कॉम्प्रेशन सुरू करते ज्यासाठी यापुढे भौतिक रेकॉर्डची आवश्यकता नाही.

कार्यप्रदर्शन प्रभाव

WAL कॉम्पॅक्शन स्वतंत्र थ्रेड म्हणून चालत असल्याने, केल्या जाणाऱ्या ऑपरेशन्सवर थेट परिणाम होऊ नये. परंतु तरीही ते CPU (कंप्रेशन) आणि डिस्कवर अतिरिक्त पार्श्वभूमी भार टाकते (संग्रहणातून प्रत्येक WAL विभाग वाचणे आणि संकुचित विभाग लिहिणे), त्यामुळे जर सिस्टीम त्याच्या जास्तीत जास्त क्षमतेवर चालत असेल, तर यामुळे कार्यक्षमतेतही ऱ्हास होईल.

सक्षम आणि कॉन्फिगर कसे करावे

तुम्ही मालमत्ता वापरून WAL कॉम्पॅक्शन सक्षम करू शकता WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). तसेच, DataStorageConfiguration.setWalCompactionLevel() पद्धत वापरून, तुम्ही डीफॉल्ट मूल्य (BEST_SPEED) सह समाधानी नसल्यास, तुम्ही कॉम्प्रेशन लेव्हल सेट करू शकता.

WAL पृष्ठ स्नॅपशॉट कॉम्प्रेशन

या कसे कार्य करते

आम्हाला आधीच आढळले आहे की डब्ल्यूएएल रेकॉर्डमध्ये तार्किक आणि भौतिक विभागलेले आहेत. प्रत्येक पृष्ठावरील प्रत्येक बदलासाठी, पृष्ठ मेमरीमध्ये एक भौतिक WAL रेकॉर्ड तयार केला जातो. भौतिक नोंदी देखील 2 उपप्रकारांमध्ये विभागल्या जातात: पृष्ठ स्नॅपशॉट रेकॉर्ड आणि डेल्टा रेकॉर्ड. प्रत्येक वेळी जेव्हा आपण पृष्ठावर काहीतरी बदलतो आणि स्वच्छ स्थितीतून गलिच्छ स्थितीत स्थानांतरित करतो, तेव्हा या पृष्ठाची संपूर्ण प्रत WAL (पृष्ठ स्नॅपशॉट रेकॉर्ड) मध्ये संग्रहित केली जाते. जरी आम्ही WAL मध्ये फक्त एक बाइट बदलला तरीही रेकॉर्ड पृष्ठ आकारापेक्षा थोडा मोठा असेल. जर आपण आधीच गलिच्छ पृष्ठावर काहीतरी बदलले तर, WAL मध्ये डेल्टा रेकॉर्ड तयार केला जातो, जो पृष्ठाच्या मागील स्थितीच्या तुलनेत केवळ बदल प्रतिबिंबित करतो, परंतु संपूर्ण पृष्ठ नाही. चेकपॉईंटच्या प्रक्रियेदरम्यान पृष्ठांची स्थिती गलिच्छ ते स्वच्छ करण्यासाठी रीसेट केली जात असल्याने, चेकपॉईंट सुरू झाल्यानंतर लगेचच, जवळजवळ सर्व भौतिक नोंदींमध्ये पृष्ठांच्या स्नॅपशॉट्सचा समावेश असेल (चेकपॉईंट सुरू झाल्यानंतर लगेचच सर्व पृष्ठे स्वच्छ असल्याने) , नंतर जसे आपण पुढील चेकपॉईंटजवळ जातो, डेल्टा रेकॉर्ड फ्रॅक्शन वाढू लागतो आणि पुढील चेकपॉईंटच्या सुरूवातीस पुन्हा रीसेट होतो. काही सिंथेटिक चाचण्यांमधील मोजमापांनी दाखवले की एकूण भौतिक नोंदींमध्ये पृष्ठ स्नॅपशॉटचा वाटा 90% पर्यंत पोहोचतो.

WAL पेज स्नॅपशॉट कॉम्प्रेशनची कल्पना तयार पेज कॉम्प्रेशन टूल वापरून पेज स्नॅपशॉट कॉम्प्रेस करणे आहे (डिस्क पेज कॉम्प्रेशन पहा). त्याच वेळी, डब्ल्यूएएलमध्ये, रेकॉर्ड केवळ-अपेंड मोडमध्ये अनुक्रमे जतन केले जातात आणि फाइल सिस्टम ब्लॉक्सच्या सीमांवर रेकॉर्ड बांधण्याची आवश्यकता नाही, म्हणून येथे, डिस्क पृष्ठ कॉम्प्रेशन मेकॅनिझमच्या विपरीत, आम्हाला येथे विरळ फाइल्सची आवश्यकता नाही. सर्व; त्यानुसार, ही यंत्रणा केवळ ओएस लिनक्सवरच कार्य करणार नाही. याव्यतिरिक्त, आम्ही पृष्ठ किती संकुचित करू शकलो हे आमच्यासाठी महत्त्वाचे नाही. जरी आम्ही 1 बाइट मुक्त केले तरीही, हा आधीच एक सकारात्मक परिणाम आहे आणि आम्ही डिस्क पृष्ठ कॉम्प्रेशनच्या विपरीत, WAL मध्ये संकुचित डेटा जतन करू शकतो, जेथे आम्ही 1 पेक्षा जास्त फाइल सिस्टम ब्लॉक मुक्त केले तरच आम्ही संकुचित पृष्ठ जतन करतो.

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

डिस्क पेज कॉम्प्रेशन प्रमाणे, WAL पेज स्नॅपशॉट कॉम्प्रेशन ZSTD, LZ4, स्नॅपी कॉम्प्रेशन अल्गोरिदम, तसेच SKIP_GARBAGE मोड वापरू शकते.

कार्यप्रदर्शन प्रभाव

हे लक्षात घेणे कठीण नाही की थेट WAL पृष्ठ स्नॅपशॉट कॉम्प्रेशन सक्षम केल्याने केवळ थ्रेड्सवर परिणाम होतो जे पृष्ठ मेमरीवर डेटा लिहितात, म्हणजेच ते थ्रेड्स जे कॅशेमध्ये डेटा बदलतात. WAL कडून भौतिक नोंदी वाचणे केवळ एकदाच होते, ज्या क्षणी नोड पडल्यानंतर वाढतो (आणि तो चेकपॉईंट दरम्यान पडला तरच).

हे खालील प्रकारे डेटा बदलणार्‍या थ्रेड्सवर परिणाम करते: डिस्कवर लिहिण्यापूर्वी प्रत्येक वेळी पृष्ठ संकुचित करण्याची आवश्यकता असल्यामुळे आम्हाला नकारात्मक प्रभाव (CPU) मिळतो आणि एक सकारात्मक प्रभाव (डिस्क IO) कमी झाल्यामुळे डेटा लिहिलेला. त्यानुसार, येथे सर्व काही सोपे आहे: जर सिस्टम कार्यप्रदर्शन CPU द्वारे मर्यादित असेल, तर आम्हाला थोडीशी निकृष्टता मिळेल, जर ते डिस्क I/O द्वारे मर्यादित असेल तर आम्हाला वाढ मिळेल.

अप्रत्यक्षपणे, WAL आकार कमी केल्याने (सकारात्मक) प्रवाहांवर देखील परिणाम होतो जे WAL विभागांना संग्रहण आणि WAL कॉम्पॅक्शन स्ट्रीममध्ये टाकतात.

सिंथेटिक डेटा वापरून आमच्या वातावरणातील वास्तविक कार्यप्रदर्शन चाचण्यांमध्ये थोडीशी वाढ दिसून आली (थ्रूपुट 10%-15% ने वाढली, लेटन्सी 10%-15% ने कमी झाली).

सक्षम आणि कॉन्फिगर कसे करावे

किमान अपाचे इग्नाइट आवृत्ती: 2.8. खालीलप्रमाणे सक्षम आणि कॉन्फिगर करा:

• क्लास-पथमध्ये प्रज्वलित-कंप्रेशन मॉड्यूल असणे आवश्यक आहे. डीफॉल्टनुसार, ते libs/वैकल्पिक निर्देशिकेतील Apache Ignite वितरणामध्ये स्थित आहे आणि क्लास-पथमध्ये समाविष्ट केलेले नाही. तुम्ही डिरेक्टरीला एका स्तरावर libs वर हलवू शकता आणि नंतर जेव्हा तुम्ही ती ignite.sh द्वारे चालवाल तेव्हा ती आपोआप सक्षम होईल.
• चिकाटी सक्षम करणे आवश्यक आहे (द्वारे सक्षम DataRegionConfiguration.setPersistenceEnabled(true)).
• पद्धत वापरून कॉम्प्रेशन मोड सेट करणे आवश्यक आहे DataStorageConfiguration.setWalPageCompression(), कॉम्प्रेशन डीफॉल्टनुसार अक्षम केले आहे (अक्षम मोड).
• वैकल्पिकरित्या, तुम्ही पद्धत वापरून कॉम्प्रेशन लेव्हल सेट करू शकता DataStorageConfiguration.setWalPageCompression(), प्रत्येक मोडसाठी वैध मूल्यांसाठी पद्धतीसाठी javadoc पहा.

निष्कर्ष

Apache Ignite मधील विचारात घेतलेल्या डेटा कॉम्प्रेशन मेकॅनिझमचा स्वतंत्रपणे वापर केला जाऊ शकतो, परंतु त्यांचे कोणतेही संयोजन देखील स्वीकार्य आहे. ते कसे कार्य करतात हे समजून घेतल्याने ते आपल्या वातावरणातील आपल्या कार्यांसाठी किती योग्य आहेत आणि ते वापरताना आपल्याला काय त्याग करावे लागेल हे निर्धारित करण्यास अनुमती देईल. डिस्क पेज कॉम्प्रेशन हे मुख्य स्टोरेज कॉम्प्रेस करण्यासाठी डिझाइन केले आहे आणि ते मध्यम कॉम्प्रेशन रेशो देऊ शकते. WAL पृष्ठ स्नॅपशॉट कॉम्प्रेशन WAL फाइल्ससाठी सरासरी कम्प्रेशन देईल आणि बहुधा कार्यप्रदर्शन सुधारेल. WAL कॉम्पॅक्शनचा कार्यक्षमतेवर सकारात्मक परिणाम होणार नाही, परंतु भौतिक नोंदी काढून WAL फाइल्सचा आकार शक्य तितका कमी करेल.

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