Pershendetje te gjitheve! Unë jam një zhvillues mbështetës që shkruaj mikroshërbime në Java + Spring. Unë punoj në një nga ekipet e brendshme të zhvillimit të produktit në Tinkoff.
Në ekipin tonë, shpesh lind pyetja e optimizimit të pyetjeve në një DBMS. Ju gjithmonë dëshironi të jeni pak më të shpejtë, por nuk mund t'ia dilni gjithmonë me indekse të ndërtuara në mënyrë të menduar-duhet të kërkoni disa zgjidhje. Gjatë një prej këtyre bredhjeve nëpër ueb në kërkim të optimizimeve të arsyeshme gjatë punës me bazat e të dhënave, gjeta , autor i SQL Performance Explained. Ky është lloji i rrallë i blogut në të cilin mund të lexoni të gjithë artikujt me radhë.
Do të doja të përkthej një artikull të shkurtër nga Marcus për ju. Mund të quhet deri diku një manifest që kërkon të tërheqë vëmendjen te problemi i vjetër, por ende i rëndësishëm i performancës së operacionit të kompensimit sipas standardit SQL.
Në disa vende do ta plotësoj autorin me shpjegime dhe komente. Unë do t'i referohem të gjitha vendeve të tilla si "përafërsisht". për më shumë qartësi
Paraqitje e vogël
Unë mendoj se shumë njerëz e dinë se sa problematike dhe e ngadaltë është puna me zgjedhjen e faqeve përmes offset. A e dini se mund të zëvendësohet mjaft lehtë me një dizajn më efikas?
Pra, fjala kyçe offset i thotë bazës së të dhënave të kapërcejë n regjistrimet e para në kërkesë. Megjithatë, baza e të dhënave ende duhet të lexojë këto n regjistrime të para nga disku, në rendin e dhënë (shënim: aplikoni renditjen nëse është specifikuar), dhe vetëm atëherë do të jetë e mundur të kthehen të dhënat nga n+1 e tutje. Gjëja më interesante është se problemi nuk është në zbatimin specifik në DBMS, por në përkufizimin origjinal sipas standardit:
… rreshtat së pari renditen sipas dhe më pas kufizohet duke hequr numrin e rreshtave të specifikuar në nga fillimi…
-SQL:2016, Pjesa 2, 4.15.3 Tabelat e prejardhura (shënim: aktualisht standardi më i përdorur)
Pika kryesore këtu është se kompensimi merr një parametër të vetëm - numrin e regjistrimeve që duhet të kapërcehen, dhe kaq. Pas këtij përkufizimi, DBMS mund të marrë vetëm të gjitha të dhënat dhe më pas të heqë ato të panevojshme. Natyrisht, ky përkufizim i kompensimit na detyron të bëjmë punë shtesë. Dhe nuk ka rëndësi nëse është SQL apo NoSQL.
Vetëm pak më shumë dhimbje
Problemet me kompensimin nuk mbarojnë këtu, dhe ja pse. Nëse, ndërmjet leximit të dy faqeve të të dhënave nga disku, një operacion tjetër fut një rekord të ri, çfarë do të ndodhë në këtë rast?
Kur offset përdoret për të kapërcyer regjistrimet nga faqet e mëparshme, në situatën e shtimit të një rekordi të ri midis leximeve të faqeve të ndryshme, ka shumë të ngjarë të merrni dublikatë (shënim: kjo është e mundur kur lexojmë faqe për faqe duke përdorur renditjen sipas konstruksionit, atëherë në mes të prodhimit tonë mund të ketë një hyrje të re).
Figura përshkruan qartë këtë situatë. Baza lexon 10 regjistrimet e para, pas së cilës futet një rekord i ri, i cili kompenson të gjitha rekordet e leximit me 1. Më pas baza merr një faqe të re nga 10 regjistrimet e radhës dhe fillon jo nga e 11-ta, siç duhet, por nga 10, duke dubluar këtë rekord. Ka anomali të tjera që lidhen me përdorimin e kësaj shprehjeje, por kjo është më e zakonshme.
Siç e kemi kuptuar tashmë, këto nuk janë probleme të një DBMS specifike ose zbatimeve të tyre. Problemi është në përcaktimin e faqes sipas standardit SQL. Ne i tregojmë DBMS-së se cilën faqe duhet të marrë ose sa regjistrime duhet të kapërcejë. Baza e të dhënave thjesht nuk është në gjendje të optimizojë një kërkesë të tillë, pasi ka shumë pak informacion për këtë.
Vlen gjithashtu të sqarohet se ky nuk është një problem me një fjalë kyçe specifike, por më tepër me semantikën e pyetjes. Ka disa sintaksa të tjera që janë identike në natyrën e tyre problematike:
- Fjala kyçe e kompensimit është siç u përmend më herët.
- Një ndërtim i dy fjalë kyçe limit [offset] (edhe pse vetë limiti nuk është aq i keq).
- Filtrimi sipas kufijve të poshtëm, bazuar në numërimin e rreshtave (për shembull, row_number(), rownum, etj.).
Të gjitha këto shprehje thjesht ju tregojnë se sa rreshta duhet të kaloni, pa informacion ose kontekst shtesë.
Më vonë në këtë artikull, fjala kyçe e kompensimit përdoret si një përmbledhje e të gjitha këtyre opsioneve.
Jeta pa OFFSET
Tani le të imagjinojmë se si do të ishte bota jonë pa të gjitha këto probleme. Rezulton se jeta pa kompensim nuk është aq e vështirë: me një përzgjedhje, mund të zgjidhni vetëm ato rreshta që nuk i kemi parë ende (shënim: domethënë ato që nuk ishin në faqen e mëparshme), duke përdorur një kusht ku.
Në këtë rast, ne nisemi nga fakti që përzgjedhjet ekzekutohen në një grup të porositur (rend i vjetër i mirë nga). Meqenëse kemi një grup të porositur, mund të përdorim një filtër mjaft të thjeshtë për të marrë vetëm të dhënat që janë prapa rekordit të fundit të faqes së mëparshme:
SELECT ...
FROM ...
WHERE ...
AND id < ?last_seen_id
ORDER BY id DESC
FETCH FIRST 10 ROWS ONLYKy është i gjithë parimi i kësaj qasjeje. Sigurisht, gjërat bëhen më argëtuese kur renditen sipas shumë kolonave, por ideja është ende e njëjtë. Është e rëndësishme të theksohet se ky dizajn është i zbatueshëm për shumë -vendimet.
Kjo qasje quhet metoda e kërkimit ose pagifikimi i grupit të çelësave. Ai zgjidh problemin e rezultatit lundrues (shënim: situata me shkrimin midis leximeve të faqeve të përshkruara më herët) dhe, natyrisht, ajo që ne të gjithë e duam, funksionon më shpejt dhe më e qëndrueshme se kompensimi klasik. Stabiliteti qëndron në faktin se koha e përpunimit të kërkesës nuk rritet në përpjesëtim me numrin e tabelës së kërkuar (shënim: nëse dëshironi të mësoni më shumë rreth punës së qasjeve të ndryshme të faqesimit, mund të . Këtu mund të gjeni edhe standarde krahasuese për metoda të ndryshme).
Një nga rrëshqitjet se faqëzimi me çelësa, natyrisht, nuk është i gjithëfuqishëm - ai ka kufizimet e veta. Më e rëndësishmja është se ajo nuk ka aftësinë për të lexuar faqe të rastësishme (shënim: në mënyrë jokonsistente). Sidoqoftë, në epokën e lëvizjes së pafund (shënim: në pjesën e përparme), ky nuk është një problem i tillë. Përcaktimi i një numri faqeje për klikim është gjithsesi një vendim i keq në dizajnin e UI (shënim: mendimi i autorit të artikullit).
Po mjetet?
Fletëzimi në çelësa shpesh nuk është i përshtatshëm për shkak të mungesës së mbështetjes instrumentale për këtë metodë. Shumica e mjeteve të zhvillimit, duke përfshirë korniza të ndryshme, nuk ju lejojnë të zgjidhni saktësisht se si do të kryhet faqezimi.
Situata përkeqësohet nga fakti se metoda e përshkruar kërkon mbështetje nga fundi në fund në teknologjitë e përdorura - nga DBMS deri në ekzekutimin e një kërkese AJAX në shfletues me lëvizje të pafundme. Në vend që të specifikoni vetëm numrin e faqes, tani duhet të specifikoni një grup çelësash për të gjitha faqet menjëherë.
Megjithatë, numri i kornizave që mbështesin pagimin në çelësa po rritet gradualisht. Ja çfarë kemi për momentin:
- për Java;
- për Rubin;
- и për Django;
- për Python;
- — API-ja e kritereve për zbatimin e JPA-së;
- për Perl;
- , hartues për Node.js .
(Shënim: disa lidhje u hoqën për faktin se në kohën e përkthimit disa biblioteka nuk ishin përditësuar që nga viti 2017-2018. Nëse jeni të interesuar, mund të shikoni burimin origjinal.)
Pikërisht në këtë moment nevojitet ndihma juaj. Nëse zhvilloni ose mbështetni një kornizë që përdor ndonjë faqezim, atëherë ju kërkoj, ju bëj thirrje, ju lutem që të ofroni mbështetje vendase për pagimin në çelësa. Nëse keni pyetje ose keni nevojë për ndihmë, unë do të jem i lumtur t'ju ndihmoj (, , ) (shënim: nga përvoja ime me Marcus, mund të them se ai është vërtet entuziast për përhapjen e kësaj teme).
Nëse përdorni zgjidhje të gatshme që mendoni se meritojnë mbështetje për pagimin me çelësa, krijoni një kërkesë ose madje ofroni një zgjidhje të gatshme, nëse është e mundur. Ju gjithashtu mund të lidheni me këtë artikull.
Përfundim
Arsyeja pse një qasje kaq e thjeshtë dhe e dobishme, si faqëzimi me çelësa, nuk është e përhapur nuk është se është e vështirë të zbatohet teknikisht ose kërkon ndonjë përpjekje të madhe. Arsyeja kryesore është se shumë janë mësuar të shohin dhe punojnë me kompensim - kjo qasje diktohet nga vetë standardi.
Si rezultat, pak njerëz mendojnë për ndryshimin e qasjes ndaj faqes, dhe për shkak të kësaj, mbështetja instrumentale nga kornizat dhe bibliotekat po zhvillohet dobët. Prandaj, nëse ideja dhe qëllimi i faqes pa kompensim është afër jush, ndihmoni ta përhapni atë!
Burimi:
Autor: Markus Winand
Burimi: www.habr.com