Miks on vajalik instrumentaalne tugi lehekülgede valimise puhul

Tere kõigile! Ma olen back-end arendaja, kes kirjutab mikroteenuseid Java + Springis. Töödan ühes ettevõtte Tinkoff sisemiste toodete arendusmeeskondades.

Meie meeskonnas tõusetub sageli küsimus päringute optimeerimisest andmebaasides. Alati tahaks natuke kiiremat, kuid mitte alati ei piisa läbimõeldud indekseerimisest — tuleb leida mingeid alternatiivseid teid. Ühel sellisel rännakul internetis, otsides mõistlikke optimeerimisi andmebaasidega töötamiseks, leidsin lõputult kasuliku Markuse Vinandi blogi, kes on raamatu "SQL Performance Explained" autor. See on see haruldane blogitüüp, kus saab järjest lugeda kõiki artikleid.

Soovin tõlkida teile väikese Markuse artikli. Seda võib mingil määral nimetada manifestiks, mis püüab juhtida tähelepanu vanale, kuid endiselt aktuaalsele probleemile, mis puudutab SQL standardi offset operatsiooni jõudlust.

Mõnes kohas täiendama autori selgitustega ja märkustega. Kõiki selliseid kohti tähistan kui "primp" selguse huvides.

Lühike sissejuhatus

Arvan, et paljud teavad, kui probleemne ja aeglane võib olla leheküljepõhine valimine offsetiga. Kas teate, et seda saab üsna lihtsalt asendada efektiivsema konstruktsiooniga?

Nii et, võtmesõna offset näitab andmebaasile, et tuleb jätta välja esimesed n kirjet päringus. Siiski peab andmebaas kõik need esimesed n kirjet lugema kettalt, jaotuses, mis on määratud (primp: rakendage sortimist, kui see on määratud), ning alles pärast seda on võimalik tagastada kirjed alates n+1 ja edasi. Huvi pakub, et probleem ei ole konkreetses teostuses andmebaasis, vaid algses määratlemises standardis:

…the rows are first sorted according to the and then limited by dropping the number of rows specified in the from the beginning…
-SQL:2016, Part 2, 4.15.3 Derived tables (primp: praegu kõige kasutatum standard)

Siin on võtmepunkt see, et offset aktsepteerib ainult ühte parameetrit — kirjeid, mis tuleb vahele jätta, ja kõik. Sellise määratluse järgimine võimaldab andmebaasil ainult hankida kõik kirjed ja seejärel kõrvaldata need, mis ei ole vajalikud. On ilmne, et selline offset’i määratlemine paneb tegema liigset tööd. Ja siinkohal ei ole oluline, kas see on SQL või NoSQL.

Veel natuke valu

Offset probleemid ei piirdu sellega ja siin on põhjused. Kui kahe lehe andmete lugemise vahel lisab mõni teine operatsioon uue kirje, mis sellel juhul juhtub?

Kui offset'i kasutatakse, et vahele jätta kirjeid eelmistelt lehtedel, siis olukorras, kus uus kirje lisatakse erinevate lehtede lugemise tegevuste vahele, on tõenäoliselt tulemuseks dubleeritud kirjed (nt: selline olukord on võimalik, kui loeme lehtede kaupa kasutades order by konstruktsiooni, siis võib meie tulemuste keskele sattuda uus kirje).

Joonis illustreerib sellist olukorda. Andmebaas loeb esimesed 10 kirjet, pärast seda lisatakse uus kirje, mis nihutab kõik loetud kirjed ühe võrra. Siis võtab andmebaas uue lehe 10 järgmist kirjet, alustades mitte 11. kirjest, nagu peaks, vaid 10. kirjest, dubleerides selle kirje. On ka teisi anomaaliaid, mis on seotud selle väljendi kasutamisega, kuid see on kõige levinum.

Nagu me juba välja selgitasime, ei ole need probleemid konkreetse andmebaasi või nende rakenduste probleemid. Probleem seisneb SQL standardi järgi lehe määratlemises. Me ütlememe andmebaasile, millist lehte on vaja välja tõmmata või kui palju kirjeid jätta vahele. Andmebaas ei ole lihtsalt suuteline sellist päringut optimeerima, kuna selleks on liiga vähe teavet.

Samuti on oluline märkida, et see ei ole konkreetse märksõna probleem, vaid pigem päringu semantika probleem. On veel mitu identset probleemset süntaksit:

• Märksõna offset, nagu eelnevalt mainitud.
• Konstruktsioon kahe märksõna limit [offset] (kuigi limit iseenesest ei ole nii halb).
• Filtreerimine alumiste piiride järgi, mis põhineb ridade nummerdamisel (näiteks row_number(), rownum jne).

Kõik need väljendid lihtsalt ütlevad, kui palju ridu on vaja vahele jätta, pakkumata mingeid lisainformatsiooni või konteksti.

Jätkuvalt kasutatakse käesolevas artiklis märksõna offset üldistena nende erinevate variantide jaoks.

Elu ilma OFFSETita

Kujutage nüüd ette, milline oleks meie maailm ilma nende probleemideta. Selgub, et elu ilma offset'ita ei ole nii keeruline: saame select'iga valida ainult need read, mida me veel ei ole näinud (nt: see tähendab neid, mida ei olnud eelmises lehes), kasutades tingimust where.

Selle juhul lähtume tõsiasjast, et valikut teostatakse järjestatud hulga (vana hea order by) peal. Kuna meil on järjestatud hulk, saame kasutada üsna lihtsat filtrit, et kuvada ainult need andmed, mis asuvad viimase eelneva lehe kirje taga:

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

See ongi kogu sellise lähenemise põhimõte. Muidugi, kui järjestada paljude veergude järgi, muutub see huvitavamaks, kuid idee on endiselt sama. Oluline on märkida, et see konstruktsioon on rakendatav paljudele NoSQL-lahendustele.

Seda lähenemist nimetatakse otsimismeetodiks ehk keyset pagination. See lahendab probleemid ujuva tulemusega (nt: olukord kirje vahel lehtede lugemisel, nagu eelnevalt kirjeldatud) ja, nagu me kõik armastame, töötab see kiiremini ja stabiilsemalt kui klassikaline offset. Stabiilsus seisneb selles, et päringu töötlemise aeg ei suurene proportsionaalselt küsitava tabeli numbriga (nt: kui soovite rohkem teada erinevate lehe jaotamise lähenemiste toimimisest, saate sirvida autori esitlust. Sealt leiate ka erinevate meetodite võrdlevad benchmarkid.

Üks slaid räägib sellest,et lehtede jaotamine võtmete järgi ei ole muidugi kõikvõimas — tal on oma piirangud. Olulisem on see, et tal ei ole võimalust lugeda juhuslikke lehti (nt: mittejärjekindlalt). Siiski, lõputu kerimise ajastul (nt: front-endis) ei ole see probleem. Lehe number klõpsamiseks on igal juhul halb lahendus UI arendamisel (nt: autori arvamus).

Ent kuidas on tööriistadega?

Küljendamine võtmete põhjal ei sobi sageli tööriistade toetuse puudumise tõttu. Enamik arendustootest, sealhulgas erinevad raamistike, ei paku valikut, kuidas täpselt küljendamine teostatakse.

Situatsiooni süvendab asjaolu, et kirjeldatud meetod nõuab kasutatavad tehnoloogiad katvat tuge — alates andmebaasist kuni AJAX-päringute täitmiseni brauseris lõputu kerimise korral. Selle asemel, et näidata ainult lehe numbrit, tuleb nüüd näidata kõigi lehtede jaoks võtmete kogumit.

Kuid võtmete põhjal lehtede jagamist toetavate raamistikute arv kasvab järk-järgult. Siin on, mis on praegu saadaval:

• jOOQ Java jaoks;
• order_query Ruby jaoks;
• chunkator ja Django Infinite Scroll Pagination Django jaoks;
• SQL Alchemy sqlakeyset Python jaoks;
• blaze-persistence — kriteeriumi API JPA rakenduste jaoks;
• DBIx::Class::Wrapper Perl jaoks;
• Massive.js, мапер для Node.js Keyset Dokumentatsioon.

(Märkus: mõned lingid on eemaldatud, kuna tõlketähtajal ei olnud mõned raamatukogud värskendatud alates 2017–2018. Kui teid huvitab, võite vaadata originaali.)

Just selles punktis on teie abi vajalik. Kui arendate või toetate raamistikku, mis mingil viisil kasutab lehtede jagamist, siis palun, ma palun teid, tehke natiivne toetust võtmete põhjal lehtede jagamise jaoks. Kui teil on küsimusi või vajate abi, olen rõõmuga abiks (a forum, Twitteris, kontaktvorm) (märkus: minu kogemuse põhjal suhtlemisel Markusiga võin öelda, et ta on tõeliselt entusiastlik selle teema levitamise suhtes).

Kui aga kasutate olemasolevaid lahendusi, mida teie arvates väärivad võtmete põhjal lehtede jagamise toetust, siis looge päring või isegi pakkuda valmis lahendust, kui see on võimalik. Võite ka viidata sellele artiklile.

Kokkuvõte

Põhjuseks, miks nii lihtne ja kasulik lähenemine nagu võtmete põhjal lehtede jagamine pole laialdaselt levinud, ei ole see, et see oleks tehniliselt keeruline või nõuaks suuri pingutusi. Peamine põhjus on see, et paljud on harjunud nägema ja töötama offsetiga — see lähenemine on dikteeritud standardi endaga.

Seetõttu ei mõtle vähesed sellele, et muuta lehtede jagamise lähenemist, ja seetõttu areneb raamistikude ja raamatukogude tööriistade tugi nõrgalt. Seega, kui idee ja eesmärk ilma offsetita lehtede jagamise osas on teile lähedane, aidake selle levitamist!

Allikas: https://use-the-index-luke.com/no-offset
Autor: Markus Winand

Allikas: habr.com