Cursor-आधारित Pagination क्या है? Tokens और Tradeoffs
Scrapeless Agent Browser आपकी automation को dynamic result interfaces में नेविगेट करने देता है, जबकि आपका application pagination state और एकत्र किए गए records को ट्रैक करता है।
संक्षेप में
- एक cursor एक continuation position की पहचान करता है। Token को opaque ही मानें, जब तक API उसकी संरचना को स्पष्ट रूप से document न करे।
- Stable ordering के लिए एक deterministic tie-breaker ज़रूरी होता है। केवल timestamp उन records में अंतर नहीं कर सकता जो एक ही क्षण पर बनाए गए हों।
- Cursor pagination किसी snapshot का संकेत नहीं देती। समकालिक inserts, deletes, और updates अब भी service के consistency contract पर निर्भर करते हैं।
- एक checkpoint में cursor के साथ‑साथ query भी शामिल होती है। Committed continuation state को आगे बढ़ाने से पहले records को संग्रहीत करें।
एक Cursor किसी विशिष्ट Ordered Query को आगे बढ़ाता है
Cursor-आधारित pagination किसी result set को पन्नों में बाँटती है और client को एक ऐसी position देती है जहाँ से वह आगे बढ़ सके। Server से निश्चित संख्या में records को skip करने के लिए कहने के बजाय, client पिछले response से मिला continuation value वापस भेजता है। Server उस value की व्याख्या query के ordering और filtering नियमों के संदर्भ में करता है। इसलिए किसी विशेष collection traversal के संबंध में ही cursor का अर्थ होता है।
शब्द cursor किसी एक सार्वभौमिक parameter नाम या data structure को निर्धारित नहीं करता। एक REST API next-page token या next link दिखा सकती है, जबकि कोई GraphQL connection edge cursors और page information दिखा सकता है। Loop बनाने से पहले चुनी गई API का contract पढ़ें। कोई client जो cursor नाम का parameter अनुमान से भेजता है, वह एक वैध HTTP request भेज सकता है जिसे service इच्छित pagination operation से अलग तरह से समझ लेती है।
AIP-158 page-token guidance page tokens को opaque मानती है और continuation को अन्य request arguments से बाँधती है। यह डिज़ाइन client को backend के आंतरिक representation से स्वतंत्र रखता है। Token किसी position को encode कर सकता है, server-side state का संदर्भ दे सकता है, या सुरक्षित query विवरण ले जा सकता है। उसके दिखने से यह सिद्ध नहीं होता कि service कौन‑सा तंत्र उपयोग कर रही है, और client को सही तरह से आगे बढ़ने के लिए यह जानने की ज़रूरत नहीं होनी चाहिए।Deterministic Ordering क्यों महत्वपूर्ण है
Deterministic order हर record को continuation boundary के सापेक्ष एक निश्चित position देता है। किसी non-unique timestamp के आधार पर sorting करने से कई records पेज की सीमा पर tie हो सकते हैं। एक सामान्य keyset डिज़ाइन sort order में एक immutable unique identifier जोड़ता है, ताकि boundary एक पूर्ण ordering key को संदर्भित करे। सटीक चुनाव database और application के data model पर निर्भर करता है।
कल्पना करें कि कोई काल्पनिक feed creation time और record ID के आधार पर क्रमबद्ध है। अगला page वर्तमान page की अंतिम जोड़ी के बाद से, उसी ordering दिशा में शुरू होता है। यदि कई records का creation time समान है, तो ID यह निर्धारित करती है कि किन्हें पहले ही देखा जा चुका है। यह एक वैचारिक उदाहरण है, न कि किसी Scrapeless endpoint का वर्णन या किसी विशिष्ट database execution plan के बारे में वादा।
The PostgreSQL ordering guidance समझाती है कि सीमित query परिणामों के लिए अनुमानित (predictable) order क्यों आवश्यक है और क्यों skipped offset rows के लिए भी server को काम करना पड़ता है। कोई उपयुक्त index एक प्रभावी keyset lookup का समर्थन कर सकता है, लेकिन केवल cursor pagination यह साबित नहीं करती कि वह index मौजूद है। जब आप अपने द्वारा संचालित backend का आकलन करें, तो वास्तविक query plan की जाँच करें; API के parameter नामों से गति का अनुमान न लगाएँ।
Cursor, Offset, और Keyset संबंधित शब्द हैं
Offset pagination किसी position की पहचान इस आधार पर करती है कि कितनी rows skip करनी हैं, जबकि cursor service के token contract के माध्यम से continuation boundary की पहचान करता है। Keyset pagination उस boundary को ordered field values के साथ लागू करने की एक सामान्य database तकनीक है। कोई API अंदरूनी तौर पर अलग तरीका उपयोग करते हुए एक opaque cursor उजागर कर सकती है। Performance दावों का मूल्यांकन करते समय public interface और storage algorithm को अलग रखें।
Offset pagination परिचित page-number navigation और किसी चुने हुए offset पर सीधे जाने का समर्थन कर सकती है। Cursor traversal अक्सर क्रमिक continuation को प्राथमिकता देता है और मनमाने page jump का समर्थन न भी करे। न ही कोई interface अपने‑आप कोई सस्ता सटीक total देता है। जैसे page बीस पर कूदना, किसी saved position को सुरक्षित रखना, या पीछे की ओर ब्राउज़ करना—ऐसी product आवश्यकताओं को अनुमान लगाने के बजाय documented API व्यवहार के संदर्भ में आँकना चाहिए।
| Feature | Offset | Cursor |
|---|---|---|
| Position | Skip amount या page number | Server द्वारा प्रदत्त position या link |
| Direct jumps | अक्सर सीमाओं के भीतर समर्थित | सिर्फ तभी जब service उन्हें समर्थन दे |
| Data changes | Positions बदल सकते हैं | Order और consistency पर निर्भर करता है |
| Client state | Query और page position | Query और opaque cursor |
GraphQL Connections एक विशिष्ट Contract परिभाषित करते हैं
The GraphQL Cursor Connections Specification connection और edge संरचनाएँ, forward और backward pagination arguments, और page information को परिभाषित करती है। उस model में cursors edges से संबंधित होते हैं और page information यह बताती है कि और edges उपलब्ध हैं या नहीं। ये field नाम उस specification की परंपराएँ हैं, हर उस API के लिए अनिवार्य नाम नहीं जो cursor का उपयोग करती है।
Forward traversal आम तौर पर page size और after cursor के संयोजन का उपयोग करती है; backward traversal संबंधित before boundary का उपयोग करती है। Connection specification यह आवश्यक करती है कि edge order उन दोनों दिशाओं में सुसंगत रहे। पीछे की ओर जाते हुए किसी उपयोगकर्ता को collection के business order का बिना स्पष्टीकरण उलटा रूप नहीं मिलना चाहिए। Implementations और clients को इस बात पर सहमत होना होता है कि चर्चा display order की हो रही है या traversal direction की।
पृष्ठ की लंबाई से ही अनुमान लगाने के बजाय प्रलेखित अंत शर्त का उपयोग करें। कुछ APIs अनुरोधित से कम आइटम लौटाते हुए भी निरंतरता प्रदान कर सकती हैं। अन्य अंतिम पृष्ठ को किसी गायब टोकन या false निरंतरता फ़्लैग से परिभाषित करती हैं। बिना दिखाई देने वाले रिकॉर्ड वाली प्रतिक्रिया की भी सावधानी से व्याख्या करनी होती है: अनुमतियाँ, फ़िल्टरिंग और एंडपॉइंट का विशिष्ट pagination व्यवहार यह प्रभावित कर सकते हैं कि वह पृष्ठ क्या दर्शाता है।
एक कर्सर बदलते डेटा सेट को फ्रीज़ नहीं करता
कर्सर‑आधारित pagination अपने आप सभी पृष्ठों को एक जैसा डेटाबेस स्नैपशॉट नहीं देती। कोई सेवा प्रत्येक पृष्ठ का मूल्यांकन मौजूदा डेटा के आधार पर कर सकती है। नए रिकॉर्ड निरंतरता सीमा से पहले दिखाई दे सकते हैं, मौजूदा रिकॉर्ड हटाए जा सकते हैं और परिवर्तनीय sort फ़ील्ड किसी रिकॉर्ड को सीमा के पार ले जा सकते हैं। ये परिवर्तन छूटे हुए या दोहराए गए अवलोकनों का कारण बनते हैं या नहीं, यह इम्प्लीमेंटेशन और उसकी consistency नीति पर निर्भर करता है।
ऐतिहासिक निर्यात के लिए, किसी प्रलेखित स्नैपशॉट, एक्सपोर्ट जॉब या स्थिर ऊपरी सीमा की तलाश करें। लाइव फ़ीड के लिए, परिभाषित करें कि लक्ष्य किसी निश्चित आबादी की गणना करना है या वर्तमान प्रविष्टियों का अवलोकन करना। ये अलग‑अलग कार्य हैं। हाई‑वॉटर मार्क कैप्चर स्कोप को वर्णित करने में मदद कर सकता है, लेकिन इसे केवल वहीं उपयोग करना चाहिए जहाँ स्रोत आवश्यक ordering और फ़िल्टरिंग गारंटी का समर्थन करता हो।
गंतव्य में रिकॉर्ड की पहचान बनाए रखें ताकि दोहराए गए अवलोकनों को पहचाना जा सके। डीडुप्लीकेशन डुप्लिकेट पंक्तियों को रोक सकता है, लेकिन यह साबित नहीं कर सकता कि कोई अनदेखा रिकॉर्ड कभी छूटा ही नहीं। कवरेज की रिपोर्ट स्रोत के स्पष्ट समापन संकेत और कैप्चर की क्वेरी सीमा का उपयोग करके करें। इंटरफ़ेस की पूरी traversal और पूर्ण ऐतिहासिक इन्वेंटरी हमेशा समान कथन नहीं होते।
फ़िल्टर सुरक्षित रखें और चेकपॉइंट्स सावधानी से कमिट करें
किसी निरंतरता टोकन को उसी क्वेरी के साथ चलना चाहिए जिसने उसे उत्पन्न किया हो। संग्रह, फ़िल्टर, sort क्रम और अन्य प्रासंगिक तर्कों को कवर करने वाला क्वेरी फ़िंगरप्रिंट स्टोर करें। यदि उपयोगकर्ता फ़िल्टर बदलता है, तो नया traversal शुरू करें, जब तक कि सेवा विशेष रूप से पुराने टोकन को नई क्वेरी के साथ मिलाने का समर्थन न करती हो। किसी अमान्य टोकन को जाँच के लिए अनुबंध समस्या की तरह मानें, न कि इस सबूत की तरह कि संग्रह खाली है।
पृष्ठ के रिकॉर्ड को अगले निरंतरता state को कमिट करने से पहले कमिट करें। चेकपॉइंट को बताना चाहिए कि वास्तव में क्या टिकाऊ स्टोरेज तक पहुँच चुका है। स्वीकृत रिकॉर्ड की संख्या, अंतिम पूर्ण पृष्ठ की पहचान (जहाँ उपलब्ध हो) और क्या स्रोत ने अधिक डेटा की रिपोर्ट की, इन्हें शामिल करें। संवेदनशील टोकन मानों को साझा लॉग से बाहर रखें; एक अपारदर्शी टोकन में सूचना हो सकती है, भले ही क्लाइंट को उसे निरीक्षण न करने के लिए कहा गया हो।
टोकन का जीवनकाल भी मायने रखता है। सर्वर‑state टोकन समाप्त हो सकता है, और आत्म‑समाहित टोकन किसी प्राधिकरण संदर्भ या साइनिंग नीति से बंधा हो सकता है। लंबी अवधि के निर्यात की योजना बनाने से पहले प्रलेखित retention अवधि पढ़ें। SCIM cursor pagination standard एक विशिष्ट मानकीकृत कर्सर कॉन्ट्रैक्ट दर्शाता है, जिसमें निरंतरता एट्रिब्यूट शामिल हैं; इसके नियमों को असंबंधित APIs पर प्रोजेक्ट नहीं किया जाना चाहिए।
ब्राउज़र इंटरफ़ेस अंतर्निहित कर्सर को छिपा सकते हैं
लोड‑मोर बटन या इनफ़िनिट‑स्क्रॉल सूची आंतरिक रूप से कर्सर का उपयोग कर सकती है, बिना उस कर्सर को पेज URL में दिखाए। दिखाई देने वाला इंटरैक्शन ब्राउज़र का pagination इंटरफ़ेस होता है, जबकि नेटवर्क अनुरोध डेटा निरंतरता को वहन करते हैं। उसी व्यवहार से शुरू करें जिसकी पेज और आपकी प्राधिकृति अनुमति देती है। आंतरिक टोकन न गढ़ें और न ही मान लें कि कोई undocumented एंडपॉइंट एक स्थिर सार्वजनिक अनुबंध है।
Scrapeless Agent Browser अधिकृत परिणाम‑नेविगेशन कार्य के लिए ब्राउज़र वातावरण प्रदान कर सकता है। उस वातावरण को समझने के लिए Agent Browser concepts का उपयोग करें और दृश्य नेविगेशन प्रकारों को अलग करने के लिए browser pagination patterns का उपयोग करें। संग्राहक को अभी भी रिकॉर्ड पहचान, सीमित traversal स्कोप और स्पष्ट stopping शर्त की आवश्यकता होती है।समीक्षा करें Scrapeless pricing जब आप सत्र लागत का अनुमान लगाते हैं, लेकिन डेटा सेट की गुणवत्ता का मूल्यांकन सत्र अवधि से स्वतंत्र रूप से करें। एक काल्पनिक कैटलॉग कैप्चर प्रत्येक दिखाई देने वाले उत्पाद ID को रिकॉर्ड कर सकता है जब पेज नए कार्ड जोड़ता है और तब रुक सकता है जब इंटरफ़ेस अपना अंत संकेतित करे। यह प्रक्रिया देखी गई ब्राउज़र traversal की पुष्टि कर सकती है, बिना अंतर्निहित कैटलॉग के ट्रांज़ैक्शनल स्नैपशॉट का दावा किए।
सही आवश्यकता के लिए कर्सर pagination चुनें
कर्सर pagination तब उपयोगी है जब किसी ordered संग्रह तक अनुक्रमिक पहुँच उत्पाद आवश्यकता के अनुकूल हो। यह उपयुक्त बैकएंड डिज़ाइन में बड़े ऑफ़सेट की लागत से बचा सकती है और पेज नंबरों की तुलना में अधिक स्पष्ट रूप से स्थिर निरंतरता सीमा व्यक्त कर सकती है। यह कम सुविधाजनक है जब उपयोगकर्ताओं को मनमाने पृष्ठ जंप की आवश्यकता हो या जब किसी टिकाऊ निर्यात को टोकन के जीवनकाल से अधिक समय तक टिकना हो।
क्वेरी क्रम, निरंतरता कॉन्ट्रैक्ट, एंड मार्कर, टोकन जीवनकाल और consistency व्यवहार का एक साथ मूल्यांकन करें। संग्रह को बढ़ाने से पहले इन निर्णयों को कंज़्यूमर के स्वीकृति मानदंड में लिखें। अंतिम डेटा सेट की गुणवत्ता इन सभी पर निर्भर करती है। सही ढंग से संभाला गया अपारदर्शी टोकन विश्वसनीय traversal का एक हिस्सा है, जबकि प्राधिकरण, स्टोरेज और कवरेज आस‑पास के अनुप्रयोग की ज़िम्मेदारियाँ बनी रहती हैं।
निष्कर्ष
किसी कर्सर को एक ordered क्वेरी के लिए निरंतरता state की तरह मानें, सेवा की अंत शर्तों को सुरक्षित रखें और आगे बढ़ने से पहले स्टोरेज को कमिट करें। कर्सर pagination कुशल अनुक्रमिक पहुँच का समर्थन कर सकती है, लेकिन एक बचावयोग्य डेटा सेट के लिए स्पष्ट consistency सीमा भी आवश्यक है। लंबी traversal को पूर्ण घोषित करने से पहले उस सीमा की स्थापना करें।
अपना वेब डेटा वर्कफ़्लो बनाएं
Agent Browser का उपयोग डायनेमिक नेविगेशन के लिए करें, जबकि आपका संग्राहक pagination state रिकॉर्ड करे और डेटा सेट कवरेज की पुष्टि करे।
आज ही साइन अप करें और पाएं $5 in free credit — कोई क्रेडिट कार्ड आवश्यक नहीं.
अपना $5 क्रेडिट क्लेम करें →FAQ
क्या कर्सर‑आधारित pagination और keyset pagination एक‑ही चीज़ हैं?
Cursor-आधारित pagination आवश्यक रूप से keyset pagination के समान नहीं है। एक cursor API का continuation interface होता है, जबकि keyset pagination एक database तकनीक है जिसे अक्सर इसे लागू करने के लिए इस्तेमाल किया जाता है। Token अन्य backend तंत्रों को छिपा सकता है, इसलिए केवल interface के आधार पर नहीं, बल्कि implementation के प्रमाणों से दक्षता का आकलन करें।
क्या कोई client एक opaque cursor को decode कर सकता है?
किसी client को opaque cursor को बिना व्याख्या किए गए मान की तरह ही मानना चाहिए। भले ही इसकी सामग्री पढ़ने योग्य लगे, इसे decode करना और उसके स्थान पर नए मान बनाना undocumented internals पर निर्भरता पैदा करता है। Token को ठीक उसी तरह लौटाएँ जैसा API दस्तावेज़ में दिया गया है और संबंधित query settings को सुरक्षित रखें।
क्या cursor pagination हर duplicate या missing record को रोकता है?
Cursor pagination हर duplicate या missing record को नहीं रोकता। Mutable data और प्रति-request consistency अभी भी traversal को प्रभावित कर सकते हैं। Deterministic ordering प्रयोग करें, जहाँ उपलब्ध हो वहाँ documented snapshot boundaries का उपयोग करें, और रिकॉर्ड पहचान को storage में रखें, साथ ही capture की वास्तविक consistency सीमाओं की रिपोर्ट करें।
क्या cursor pagination सीधे किसी भी page पर jump कर सकता है?
Cursor pagination मनमाने page jumps का समर्थन तभी करता है जब service वह क्षमता प्रदान करे। कई cursor interfaces क्रमिक traversal के लिए डिज़ाइन किए गए होते हैं। जिस product को direct page selection की ज़रूरत हो, उसे अपना interface चुनने या ऐसे व्यवहार का वादा करने से पहले API के navigation support की पुष्टि कर लेनी चाहिए।
Pagination checkpoint में क्या होना चाहिए?
एक pagination checkpoint में committed continuation state और वह query definition शामिल होनी चाहिए जिसने इसे उत्पन्न किया है। Storage प्रगति और source के completion signal को भी रिकॉर्ड करें। Checkpoint को केवल तब आगे बढ़ाएँ जब स्वीकार किए गए records store हो चुके हों, और यदि cursor मान संवेदनशील query context को उजागर कर सकते हों तो उन्हें सुरक्षित रखें।