რატომ გვჭირდება ინსტრუმენტული მხარდაჭერა გასაღებებზე პაგინაციისთვის?

Სალამი ყველას! მე ვარ დეველოპერი, რომელიც წერს მიკროსერვისებს Java + Spring. მე ვმუშაობ Tinkoff-ის პროდუქტის განვითარების ერთ-ერთ შიდა გუნდში.

ჩვენს გუნდში ხშირად ჩნდება კითხვა DBMS-ში მოთხოვნების ოპტიმიზაციის შესახებ. თქვენ ყოველთვის გინდათ იყოთ ცოტა უფრო სწრაფი, მაგრამ ყოველთვის არ შეგიძლიათ გაუმკლავდეთ გააზრებულად აგებულ ინდექსებს - თქვენ უნდა მოძებნოთ რამდენიმე გამოსავალი. ერთ-ერთი ასეთი ხეტიალისას ინტერნეტში, მონაცემთა ბაზებთან მუშაობისას გონივრული ოპტიმიზაციის მოსაძებნად, აღმოვაჩინე მარკუს ვინანდის უსასრულოდ სასარგებლო ბლოგი, ავტორი SQL Performance Explained. ეს ის იშვიათი ტიპის ბლოგია, რომელშიც ყველა სტატიის ზედიზედ წაკითხვა შეგიძლიათ.

მინდა მოგითარგმნოთ მარკუსის მოკლე სტატია. მას გარკვეულწილად შეიძლება ეწოდოს მანიფესტი, რომელიც ცდილობს ყურადღების მიქცევას SQL სტანდარტის მიხედვით ოფსეტური ოპერაციის შესრულების ძველ, მაგრამ მაინც აქტუალურ პრობლემაზე.

ზოგან ავტორს ახსნა-განმარტებითა და კომენტარებით შევავსებ. მე მოვიხსენიებ ყველა ასეთ ადგილს, როგორც "დაახლოებით". მეტი სიცხადისთვის

მცირე შესავალი

ვფიქრობ, ბევრმა იცის, რამდენად პრობლემური და ნელია ოფსეტური გვერდის შერჩევასთან მუშაობა. იცოდით, რომ ის საკმაოდ მარტივად შეიძლება შეიცვალოს უფრო ეფექტური დიზაინით?

ასე რომ, ოფსეტური საკვანძო სიტყვა ეუბნება მონაცემთა ბაზას გამოტოვოს პირველი n ჩანაწერი მოთხოვნაში. თუმცა, მონაცემთა ბაზას ჯერ კიდევ სჭირდება ამ პირველი n ჩანაწერის წაკითხვა დისკიდან, მოცემული თანმიმდევრობით (შენიშვნა: გამოიყენეთ დახარისხება, თუ მითითებულია) და მხოლოდ ამის შემდეგ იქნება შესაძლებელი ჩანაწერების დაბრუნება n+1-დან. ყველაზე საინტერესო ის არის, რომ პრობლემა არა DBMS-ში კონკრეტულ განხორციელებაშია, არამედ სტანდარტის მიხედვით თავდაპირველ განმარტებაში:

... სტრიქონები ჯერ დალაგებულია და შემდეგ შემოიფარგლება მითითებული მწკრივების რაოდენობის თავიდანვე ამოღებით...
-SQL:2016, ნაწილი 2, 4.15.3 მიღებული ცხრილები (შენიშვნა: ამჟამად ყველაზე ხშირად გამოყენებული სტანდარტი)

აქ მთავარი ის არის, რომ ოფსეტი იღებს ერთ პარამეტრს - ჩანაწერების რაოდენობას, რომლებიც უნდა გამოტოვოთ და ეს არის ის. ამ განმარტების შემდეგ, DBMS-ს შეუძლია მხოლოდ აღადგინოს ყველა ჩანაწერი და შემდეგ გააუქმოს არასაჭირო ჩანაწერები. ცხადია, ოფსეტის ეს განმარტება გვაიძულებს დამატებითი სამუშაოს შესრულებას. და არც კი აქვს მნიშვნელობა, არის ეს SQL თუ NoSQL.

ცოტა მეტი ტკივილი

ოფსეტური პრობლემები ამით არ მთავრდება და აი, რატომ. თუ დისკიდან მონაცემების ორი გვერდის წაკითხვას შორის სხვა ოპერაცია ჩასვამს ახალ ჩანაწერს, რა მოხდება ამ შემთხვევაში?

როდესაც ოფსეტი გამოიყენება წინა გვერდებიდან ჩანაწერების გამოტოვებისთვის, სხვადასხვა გვერდების წაკითხვებს შორის ახალი ჩანაწერის დამატების შემთხვევაში, დიდი ალბათობით მიიღებთ დუბლიკატებს (შენიშვნა: ეს შესაძლებელია, როდესაც ვკითხულობთ გვერდი გვერდს კონსტრუქციის მიხედვით, შემდეგ ჩვენი გამომავალი შუა რიცხვებში შეიძლება მიიღოს ახალი ჩანაწერი).

ფიგურა ნათლად ასახავს ამ სიტუაციას. ბაზა კითხულობს პირველ 10 ჩანაწერს, რის შემდეგაც ჩასმულია ახალი ჩანაწერი, რომელიც ანაცვლებს ყველა წაკითხულ ჩანაწერს 1-ით. შემდეგ ბაზა იღებს ახალ გვერდს შემდეგი 10 ჩანაწერიდან და იწყება არა მე-11-დან, როგორც უნდა, არამედ მე-10, ამ ჩანაწერის დუბლირება. არსებობს სხვა ანომალიები, რომლებიც დაკავშირებულია ამ გამოთქმის გამოყენებასთან, მაგრამ ეს ყველაზე გავრცელებულია.

როგორც უკვე გავარკვიეთ, ეს არ არის კონკრეტული DBMS-ის პრობლემები ან მათი დანერგვა. პრობლემა მდგომარეობს SQL სტანდარტის მიხედვით პაგინაციის განსაზღვრაში. ჩვენ ვეუბნებით DBMS-ს, რომელი გვერდის მოზიდვა ან რამდენი ჩანაწერის გამოტოვება. მონაცემთა ბაზას უბრალოდ არ შეუძლია ასეთი მოთხოვნის ოპტიმიზაცია, რადგან ამისათვის ძალიან ცოტა ინფორმაციაა.

ასევე ღირს იმის გარკვევა, რომ ეს არ არის პრობლემა კონკრეტულ საკვანძო სიტყვასთან, არამედ მოთხოვნის სემანტიკასთან. არსებობს კიდევ რამდენიმე სინტაქსი, რომლებიც იდენტურია მათი პრობლემური ბუნებით:

• ოფსეტური საკვანძო სიტყვა არის როგორც ადრე აღვნიშნეთ.
• ორი საკვანძო სიტყვის კონსტრუქცია ლიმიტი [offset] (თუმცა ლიმიტი თავისთავად არც ისე ცუდია).
• ფილტრაცია ქვედა საზღვრებით, მწკრივების ნუმერაციის საფუძველზე (მაგალითად, row_number(), rownum და ა.შ.).

ყველა ეს გამონათქვამი უბრალოდ გეტყვით რამდენი ხაზი უნდა გამოტოვოთ, დამატებითი ინფორმაციის ან კონტექსტის გარეშე.

მოგვიანებით ამ სტატიაში, ოფსეტური საკვანძო სიტყვა გამოიყენება როგორც ყველა ამ ვარიანტის შეჯამება.

ცხოვრება OFFSET-ის გარეშე

ახლა წარმოვიდგინოთ, როგორი იქნებოდა ჩვენი სამყარო ყველა ამ პრობლემის გარეშე. გამოდის, რომ ოფსეტური ცხოვრება არც ისე რთულია: სელექციით შეგიძლიათ აირჩიოთ მხოლოდ ის რიგები, რომლებიც ჯერ არ გვინახავს (შენიშვნა: ანუ ის, რაც წინა გვერდზე არ იყო), იმ პირობის გამოყენებით, სადაც.

ამ შემთხვევაში, ჩვენ ვიწყებთ იქიდან, რომ სელექციები შესრულებულია შეკვეთილ კომპლექტზე (ძველი კარგი შეკვეთით). ვინაიდან ჩვენ გვაქვს შეკვეთილი ნაკრები, ჩვენ შეგვიძლია გამოვიყენოთ საკმაოდ მარტივი ფილტრი, რომ მივიღოთ მხოლოდ ის მონაცემები, რომლებიც წინა გვერდის ბოლო ჩანაწერის მიღმაა:

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

ეს არის ამ მიდგომის მთელი პრინციპი. რა თქმა უნდა, ყველაფერი უფრო სახალისო ხდება მრავალი სვეტის მიხედვით დახარისხებისას, მაგრამ იდეა მაინც იგივეა. მნიშვნელოვანია აღინიშნოს, რომ ეს დიზაინი გამოიყენება ბევრისთვის NoSQL- გადაწყვეტილებები.

ამ მიდგომას უწოდებენ ძიების მეთოდს ან კლავიშთა პაგინაციას. ის აგვარებს მცურავი შედეგის პრობლემას (შენიშვნა: ადრე აღწერილი გვერდების წაკითხვას შორის წერის სიტუაცია) და, რა თქმა უნდა, ის, რაც ჩვენ ყველას გვიყვარს, მუშაობს უფრო სწრაფად და სტაბილურად, ვიდრე კლასიკური ოფსეტი. სტაბილურობა მდგომარეობს იმაში, რომ მოთხოვნის დამუშავების დრო არ იზრდება მოთხოვნილი ცხრილის რაოდენობის პროპორციულად (შენიშვნა: თუ გსურთ გაიგოთ მეტი პაგინაციის სხვადასხვა მიდგომების მუშაობის შესახებ, შეგიძლიათ გადახედეთ ავტორის პრეზენტაციას. აქ ასევე შეგიძლიათ იპოვოთ შედარებითი კრიტერიუმები სხვადასხვა მეთოდისთვის).

ერთ-ერთი სლაიდი საუბრობს ამაზერომ კლავიშებით პაგინაცია, რა თქმა უნდა, არ არის ყოვლისშემძლე - მას აქვს თავისი შეზღუდვები. ყველაზე მნიშვნელოვანი ის არის, რომ მას არ აქვს შემთხვევითი გვერდების წაკითხვის უნარი (შენიშვნა: არათანმიმდევრულად). თუმცა, გაუთავებელი გადახვევის ეპოქაში (შენიშვნა: წინა მხარეს), ეს არ არის ასეთი პრობლემა. დაწკაპუნებისთვის გვერდის ნომრის მითითება მაინც ცუდი გადაწყვეტილებაა UI დიზაინში (შენიშვნა: სტატიის ავტორის აზრი).

რაც შეეხება ხელსაწყოებს?

გასაღებებზე პაგირება ხშირად არ არის შესაფერისი ამ მეთოდის ინსტრუმენტული მხარდაჭერის არარსებობის გამო. განვითარების ინსტრუმენტების უმეტესობა, მათ შორის სხვადასხვა ჩარჩოები, არ გაძლევთ საშუალებას აირჩიოთ ზუსტად როგორ შესრულდება პაგინაცია.

სიტუაციას ამძიმებს ის ფაქტი, რომ აღწერილი მეთოდი მოითხოვს ბოლომდე მხარდაჭერას გამოყენებულ ტექნოლოგიებში - DBMS-დან AJAX მოთხოვნის შესრულებამდე ბრაუზერში გაუთავებელი გადახვევით. იმის ნაცვლად, რომ მიუთითოთ მხოლოდ გვერდის ნომერი, ახლა თქვენ უნდა მიუთითოთ კლავიშების ნაკრები ერთდროულად ყველა გვერდისთვის.

თუმცა, ჩარჩოების რაოდენობა, რომლებიც მხარს უჭერენ კლავიშებზე პაგინაციას, თანდათან იზრდება. აი რა გვაქვს ამ მომენტში:

• JOOQ ჯავისთვის;
• შეკვეთა_შეკითხვა რუბისთვის;
• ჩუნქატორი и Django Infinite Scroll Pagination ჯანგოსთვის;
• SQL Alchemy sqlakeyset პითონისთვის;
• ცეცხლგამძლეობა — კრიტერიუმების API JPA განხორციელებისთვის;
• DBIx::კლასი::შეფუთვა პერლისთვის;
• მასიური.js, Mapper for Node.js Keyset დოკუმენტაცია.

(შენიშვნა: ზოგიერთი ბმული წაიშალა იმის გამო, რომ თარგმანის დროს ზოგიერთი ბიბლიოთეკა არ იყო განახლებული 2017-2018 წლებში. დაინტერესების შემთხვევაში შეგიძლიათ იხილოთ ორიგინალური წყარო.)

სწორედ ამ მომენტშია საჭირო თქვენი დახმარება. თუ თქვენ შეიმუშავებთ ან მხარს უჭერთ ჩარჩოს, რომელიც იყენებს პაგინაციას, მაშინ გთხოვთ, მოგიწოდებთ, უზრუნველვყოთ ძირითადი მხარდაჭერა გასაღებებზე პაგინაციისთვის. თუ თქვენ გაქვთ შეკითხვები ან გჭირდებათ დახმარება, სიამოვნებით დაგეხმარებით (ფორუმი, Twitter, საკონტაქტო ფორმა) (შენიშვნა: მარკუსთან ჩემი გამოცდილებიდან შემიძლია ვთქვა, რომ ის ნამდვილად ენთუზიაზმით არის განწყობილი ამ თემის გავრცელებით).

თუ იყენებთ მზა გადაწყვეტილებებს, რომლებიც, თქვენი აზრით, იმსახურებს კლავიშებით პაგინაციის მხარდაჭერას, შექმენით მოთხოვნა ან თუნდაც შესთავაზეთ მზა გადაწყვეტა, თუ ეს შესაძლებელია. თქვენ ასევე შეგიძლიათ ამ სტატიის ბმული.

დასკვნა

მიზეზი, რის გამოც ისეთი მარტივი და სასარგებლო მიდგომა, როგორიცაა კლავიშებით პაგინაცია, არ არის გავრცელებული, არ არის ის, რომ მისი განხორციელება ტექნიკურად რთულია ან დიდ ძალისხმევას მოითხოვს. მთავარი მიზეზი ისაა, რომ ბევრს სჩვევია ოფსეტურით ყურება და მუშაობა – ეს მიდგომა თავად სტანდარტით არის ნაკარნახევი.

შედეგად, ცოტა ადამიანი ფიქრობს პაგინაციისადმი მიდგომის შეცვლაზე და ამის გამო, ჩარჩოებისა და ბიბლიოთეკების ინსტრუმენტული მხარდაჭერა ცუდად ვითარდება. ამიტომ, თუ უოფსეტური პაგინაციის იდეა და მიზანი თქვენთვის ახლოსაა, დაეხმარეთ მის გავრცელებას!

წყარო: https://use-the-index-luke.com/no-offset
ავტორი: მარკუს ვინანდ

წყარო: www.habr.com