કી પર પૃષ્ઠ ક્રમાંકન માટે તમારે શા માટે ઇન્સ્ટ્રુમેન્ટલ સપોર્ટની જરૂર છે?

કેમ છો બધા! હું જાવા + સ્પ્રિંગમાં માઇક્રો સર્વિસ લખતો બેકએન્ડ ડેવલપર છું. હું Tinkoff ખાતે આંતરિક ઉત્પાદન વિકાસ ટીમોમાંથી એકમાં કામ કરું છું.

અમારી ટીમમાં, DBMS માં ક્વેરીઝને ઑપ્ટિમાઇઝ કરવાનો પ્રશ્ન વારંવાર ઊભો થાય છે. તમે હંમેશા થોડા ઝડપી બનવા માંગો છો, પરંતુ તમે હંમેશા વિચારપૂર્વક બાંધેલા અનુક્રમણિકાઓ સાથે મેળવી શકતા નથી-તમારે કેટલાક ઉકેલો શોધવા પડશે. ડેટાબેસેસ સાથે કામ કરતી વખતે વાજબી ઑપ્ટિમાઇઝેશનની શોધમાં આમાંના એક વેબ પર ભટકતા, મને જાણવા મળ્યું માર્કસ વાયનાન્ડનો અનંત મદદરૂપ બ્લોગ, એસક્યુએલ પરફોર્મન્સના લેખક સમજાવ્યું. આ એવો દુર્લભ પ્રકારનો બ્લોગ છે જેમાં તમે સળંગ તમામ લેખો વાંચી શકો છો.

હું તમારા માટે માર્કસના એક નાનકડા લેખનો અનુવાદ કરવા માંગુ છું. તેને અમુક અંશે મેનિફેસ્ટો કહી શકાય કે જે એસક્યુએલ સ્ટાન્ડર્ડ અનુસાર ઑફસેટ ઑપરેશનની કામગીરીની જૂની, પરંતુ હજુ પણ સંબંધિત સમસ્યા તરફ ધ્યાન દોરવા માંગે છે.

કેટલીક જગ્યાએ હું લેખકને સ્પષ્ટતા અને ટિપ્પણીઓ સાથે પૂરક કરીશ. હું આવા તમામ સ્થળોનો ઉલ્લેખ "આશરે" તરીકે કરીશ. વધુ સ્પષ્ટતા માટે

નાનો પરિચય

મને લાગે છે કે ઘણા લોકો જાણે છે કે ઑફસેટ દ્વારા પૃષ્ઠ પસંદ કરે છે તેની સાથે કેટલું સમસ્યારૂપ અને ધીમું કામ કરે છે. શું તમે જાણો છો કે તેને વધુ કાર્યક્ષમ ડિઝાઇન સાથે સરળતાથી બદલી શકાય છે?

તેથી, ઑફસેટ કીવર્ડ ડેટાબેઝને વિનંતીમાં પ્રથમ n રેકોર્ડ્સ છોડવા માટે કહે છે. જો કે, ડેટાબેઝને હજુ પણ ડિસ્કમાંથી આ પ્રથમ n રેકોર્ડ્સ, આપેલ ક્રમમાં વાંચવાની જરૂર છે (નોંધ: જો તે સ્પષ્ટ કરેલ હોય તો સોર્ટિંગ લાગુ કરો), અને તે પછી જ n+1 થી રેકોર્ડ પરત કરવાનું શક્ય બનશે. સૌથી રસપ્રદ બાબત એ છે કે સમસ્યા DBMS માં ચોક્કસ અમલીકરણમાં નથી, પરંતુ ધોરણ અનુસાર મૂળ વ્યાખ્યામાં છે:

…પંક્તિઓને પહેલા મુજબ સૉર્ટ કરવામાં આવે છે અને પછી માં ઉલ્લેખિત પંક્તિઓની સંખ્યાને શરૂઆતથી છોડીને મર્યાદિત કરવામાં આવે છે...
-SQL:2016, ભાગ 2, 4.15.3 વ્યુત્પન્ન કોષ્ટકો (નોંધ: હાલમાં સૌથી વધુ વપરાતું ધોરણ)

અહીં મુખ્ય મુદ્દો એ છે કે ઑફસેટ એક જ પરિમાણ લે છે - છોડવા માટેના રેકોર્ડ્સની સંખ્યા, અને બસ. આ વ્યાખ્યાને અનુસરીને, DBMS માત્ર તમામ રેકોર્ડ્સ પુનઃપ્રાપ્ત કરી શકે છે અને પછી બિનજરૂરી રેકોર્ડ્સને કાઢી શકે છે. દેખીતી રીતે, ઓફસેટની આ વ્યાખ્યા આપણને વધારાનું કામ કરવા દબાણ કરે છે. અને તે SQL અથવા NoSQL છે તે પણ કોઈ વાંધો નથી.

બસ થોડી વધુ પીડા

ઑફસેટ સાથેની સમસ્યાઓ ત્યાં સમાપ્ત થતી નથી, અને અહીં શા માટે છે. જો, ડિસ્કમાંથી ડેટાના બે પૃષ્ઠો વાંચવા વચ્ચે, અન્ય ઑપરેશન નવો રેકોર્ડ દાખલ કરે છે, તો આ કિસ્સામાં શું થશે?

જ્યારે અગાઉના પૃષ્ઠોમાંથી રેકોર્ડ્સ છોડવા માટે ઑફસેટનો ઉપયોગ કરવામાં આવે છે, ત્યારે વિવિધ પૃષ્ઠોના વાંચન વચ્ચે નવો રેકોર્ડ ઉમેરવાની સ્થિતિમાં, તમને મોટાભાગે ડુપ્લિકેટ્સ મળશે (નોંધ: આ શક્ય છે જ્યારે અમે રચના દ્વારા ક્રમનો ઉપયોગ કરીને પૃષ્ઠ દ્વારા પૃષ્ઠ વાંચીએ છીએ, પછી અમારા આઉટપુટની મધ્યમાં તેને નવી એન્ટ્રી મળી શકે છે).

આકૃતિ સ્પષ્ટપણે આ પરિસ્થિતિને દર્શાવે છે. આધાર પ્રથમ 10 રેકોર્ડ્સ વાંચે છે, ત્યારબાદ એક નવો રેકોર્ડ દાખલ કરવામાં આવે છે, જે તમામ વાંચેલા રેકોર્ડ્સને 1 દ્વારા સરભર કરે છે. પછી આધાર આગામી 10 રેકોર્ડ્સમાંથી એક નવું પૃષ્ઠ લે છે અને 11મીથી શરૂ થાય છે, જેમ તે જોઈએ નહીં, પરંતુ 10મી, આ રેકોર્ડનું ડુપ્લિકેટિંગ. આ અભિવ્યક્તિના ઉપયોગ સાથે સંકળાયેલ અન્ય વિસંગતતાઓ છે, પરંતુ આ સૌથી સામાન્ય છે.

જેમ આપણે પહેલેથી જ શોધી કાઢ્યું છે, આ કોઈ ચોક્કસ DBMS અથવા તેના અમલીકરણની સમસ્યાઓ નથી. સમસ્યા SQL સ્ટાન્ડર્ડ અનુસાર પૃષ્ઠ ક્રમાંકને વ્યાખ્યાયિત કરવામાં છે. અમે DBMS ને કહીએ છીએ કે કયું પૃષ્ઠ મેળવવું અથવા કેટલા રેકોર્ડ છોડવા. ડેટાબેઝ આવી વિનંતીને ઑપ્ટિમાઇઝ કરવામાં સક્ષમ નથી, કારણ કે આ માટે ખૂબ ઓછી માહિતી છે.

તે સ્પષ્ટ કરવું પણ યોગ્ય છે કે આ કોઈ ચોક્કસ કીવર્ડ સાથે સમસ્યા નથી, પરંતુ ક્વેરીનાં સિમેન્ટિક્સ સાથે છે. ત્યાં ઘણા વધુ વાક્યરચના છે જે તેમની સમસ્યારૂપ પ્રકૃતિમાં સમાન છે:

• ઑફસેટ કીવર્ડ અગાઉ જણાવ્યા મુજબ છે.
• બે કીવર્ડ્સ લિમિટ [ઓફસેટ]નું બાંધકામ (જોકે મર્યાદા પોતે એટલી ખરાબ નથી).
• પંક્તિ ક્રમાંકન (ઉદાહરણ તરીકે, row_number(), rownum, વગેરે) પર આધારિત, નીચલા સીમાઓ દ્વારા ફિલ્ટરિંગ.

આ તમામ અભિવ્યક્તિઓ ફક્ત તમને જણાવે છે કે કેટલી લાઇન છોડવી, કોઈ વધારાની માહિતી અથવા સંદર્ભ નથી.

પાછળથી આ લેખમાં, ઑફસેટ કીવર્ડનો ઉપયોગ આ તમામ વિકલ્પોના સારાંશ તરીકે થાય છે.

ઑફસેટ વિના જીવન

હવે ચાલો કલ્પના કરીએ કે આ બધી સમસ્યાઓ વિના આપણું વિશ્વ કેવું હશે. તે તારણ આપે છે કે ઑફસેટ વિનાનું જીવન એટલું મુશ્કેલ નથી: પસંદગી સાથે, તમે ફક્ત તે જ પંક્તિઓ પસંદ કરી શકો છો જે અમે હજી સુધી જોઈ નથી (નોંધ: એટલે કે, જે અગાઉના પૃષ્ઠ પર ન હતી), જ્યાં શરતનો ઉપયોગ કરીને.

આ કિસ્સામાં, અમે એ હકીકતથી શરૂ કરીએ છીએ કે પસંદગીઓ ઓર્ડર કરેલ સેટ પર ચલાવવામાં આવે છે (સારા જૂના ઓર્ડર દ્વારા). અમારી પાસે ઓર્ડર કરેલ સેટ હોવાથી, અમે ફક્ત પાછલા પૃષ્ઠના છેલ્લા રેકોર્ડની પાછળનો ડેટા મેળવવા માટે એકદમ સરળ ફિલ્ટરનો ઉપયોગ કરી શકીએ છીએ:

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

તે આ અભિગમનો સંપૂર્ણ સિદ્ધાંત છે. અલબત્ત, ઘણી કૉલમ્સ દ્વારા સૉર્ટ કરતી વખતે વસ્તુઓને વધુ આનંદ મળે છે, પરંતુ વિચાર હજુ પણ એ જ છે. એ નોંધવું અગત્યનું છે કે આ ડિઝાઇન ઘણાને લાગુ પડે છે NoSQL- નિર્ણયો.

આ અભિગમને સીક મેથડ અથવા કીસેટ પૃષ્ઠ ક્રમાંકન કહેવામાં આવે છે. તે ફ્લોટિંગ પરિણામ સમસ્યાનું નિરાકરણ લાવે છે (નોંધ: અગાઉ વર્ણવેલ પૃષ્ઠો વચ્ચે લખવાની પરિસ્થિતિ) અને, અલબત્ત, જે આપણે બધાને ગમે છે, તે ક્લાસિક ઑફસેટ કરતાં વધુ ઝડપી અને વધુ સ્થિર કામ કરે છે. સ્થિરતા એ હકીકતમાં રહેલી છે કે વિનંતીની પ્રક્રિયાનો સમય વિનંતી કરેલ કોષ્ટકની સંખ્યાના પ્રમાણમાં વધતો નથી (નોંધ: જો તમે પૃષ્ઠ ક્રમાંકન માટેના વિવિધ અભિગમોના કાર્ય વિશે વધુ જાણવા માંગતા હો, તો તમે લેખકની રજૂઆત જુઓ. તમે ત્યાં વિવિધ પદ્ધતિઓ માટે તુલનાત્મક બેન્ચમાર્ક પણ શોધી શકો છો).

સ્લાઇડ્સમાંથી એક તે વિશે વાત કરે છેકી દ્વારા પૃષ્ઠ ક્રમાંકન, અલબત્ત, સર્વશક્તિમાન નથી - તેની મર્યાદાઓ છે. સૌથી નોંધપાત્ર એ છે કે તેણી પાસે રેન્ડમ પૃષ્ઠો વાંચવાની ક્ષમતા નથી (નોંધ: અસંગત). જો કે, અનંત સ્ક્રોલિંગના યુગમાં (નોંધ: આગળના છેડે), આ આવી સમસ્યા નથી. ક્લિક કરવા માટે પૃષ્ઠ નંબરનો ઉલ્લેખ કરવો એ કોઈપણ રીતે UI ડિઝાઇનમાં ખરાબ નિર્ણય છે (નોંધ: લેખના લેખકનો અભિપ્રાય).

સાધનો વિશે શું?

આ પદ્ધતિ માટે ઇન્સ્ટ્રુમેન્ટલ સપોર્ટના અભાવને કારણે કી પર પૃષ્ઠ ક્રમાંકન ઘણીવાર યોગ્ય નથી. મોટાભાગના વિકાસ સાધનો, વિવિધ ફ્રેમવર્ક સહિત, તમને પૃષ્ઠ ક્રમાંકન કેવી રીતે કરવામાં આવશે તે બરાબર પસંદ કરવાની મંજૂરી આપતા નથી.

પરિસ્થિતિ એ હકીકતને કારણે વણસી છે કે વર્ણવેલ પદ્ધતિને ઉપયોગમાં લેવાતી ટેક્નોલોજીઓમાં એન્ડ-ટુ-એન્ડ સપોર્ટની જરૂર છે - DBMS થી લઈને અનંત સ્ક્રોલિંગ સાથે બ્રાઉઝરમાં AJAX વિનંતીના અમલ સુધી. ફક્ત પૃષ્ઠ નંબરનો ઉલ્લેખ કરવાને બદલે, તમારે હવે એક જ સમયે બધા પૃષ્ઠો માટે કીનો સમૂહ સ્પષ્ટ કરવો પડશે.

જો કે, કી પર પૃષ્ઠ ક્રમાંકનને સમર્થન આપતા ફ્રેમવર્કની સંખ્યા ધીમે ધીમે વધી રહી છે. આ ક્ષણે અમારી પાસે જે છે તે અહીં છે:

• jOOQ જાવા માટે;
• ઓર્ડર_ક્વેરી રૂબી માટે;
• ચંકેટર и Django અનંત સ્ક્રોલ પૃષ્ઠ ક્રમાંકન જેંગો માટે;
• એસક્યુએલ કીમીયા sqlakeyset પાયથોન માટે;
• અગ્નિ-દ્રઢતા — JPA અમલીકરણ માટે માપદંડ API;
• DBIx::Class::Wrapper પર્લ માટે;
• Massive.js, Node.js માટે મેપર કીસેટ દસ્તાવેજીકરણ.

(નોંધ: અનુવાદ સમયે કેટલીક લાઇબ્રેરીઓ 2017-2018 થી અપડેટ કરવામાં આવી ન હતી તે હકીકતને કારણે કેટલીક લિંક્સ દૂર કરવામાં આવી હતી. જો તમને રસ હોય, તો તમે મૂળ સ્ત્રોત જોઈ શકો છો.)

આ ક્ષણે તમારી મદદની જરૂર છે. જો તમે પૃષ્ઠ ક્રમાંકનનો કોઈપણ ઉપયોગ કરતું ફ્રેમવર્ક વિકસાવો છો અથવા તેને સમર્થન આપો છો, તો હું પૂછું છું, હું વિનંતી કરું છું, હું તમને કી પર પૃષ્ઠ ક્રમાંકન માટે મૂળ સમર્થન પ્રદાન કરવા વિનંતી કરું છું. જો તમને પ્રશ્નો હોય અથવા મદદની જરૂર હોય, તો મને મદદ કરવામાં આનંદ થશે (ફોરમ, Twitter, સંપર્ક ફોર્મ) (નોંધ: માર્કસ સાથેના મારા અનુભવ પરથી, હું કહી શકું છું કે તે આ વિષયને ફેલાવવા માટે ખરેખર ઉત્સાહી છે).

જો તમે તૈયાર સોલ્યુશન્સનો ઉપયોગ કરો છો જે તમને કી દ્વારા પૃષ્ઠ ક્રમાંકન માટે સમર્થન મેળવવા માટે યોગ્ય લાગે છે, તો વિનંતી બનાવો અથવા જો શક્ય હોય તો તૈયાર સોલ્યુશન ઓફર કરો. તમે આ લેખ સાથે લિંક પણ કરી શકો છો.

નિષ્કર્ષ

કી દ્વારા પૃષ્ઠ ક્રમાંકન જેવો આટલો સરળ અને ઉપયોગી અભિગમ વ્યાપક નથી તેનું કારણ એ નથી કે તેને તકનીકી રીતે અમલમાં મૂકવું મુશ્કેલ છે અથવા કોઈ મહાન પ્રયાસની જરૂર છે. મુખ્ય કારણ એ છે કે ઘણા લોકો ઑફસેટ સાથે જોવા અને કામ કરવા માટે ટેવાયેલા છે - આ અભિગમ ધોરણ દ્વારા જ નક્કી કરવામાં આવે છે.

પરિણામે, થોડા લોકો પૃષ્ઠ ક્રમાંકન માટેના અભિગમને બદલવા વિશે વિચારે છે, અને તેના કારણે, ફ્રેમવર્ક અને લાઇબ્રેરીઓ તરફથી ઇન્સ્ટ્રુમેન્ટલ સપોર્ટ નબળી રીતે વિકસિત થઈ રહ્યો છે. તેથી, જો ઑફસેટ-ફ્રી પૃષ્ઠ ક્રમાંકનનો વિચાર અને ધ્યેય તમારી નજીક છે, તો તેને ફેલાવવામાં સહાય કરો!

સોર્સ: https://use-the-index-luke.com/no-offset
લેખક: માર્કસ વિનાન્ડ

સોર્સ: www.habr.com