मुझे मुख्य पृष्ठांकन के लिए वाद्य समर्थन की आवश्यकता क्यों है

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

हमारी टीम अक्सर DBMS में क्वेरी ऑप्टिमाइज़ेशन का प्रश्न उठाती है। आप हमेशा थोड़ा तेज़ चाहते हैं, लेकिन आप हमेशा अच्छी तरह से डिज़ाइन किए गए इंडेक्स के साथ नहीं मिल सकते हैं - आपको कुछ वर्कअराउंड की तलाश करनी होगी। डेटाबेस के साथ काम करने के दौरान उचित अनुकूलन की तलाश में नेट के आसपास इन भटकने के दौरान, मैंने SQL प्रदर्शन समझाया मार्कस विनंद के असीम रूप से उपयोगी ब्लॉग पाया। यह बहुत ही दुर्लभ प्रकार का ब्लॉग है जहाँ आप एक पंक्ति में सभी लेख पढ़ सकते हैं।

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

कुछ स्थानों पर मैं लेखक को स्पष्टीकरण और टिप्पणियों के साथ पूरक करूंगा। मैं ऐसे सभी स्थानों को "लगभग।" स्पष्टता के लिए नामित करूंगा।

छोटा सा परिचय

मुझे लगता है कि बहुत से लोग जानते हैं कि ऑफसेट के माध्यम से योनि चयन के साथ काम करना कितना समस्याग्रस्त और निरोधात्मक है। लेकिन क्या आप जानते हैं कि इसे काफी अधिक उत्पादक डिजाइन के साथ बदला जा सकता है।

इसलिए, ऑफ़सेट कीवर्ड डेटाबेस को अनुरोध में पहले n प्रविष्टियों को छोड़ने के लिए कहता है। हालाँकि, डेटाबेस को अभी भी डिस्क से इन पहले n रिकॉर्ड्स को पढ़ना है, और निर्दिष्ट क्रम में (ध्यान दें: यदि कोई निर्दिष्ट किया गया है तो छंटाई लागू करें), और उसके बाद ही n + 1 से शुरू होने वाले रिकॉर्ड को वापस करना संभव होगा। सबसे दिलचस्प बात यह है कि समस्या DBMS में ठोस कार्यान्वयन में नहीं है, लेकिन मानक द्वारा प्रारंभिक परिभाषा में:

... पंक्तियों को पहले <खंड के द्वारा आदेश के अनुसार क्रमबद्ध किया जाता है> और फिर शुरुआत में <परिणाम ऑफसेट खंड> में निर्दिष्ट पंक्तियों की संख्या को गिराकर सीमित किया जाता है ...
-SQL: 2016, भाग 2, 4.15.3 व्युत्पन्न टेबल (ध्यान दें: अब सबसे अधिक इस्तेमाल किया जाने वाला मानक)

यहाँ मुख्य बिंदु यह है कि ऑफसेट एक एकल पैरामीटर लेता है - रिकॉर्ड करने की संख्या, और इसे। इस परिभाषा के बाद, एक DBMS केवल सभी रिकॉर्ड प्राप्त कर सकता है और फिर अनावश्यक लोगों को छोड़ सकता है। जाहिर है, ऑफसेट की ऐसी परिभाषा आपको अतिरिक्त काम करने के लिए मजबूर करती है। और यह SQL या NoSQL है, तो भी कोई फर्क नहीं पड़ता।

कुछ और दर्द

ऑफसेट समस्याएं समाप्त नहीं होती हैं, और यहाँ क्यों है। यदि कोई अन्य ऑपरेशन डिस्क से डेटा के दो पेज पढ़ने के बीच एक नया रिकॉर्ड सम्मिलित करता है, तो इस मामले में क्या होगा?

जब ऑफसेट का उपयोग पिछले पृष्ठों से रिकॉर्ड को छोड़ने के लिए किया जाता है, तो विभिन्न पृष्ठों को पढ़ने पर संचालन के बीच एक नया रिकॉर्ड जोड़ने की स्थिति में, सबसे अधिक संभावना है कि आपको डुप्लिकेट मिलेगा (ध्यान दें: यह तब संभव है जब हम पृष्ठ द्वारा पृष्ठ का उपयोग करके क्रम से खंड का उपयोग करते हैं, तो हमारे आउटपुट के मध्य में हो सकता है एक नया रिकॉर्ड प्राप्त करें)।

आंकड़ा स्पष्ट रूप से ऐसी स्थिति को दर्शाता है। आधार पहले 10 रिकॉर्ड पढ़ता है, जिसके बाद एक नया रिकॉर्ड डाला जाता है, जो 1. द्वारा सभी पढ़े गए रिकॉर्ड को स्थानांतरित कर देता है। फिर आधार अगले 10 रिकॉर्ड से एक नया पेज लेता है और 11 वें से शुरू नहीं होता है, लेकिन 10 वीं से, इस रिकॉर्ड को दोहराता है। इस अभिव्यक्ति के उपयोग से जुड़ी अन्य विसंगतियां हैं, लेकिन यह सबसे आम है।

जैसा कि हम पहले ही पता लगा चुके हैं, ये किसी विशेष डीबीएमएस या उनके कार्यान्वयन की समस्याएं नहीं हैं। समस्या SQL मानक के अनुसार पृष्ठांकन की परिभाषा है। हम DBMS को बताते हैं कि किस पेज को छोड़ना है या कितने रिकॉर्ड छोड़ना है। आधार केवल इस तरह के अनुरोध को अनुकूलित करने में सक्षम नहीं है, क्योंकि इसके लिए बहुत कम जानकारी है।

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

• ऑफसेट कीवर्ड, जैसा कि पहले उल्लेख किया गया है।
• दो कीवर्ड सीमा [ऑफसेट] का निर्माण (हालांकि सीमा खुद इतनी बुरी नहीं है)।
• लाइन नंबरिंग के आधार पर निचली सीमा द्वारा फ़िल्टर करना (उदा। Row_number (), rownum, आदि)।

इन सभी अभिव्यक्तियों में केवल यह कहा जाता है कि कितनी लाइनें छोड़नी हैं, कोई अतिरिक्त जानकारी या संदर्भ नहीं।

बाद में इस लेख में, ऑफसेट कीवर्ड का उपयोग इन सभी विकल्पों के सामान्यीकरण के रूप में किया जाता है।

बिना OFFSET के जीवन

अब कल्पना कीजिए कि इन सभी समस्याओं के बिना हमारी दुनिया कैसी होगी। यह पता चला है कि ऑफसेट के बिना जीवन इतना जटिल नहीं है: आप केवल उन पंक्तियों का चयन कर सकते हैं जिन्हें हमने नहीं देखा है (ध्यान दें: अर्थात, जो अंतिम पृष्ठ पर नहीं थे) उस स्थिति का उपयोग करके जहां।

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

SELECT ... FROM ... WHERE ... AND id < ?last_seen_id ORDER BY id DESC FETCH FIRST 10 ROWS ONLY 

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

इस दृष्टिकोण को सीक विधि या कीसेट पेजिंग कहा जाता है। यह एक अस्थायी परिणाम के साथ समस्या को हल करता है (ध्यान दें: पृष्ठ के बीच लिखने के साथ स्थिति, पहले से वर्णित है) और निश्चित रूप से, कि हम सभी प्यार करते हैं, क्लासिक ऑफसेट की तुलना में तेजी से और अधिक स्थिर काम करते हैं। स्थिरता इस तथ्य में निहित है कि क्वेरी प्रोसेसिंग का समय अनुरोधित तालिका की संख्या के अनुपात में नहीं बढ़ता है (नोट: यदि आप पृष्ठांकन के विभिन्न तरीकों के काम के बारे में अधिक जानकारी चाहते हैं, तो आप लेखक की प्रस्तुति के माध्यम से देख सकते हैं । आप विभिन्न तरीकों का उपयोग करके तुलनात्मक बेंचमार्क भी देख सकते हैं)।

स्लाइड्स में से एक यह बताता है कि कुंजी पृष्ठांकन, ज़ाहिर है, सर्वशक्तिमान नहीं है - इसकी अपनी सीमाएँ हैं। सबसे महत्वपूर्ण - वह यादृच्छिक पृष्ठों (नोट: असंगत) को पढ़ने की क्षमता नहीं रखता है। हालांकि, अंतहीन स्क्रॉलिंग के युग में (नोट: सामने के छोर पर), यह ऐसी समस्या नहीं है। यूआई विकसित करते समय एक क्लिक के लिए पृष्ठ संख्या निर्दिष्ट करना किसी भी मामले में एक बुरा निर्णय है (नोट: लेख के लेखक की राय)।

साधनों के बारे में क्या?

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

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

हालाँकि, कुंजी पृष्ठांकन का समर्थन करने वाले ढाँचों की संख्या धीरे-धीरे बढ़ रही है। यहाँ इस समय क्या है:

• जावा के लिए jOOQ ;
• Ruby के लिए order_query ;
• Chunkator और Django के लिए अनंत स्क्रॉल पृष्ठांकन ;
• पायथन के लिए एसक्यूएल अल्केमी स्क्वैलेसीट ;
• ब्लेज़-दृढ़ता - जेपीए कार्यान्वयन के लिए मापदंड एपीआई;
• DBIx :: वर्ग :: पर्ल के लिए आवरण ;
• Massive.js , Node.js कीसेट प्रलेखन के लिए एक मैपर।

(नोट: कुछ लिंक इस तथ्य के कारण हटा दिए गए थे कि अनुवाद के समय कुछ पुस्तकालयों को 2017-2018 से अपडेट नहीं किया गया था। अगर दिलचस्पी है, तो आप स्रोत को देख सकते हैं।)

यह इस समय है कि आपकी सहायता की आवश्यकता है। यदि आप किसी ऐसे फ्रेमवर्क का विकास या समर्थन कर रहे हैं जो किसी तरह से पेजेशन का उपयोग करता है, तो मैं पूछता हूं, मैं आग्रह करता हूं, मैं आपसे प्रार्थना करता हूं कि आप पेजिंग के लिए मूल समर्थन करें। यदि आपके पास प्रश्न हैं या मदद की आवश्यकता है, तो मुझे मदद करने में खुशी होगी ( मंच , ट्विटर , संपर्क फ़ॉर्म ) (नोट: मार्कस के साथ मेरे अनुभव में, मैं कह सकता हूं कि वह वास्तव में इस विषय को फैलाने के बारे में उत्साही है)।

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

निष्कर्ष

मुख्य पृष्ठांकन के रूप में इस तरह के एक सरल और उपयोगी दृष्टिकोण व्यापक नहीं है कि यह तकनीकी कार्यान्वयन में मुश्किल नहीं है या किसी महान प्रयास की आवश्यकता नहीं है। मुख्य कारण यह है कि कई का उपयोग ऑफसेट के साथ देखने और काम करने के लिए किया जाता है - यह दृष्टिकोण मानक द्वारा ही निर्धारित किया जाता है।

नतीजतन, कुछ लोग पृष्ठांकन के लिए दृष्टिकोण को बदलने के बारे में सोचते हैं, और इसके कारण, चौखटे और पुस्तकालयों से वाद्य समर्थन खराब रूप से विकसित हो रहा है। इसलिए, यदि आप बिना किसी उपद्रव के विचार और लक्ष्य के करीब हैं, तो इसे फैलाने में मदद करें!

स्रोत: https://use-the-index-luke.com/no-offset
द्वारा पोस्ट: मार्कस Winand