लोकप्रिय एंटीपैटर्न: पेजिनेशन

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

समस्या

इसलिए, हमें क्वेरी "पेजिनेशन" के लिए सभी संदेशों को जारी करने की आवश्यकता है, जो कि सबसे हालिया ( शीर्ष से अंतिम वाले बदल गए ) या कुछ पेचीदा क्रम से शुरू होता है। सब कुछ ठीक है, जब तक हमारे पास इन संदेशों में से सौ से कम हैं - हम सिर्फ डेटाबेस से चयन करते हैं और डेटा वापस करते हैं:

ग्राहक से अनुरोध:

GET /message/text=/ 

डेटाबेस अनुरोध:

 SELECT FROM Message WHERE text LICENE "" ORDER BY changed DESC 

ग्राहक के लिए JSON प्रतिक्रिया योजना:

 Array<{ id : number , text : string }> 

लेकिन संदेशों की संख्या बढ़ रही है और हमें निम्नलिखित परेशानियाँ हैं:

1. डेटाबेस क्वेरीज़ धीमी होती जा रही हैं क्योंकि अधिक डेटा को स्कूप किया जाना है।
2. नेटवर्क पर डेटा भेजने में अधिक से अधिक समय लग रहा है।
3. क्लाइंट पर इस डेटा का प्रतिपादन लंबा और लंबा हो रहा है।

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

सबसे सरल समाधान, जो शायद पहले मन में आता है, और आप इसे अब किसी भी टोस्टर में मिल सकते हैं - डेटा को थोक में नहीं देने के लिए, लेकिन पृष्ठों में टूट गया। बस हमें क्लाइंट से डेटाबेस अनुरोध में एक अतिरिक्त पैरामीटर फेंकना होगा:

 GET /message/text=/page=5/ 

 SELECT FROM Message WHERE text LICENE "" ORDER BY changed DESC SKIP 5 * 10 LIMIT 10 

 SELECT count(*) FROM Message WHERE text LICENE "" 

 { pageItems : Array<{ id : number , text : string }> totalCount : number } 

ठीक है, हाँ, हमें अभी भी सभी संदेशों को फिर से लिखना था ताकि ग्राहक पृष्ठों की एक सूची बना सके या वर्चुअल स्क्रॉल की ऊंचाई की गणना कर सके, लेकिन कम से कम हमें डेटाबेस से इन सभी 100500 संदेशों को प्राप्त करने की आवश्यकता नहीं थी।

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

1. अगले पृष्ठ पर, संदेश फिर से दिखाई दे सकते हैं जो पहले से ही पिछले थे।
2. उपयोगकर्ता को कुछ संदेश दिखाई नहीं देंगे, क्योंकि वे 5 से 6 तक उपयोगकर्ता के संक्रमण के बीच पेज 6 से 5 पर जाने में सफल रहे।

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

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

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

जैसा कि आप देख सकते हैं, पेजिनेशन में कई समस्याएं हैं। क्या वास्तव में कोई बेहतर उपाय नहीं है?

निर्णय

सबसे पहले, आइए ध्यान दें कि डेटाबेस के साथ काम करते समय 2 ऑपरेशन हैं जो अनिवार्य रूप से अलग हैं:

1. खोजें। कुछ क्वेरी के लिए डेटा को पॉइंटर्स खोजने का अपेक्षाकृत भारी संचालन।
2. सैम्पलिंग। वास्तव में डेटा प्राप्त करने का एक अपेक्षाकृत सरल ऑपरेशन।

यह आदर्श होगा:

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

स्नैपशॉट कहाँ संग्रहीत करें? 2 विकल्प हैं:

1. सर्वर पर। लेकिन फिर हम इसे खोज परिणामों के साथ कचरे के एक समूह के साथ बंद कर देते हैं जिन्हें समय के साथ साफ करने की आवश्यकता होती है।
2. ग्राहक को। लेकिन फिर आपको तुरंत ग्राहक को सभी स्नैपशॉट स्थानांतरित करना होगा।

चलो स्नैपशॉट के आकार का अनुमान लगाते हैं, जो कि केवल पहचानकर्ताओं की एक सूची है। यह संदिग्ध है कि उपयोगकर्ता के पास फ़िल्टरिंग और सॉर्टिंग का उपयोग किए बिना कम से कम 100 पृष्ठों को रोल करने का धैर्य था। मान लीजिए कि हमारे पास प्रति पृष्ठ 20 तत्व हैं। प्रत्येक पहचानकर्ता जोंस प्रतिनिधित्व में 10 से अधिक बाइट्स नहीं लेंगे। गुणा करें और 20kb से अधिक न लें। और बहुत कम होने की संभावना है। 1000 तत्वों में, आउटपुट के आकार पर एक कठिन सीमा निर्धारित करना उचित होगा।

 GET /message/text=/ 

 SELECT id FROM Message WHERE text LICENE "" ORDER BY changed DESC LIMIT 1000 

 Array<number> 

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

 GET /message=49,48,47,46,45,42,41,40,39,37/ 

 SELECT FROM Message WHERE id IN [49,48,47,46,45,42,41,40,39,37] 

 Array< { id : number , text : string } | { id : number , error : string } > 

अंततः हमें क्या मिलता है:

1. सामान्यीकृत एपीआई: अलग से खोज, अलग से डेटा का चयन करें।
2. खोज प्रश्नों की संख्या कम से कम करें।
3. आप पहले से डाउनलोड किए गए डेटा का अनुरोध नहीं कर सकते हैं, या इसे पृष्ठभूमि में अपडेट कर सकते हैं।
4. क्लाइंट साइड पर अपेक्षाकृत सरल और सार्वभौमिक कोड।

कमियों में से, इसे छोड़कर नोट किया जा सकता है:

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