Hei kaikki! Olen taustakehittäjä, joka kirjoittaa mikropalveluita Java + Spring -kielellä. Työskentelen yhdessä Tinkoffin sisäisestä tuotekehitystiimistä.
Tiimissämme herää usein kysymys kyselyjen optimoinnista DBMS:ssä. Haluat aina olla hieman nopeampi, mutta et aina pärjää harkitusti rakennetuilla indekseillä – sinun on etsittävä joitain kiertotapoja. Yhdessä näistä seikkailuista verkossa etsiessäni järkeviä optimointeja tietokantojen kanssa työskennellessäni löysin , SQL Performance Explained -julkaisun kirjoittaja. Tämä on se harvinainen blogityyppi, jossa voit lukea kaikki artikkelit peräkkäin.
Haluaisin kääntää sinulle Marcuksen lyhyen artikkelin. Sitä voidaan jossain määrin kutsua manifestiksi, joka pyrkii kiinnittämään huomiota vanhaan, mutta edelleen relevanttiin ongelmaan offset-operaation suorittamisessa SQL-standardin mukaisesti.
Paikoin täydentän kirjoittajaa selityksillä ja kommenteilla. Kutsun kaikkia tällaisia paikkoja "noin". lisää selkeyttä
Pieni johdanto
Luulen, että monet tietävät, kuinka ongelmallista ja hidasta työskentely offsetin kautta tapahtuvien sivuvalintojen kanssa on. Tiesitkö, että se voidaan melko helposti vaihtaa tehokkaampaan malliin?
Joten offset-avainsana käskee tietokannan ohittamaan pyynnön ensimmäiset n tietuetta. Tietokannan on kuitenkin vielä luettava nämä ensimmäiset n tietuetta levyltä annetussa järjestyksessä (huomaa: käytä lajittelua, jos se on määritetty), ja vasta sitten on mahdollista palauttaa tietueita n+1:stä eteenpäin. Mielenkiintoisin asia on, että ongelma ei ole DBMS:n tietyssä toteutuksessa, vaan alkuperäisessä standardin mukaisessa määritelmässä:
…rivit lajitellaan ensin ja sitten rajoittaa pudottamalla rivien määrä määritetty alusta alkaen…
-SQL:2016, Osa 2, 4.15.3 Johdetut taulukot (huomaa: tällä hetkellä eniten käytetty standardi)
Tärkeintä tässä on, että offset ottaa yhden parametrin - ohitettavien tietueiden määrän, ja siinä se. Tämän määritelmän mukaisesti DBMS voi vain noutaa kaikki tietueet ja sitten hylätä tarpeettomat. Ilmeisesti tämä offsetin määritelmä pakottaa meidät tekemään ylimääräistä työtä. Ja sillä ei ole edes väliä, onko se SQL vai NoSQL.
Vähän lisää kipua
Offsetin ongelmat eivät lopu tähän, ja tässä on syy. Jos kahden tietosivun lukemisen välillä levyltä toinen toiminto lisää uuden tietueen, mitä tapahtuu tässä tapauksessa?
Kun offsetilla ohitetaan tietueita aiemmilta sivuilta, tilanteessa, jossa uusi tietue lisätään eri sivujen lukujen väliin, saat todennäköisesti kaksoiskappaleita (huomaa: tämä on mahdollista, kun luemme sivu sivulta järjestys konstruktion mukaan, sitten tulostemme keskellä se voi saada uuden merkinnän).
Kuva kuvaa selkeästi tätä tilannetta. Kanta lukee ensimmäiset 10 tietuetta, minkä jälkeen lisätään uusi tietue, joka siirtää kaikki luetut tietueet yhdellä. Sitten kanta ottaa uuden sivun seuraavilta 1 tietueelta ja ei aloita 10. tietueesta, kuten sen pitäisi, vaan tietueesta 11., kopioidaan tämän ennätyksen. Tämän ilmaisun käyttöön liittyy muitakin poikkeavuuksia, mutta tämä on yleisin.
Kuten olemme jo havainneet, nämä eivät ole tietyn DBMS:n tai niiden toteutusten ongelmia. Ongelmana on sivunumeron määrittely SQL-standardin mukaan. Kerromme DBMS:lle, mikä sivu noudetaan tai kuinka monta tietuetta ohitetaan. Tietokanta ei yksinkertaisesti pysty optimoimaan tällaista pyyntöä, koska siihen on liian vähän tietoa.
On myös syytä selventää, että tämä ei ole tietyn avainsanan ongelma, vaan pikemminkin kyselyn semantiikka. On olemassa useita muita syntakseja, jotka ovat identtisiä ongelmallisuutensa vuoksi:
- Offset-avainsana on kuten aiemmin mainittiin.
- Kahden avainsanan rakenne rajoittaa [offset] (vaikka itse raja ei ole niin huono).
- Suodatus alarajojen mukaan, perustuen rivien numerointiin (esimerkiksi rivin_numero(), rivinumero jne.).
Kaikki nämä lausekkeet kertovat yksinkertaisesti, kuinka monta riviä ohitetaan, ei lisätietoa tai kontekstia.
Myöhemmin tässä artikkelissa offset-avainsanaa käytetään yhteenvetona kaikista näistä vaihtoehdoista.
Elämä ilman OFFSETia
Kuvittele nyt, millainen maailmamme olisi ilman kaikkia näitä ongelmia. Osoittautuu, että elämä ilman siirtymää ei ole niin vaikeaa: valinnalla voit valita vain ne rivit, joita emme ole vielä nähneet (huom: eli ne, jotka eivät olleet edellisellä sivulla), käyttämällä ehtoa missä.
Tässä tapauksessa lähdetään siitä, että valinnat suoritetaan tilatulle sarjalle (vanha hyvä järjestys). Koska meillä on tilattu joukko, voimme käyttää melko yksinkertaista suodatinta saadaksemme vain tiedot, jotka ovat edellisen sivun viimeisen tietueen takana:
SELECT ...
FROM ...
WHERE ...
AND id < ?last_seen_id
ORDER BY id DESC
FETCH FIRST 10 ROWS ONLYTämä on tämän lähestymistavan koko periaate. Tietysti asiat muuttuvat hauskemmaksi lajitellessa useiden sarakkeiden mukaan, mutta idea on silti sama. On tärkeää huomata, että tämä malli sopii moniin -päätökset.
Tätä lähestymistapaa kutsutaan hakumenetelmäksi tai avainjoukon sivutukseksi. Se ratkaisee kelluvan tulosongelman (huom: aiemmin kuvattu tilanne sivujen lukemisen välillä) ja tietysti se, mitä me kaikki rakastamme, se toimii nopeammin ja vakaammin kuin klassinen offset. Vakaus piilee siinä, että pyynnön käsittelyaika ei kasva suhteessa pyydetyn taulukon määrään (huomaa: jos haluat oppia lisää erilaisten sivutusmenetelmien toiminnasta, voit . Sieltä löydät myös vertailevat vertailut eri menetelmille).
Yksi dioista että avaimilla sivutus ei tietenkään ole kaikkivoipaa - sillä on rajoituksensa. Merkittävin on, että hänellä ei ole kykyä lukea satunnaisia sivuja (huom: epäjohdonmukaisesti). Kuitenkin loputtoman vierityksen aikakaudella (huomautus: etuosassa) tämä ei ole sellainen ongelma. Sivunumeron määrittäminen napsautusta varten on joka tapauksessa huono päätös käyttöliittymäsuunnittelussa (huom: artikkelin kirjoittajan mielipide).
Entä työkalut?
Näppäimien sivutus ei useinkaan ole sopivaa, koska tälle menetelmälle ei ole instrumentaalista tukea. Useimmat kehitystyökalut, mukaan lukien erilaiset puitteet, eivät salli sinun valita tarkalleen, kuinka sivutus suoritetaan.
Tilannetta pahentaa se, että kuvattu menetelmä vaatii päästä päähän -tukea käytetyille teknologioille - DBMS:stä AJAX-pyynnön suorittamiseen selaimessa loputtomalla selauksella. Sen sijaan, että määrität vain sivunumeron, sinun on nyt määritettävä näppäinsarja kaikille sivuille kerralla.
Avainten sivutusta tukevien kehysten määrä kuitenkin kasvaa vähitellen. Tässä mitä meillä on tällä hetkellä:
- Javalle;
- Rubylle;
- и Djangolle;
- Pythonille;
- — kriteerien API JPA-toteutuksiin;
- Perlille;
- , Mapper Node.js:lle .
(Huom: jotkut linkit poistettiin, koska osa kirjastoista ei ollut päivitetty käännöshetkellä 2017-2018 jälkeen. Jos olet kiinnostunut, voit katsoa alkuperäistä lähdettä.)
Juuri tällä hetkellä sinun apuasi tarvitaan. Jos kehität tai tuet puitteita, jotka käyttävät sivutusta, pyydän, kehotan sinua tarjoamaan natiivitukea avaimien sivutukselle. Jos sinulla on kysyttävää tai tarvitset apua, autan mielelläni (, , ) (huom: kokemuksestani Marcuksen kanssa voin sanoa, että hän on todella innostunut levittämään tätä aihetta).
Jos käytät valmiita ratkaisuja, jotka mielestäsi ansaitsevat tukea avaimilla sivuttamiseen, tee pyyntö tai tarjoa mahdollisuuksien mukaan valmis ratkaisu. Voit myös linkittää tähän artikkeliin.
Johtopäätös
Syy siihen, miksi niin yksinkertainen ja hyödyllinen lähestymistapa kuin avaimien sivutus ei ole laajalle levinnyt, ei johdu siitä, että se on teknisesti vaikea toteuttaa tai vaatisi paljon vaivaa. Pääsyynä on se, että monet ovat tottuneet näkemään offsetin ja työskentelemään sen kanssa - tämä lähestymistapa sanelee itse standardi.
Tämän seurauksena harvat ajattelevat sivutustavan muuttamista, ja tämän vuoksi kehysten ja kirjastojen instrumentaalinen tuki kehittyy huonosti. Siksi, jos offset-vapaan sivutuksen idea ja tavoite on lähellä sinua, auta levittämään sitä!
Lähde:
Kirjailija: Markus Winand
Lähde: will.com