Miks vajate klahvide lehekülgede jaoks instrumentaalset tuge?

Tere kõigile! Olen taustaprogrammi arendaja, kes kirjutab Java + Springis mikroteenuseid. Töötan ühes Tinkoffi sisemises tootearendusmeeskonnas.

Meie meeskonnas kerkib sageli küsimus päringute optimeerimisest DBMS-is. Tahad alati veidi kiirem olla, kuid läbimõeldult koostatud indeksidega ei saa alati hakkama – pead otsima mõningaid lahendusi. Ühel sellisel veebis ringi uitamise ajal andmebaasidega töötamisel mõistlikke optimeerimisi otsides leidsin Marcus Wynandi lõputult kasulik ajaveeb, raamatu SQL Performance Explained autor. See on haruldane ajaveebi tüüp, kus saate lugeda kõiki artikleid järjest.

Tahaksin tõlkida teile Marcuse lühikese artikli. Mingil määral võib seda nimetada manifestiks, mis püüab juhtida tähelepanu vanale, kuid siiski aktuaalsele nihketoimingu sooritamise probleemile SQL standardi järgi.

Kohati täiendan autorit selgituste ja kommentaaridega. Ma nimetan kõiki selliseid kohti kui "umbes". suurema selguse huvides

Väike sissejuhatus

Arvan, et paljud teavad, kui problemaatiline ja aeglane on nihke kaudu lehevalikutega töötamine. Kas teadsite, et selle saab üsna lihtsalt asendada tõhusama disainiga?

Seega käsib nihke märksõna andmebaasil jätta päringu esimesed n kirjet vahele. Andmebaas peab siiski need esimesed n kirjet kettalt etteantud järjekorras ette lugema (märkus: rakenda sorteerimist, kui see on määratud) ja alles siis on võimalik kirjeid tagastada alates n+1-st. Kõige huvitavam on see, et probleem ei ole DBMS-i konkreetses teostuses, vaid algses definitsioonis vastavalt standardile:

…read sorteeritakse esmalt vastavalt ja seejärel piirata, jättes välja jaotises määratud ridade arvu algusest peale...
-SQL:2016, 2. osa, 4.15.3 Tuletatud tabelid (märkus: praegu enimkasutatav standard)

Võtmepunkt on siin see, et nihe võtab ühe parameetri – vahele jäetavate kirjete arvu ja ongi kõik. Seda määratlust järgides saab DBMS ainult kõik kirjed hankida ja seejärel mittevajalikud ära visata. Ilmselgelt sunnib see kompensatsiooni määratlus meid tegema lisatööd. Ja pole isegi vahet, kas see on SQL või NoSQL.

Ainult natuke rohkem valu

Offsetiga seotud probleemid ei lõpe sellega ja siin on põhjus. Kui kahe lehekülje andmete lugemise vahel kettalt sisestab mõni muu toiming uue kirje, mis siis sel juhul juhtub?

Kui nihet kasutatakse eelmiste lehtede kirjete vahelejätmiseks, siis uue kirje lisamisel erinevate lehekülgede lugemiste vahele tekib suure tõenäosusega duplikaadid (märkus: see on võimalik, kui loeme lehekülgede kaupa, kasutades järjestust konstruktsiooni järgi, siis meie väljundi keskel võib see saada uue kirje).

Joonis kujutab seda olukorda selgelt. Alus loeb esimesed 10 kirjet, mille järel sisestatakse uus kirje, mis nihutab kõik loetud kirjed 1 võrra. Seejärel võtab baas järgmisest 10 kirjest uue lehekülje ja alustab mitte 11. kuupäevast, nagu peaks, vaid alates 10., dubleerides seda rekordit. Selle väljendi kasutamisega on seotud ka teisi kõrvalekaldeid, kuid see on kõige levinum.

Nagu me juba teada saime, ei ole need konkreetse DBMS-i või nende rakenduste probleemid. Probleem on lehekülgede määramises SQL standardi järgi. Me ütleme DBMS-ile, millist lehekülge tuua või mitu kirjet vahele jätta. Andmebaas lihtsalt ei suuda sellist päringut optimeerida, kuna selle jaoks on liiga vähe teavet.

Samuti tasub selgitada, et probleem ei ole konkreetse märksõnaga, vaid pigem päringu semantikaga. On veel mitu süntaksit, mis on oma probleemse olemuselt identsed:

• Nihke märksõna on nagu varem mainitud.
• Kahest märksõnast koosnev konstruktsioon limit [nihe] (kuigi limiit ise pole nii halb).
• Filtreerimine alumiste piiride järgi, lähtudes ridade nummerdamisest (näiteks rea_arv(), reanumber jne).

Kõik need väljendid lihtsalt ütlevad teile, mitu rida tuleb vahele jätta, ilma täiendava teabe või kontekstita.

Hiljem selles artiklis kasutatakse nihke märksõna kõigi nende valikute kokkuvõttena.

Elu ilma OFFSETita

Kujutagem nüüd ette, milline oleks meie maailm ilma kõigi nende probleemideta. Selgub, et elu ilma nihketa polegi nii keeruline: valikuga saate valida ainult need read, mida me pole veel näinud (märkus: st need, mida eelmisel lehel polnud), kasutades tingimust kus.

Sel juhul lähtume sellest, et valikud teostatakse tellitud komplektil (vana hea order by). Kuna meil on tellitud komplekt, saame kasutada üsna lihtsat filtrit, et saada ainult need andmed, mis on eelmise lehe viimase kirje taga:

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

See on kogu selle lähenemisviisi põhimõte. Paljude veergude järgi sorteerimisel läheb asi muidugi lõbusamaks, aga mõte on ikka sama. Oluline on märkida, et see disain sobib paljudele NoSQL-otsused.

Seda lähenemisviisi nimetatakse otsingumeetodiks või võtmekomplekti lehekülgedeks. See lahendab ujuva tulemuse probleemi (märkus: varem kirjeldatud olukord lehekülgede lugemise vahel kirjutamisel) ja loomulikult see, mis meile kõigile meeldib, see töötab kiiremini ja stabiilsemalt kui klassikaline nihe. Stabiilsus seisneb selles, et päringu töötlemise aeg ei pikene proportsionaalselt taotletava tabeli arvuga (märkus: kui soovite rohkem teada saada erinevate lehekülgede otsimise lähenemisviiside töö kohta, saate vaadake läbi autori esitlus. Sealt leiate ka erinevate meetodite võrdlusalused).

Üks slaididest räägib sellestet klahvide järgi lehitsemine pole muidugi kõikvõimas – sellel on omad piirangud. Kõige olulisem on see, et tal pole võimalust juhuslikke lehti lugeda (märkus: ebajärjekindlalt). Kuid lõputu kerimise ajastul (märkus: esiotsas) pole see nii probleem. Klikkimiseks leheküljenumbri määramine on kasutajaliidese kujunduses nagunii halb otsus (märkus: artikli autori arvamus).

Aga tööriistad?

Klahvidel lehekülgede kirjutamine ei sobi sageli selle meetodi instrumentaalse toe puudumise tõttu. Enamik arendustööriistu, sealhulgas erinevad raamistikud, ei võimalda teil täpselt valida, kuidas lehekülgede otsimine toimub.

Olukorda raskendab asjaolu, et kirjeldatud meetod nõuab kasutatavate tehnoloogiate täielikku tuge - alates DBMS-ist kuni AJAX-i päringu täitmiseni brauseris lõputu kerimisega. Selle asemel, et määrata ainult leheküljenumber, peate nüüd määrama klahvikomplekti kõigi lehtede jaoks korraga.

Siiski kasvab järk-järgult võtmete lehekülgede muutmist toetavate raamistike arv. Siin on see, mis meil hetkel on:

• jOOQ Java jaoks;
• tellimuse_päring Ruby jaoks;
• tükeldaja и Django Infinite Scroll Pagination Django jaoks;
• SQL Alchemy sqlakeyset Pythoni jaoks;
• leek-püsivus — kriteeriumite API JPA juurutamiseks;
• DBIx::Klass::ümbris Perli jaoks;
• Massive.js, kaardistaja jaoks Node.js Võtmekomplekti dokumentatsioon.

(Märkus: mõned lingid eemaldati, kuna tõlkimise ajal ei olnud mõnda teeki uuendatud alates 2017-2018. Huvi korral võite vaadata algallikat.)

Just sel hetkel on teie abi vaja. Kui arendate või toetate raamistikku, mis kasutab lehekülgede lehte, siis palun, ma palun, anun, et pakuksite võtmete lehekülgede jaoks natiivset tuge. Kui teil on küsimusi või vajate abi, aitan hea meelega (foorum, puperdama, kontaktivorm) (märkus: oma kogemuse põhjal Marcusega võin öelda, et ta on selle teema levitamisest tõeliselt entusiastlik).

Kui kasutate valmislahendusi, mis teie arvates väärivad võtmete järgi lehitsemise tuge, koostage päring või pakkuge võimalusel isegi valmislahendust. Võite ka sellele artiklile linkida.

Järeldus

Põhjus, miks selline lihtne ja kasulik lähenemine nagu klahvide järgi lehekülgede otsimine pole laialt levinud, ei seisne selles, et seda oleks tehniliselt keeruline teostada või see nõuab suuri pingutusi. Peamine põhjus on see, et paljud on harjunud nägema ja töötama nihkega – selle lähenemise dikteerib standard ise.

Seetõttu mõtlevad vähesed inimesed lehekülgede lugemise lähenemisviisi muutmisele ja seetõttu areneb raamistike ja raamatukogude instrumentaalne tugi halvasti. Seega, kui offset-vaba lehekülgede lehitsemise idee ja eesmärk on teile lähedal, aidake seda levitada!

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

Allikas: www.habr.com