किसी बड़े collection endpoint को आप कैसे paginate करेंगे, और सीधे limit और offset क्यों नहीं?

keyset pagination को तरजीह दें, जिसे cursor pagination भी कहते हैं: किसी स्थिर unique key पर order करें, आखिरी row के लिए एक opaque cursor लौटाएं और उसके बाद वाली rows मांगें। offset pagination में डेटाबेस को हर छोड़ी गई row पढ़कर फेंकनी पड़ती है, इसलिए पांच हज़ारवां पेज धीमा होता है, और scroll के बीच में insert या delete हुई rows से duplicates और gaps बनते हैं। keyset हर पेज पर लगभग एक जैसा समय लेता है और writes के बीच भी स्थिर रहता है।

मेरा डिफ़ॉल्ट keyset है। क्लाइंट एक पेज मांगता है, उसे items के साथ एक opaque cursor मिलता है, और अगली request कहती है कि इस cursor के बाद वाली rows दो। अंदर से यह sort key पर एक where clause है, इसलिए सही index के साथ यह एक index seek है और पहले पेज तथा हज़ारवें पेज की लागत बराबर रहती है। offset ऐसा नहीं कर सकता, क्योंकि डेटाबेस को offset से पहले वाला सब कुछ चलकर फेंकना ही पड़ता है, और इससे भी बुरा यह कि किसी के scroll करते वक्त अगर एक row insert हो जाए तो उसके आगे के सब पेज खिसक जाते हैं और उसे या तो duplicate दिखता है या कोई item छूट जाता है। जो बात लोगों को फंसाती है वह है tiebreaker: अगर मैं created at पर sort करूं और दो rows का timestamp एक ही हो, तो क्रम deterministic नहीं रहता, इसलिए cursor created at के साथ id भी encode करता है और तुलना उस जोड़े पर होती है। मैं जो खोता हूं वह है मनमाने पेज पर छलांग और सस्ते total counts। infinite scroll वाली feed में इनकी कमी किसी को नहीं खलती; जिस admin टेबल को पेज नंबर चाहिए, वहां मैं एक तय अधिकतम सीमा के साथ offset इस्तेमाल कर लूंगा।