Saluton al ĉiuj! Mi estas backend-programisto skribanta mikroservojn en Java + Spring. Mi laboras en unu el la internaj produkt-disvolvaj teamoj ĉe Tinkoff.
En nia teamo ofte aperas la demando pri optimumigo de demandoj en DBMS. Vi ĉiam volas esti iom pli rapida, sed vi ne ĉiam povas elteni per penseme konstruitaj indeksoj—vi devas serĉi iujn solvojn. Dum unu el ĉi tiuj vagadoj tra la reto serĉante raciajn optimumojn kiam vi laboras kun datumbazoj, mi trovis , verkinto de SQL Performance Explained. Jen tiu malofta tipo de blogo, en kiu vi povas legi ĉiujn artikolojn en vico.
Mi ŝatus traduki por vi mallongan artikolon de Marcus. Oni povas nomi ĝin iagrade manifesto, kiu celas atentigi la malnovan, sed ankoraŭ gravan problemon de la agado de la ofseta operacio laŭ la SQL-normo.
Kelkloke mi kompletigos la aŭtoron per klarigoj kaj komentoj. Mi aludos ĉiujn tiajn lokojn kiel "ĉ." por pli da klareco
Malgranda enkonduko
Mi pensas, ke multaj homoj scias kiom problema kaj malrapida estas labori kun paĝo-elektoj per ofseto. Ĉu vi scias, ke ĝi povas esti sufiĉe facile anstataŭigita per pli efika dezajno?
Do, la kompensa ŝlosilvorto diras al la datumbazo preterpasi la unuajn n rekordojn en la peto. Tamen, la datumbazo ankoraŭ bezonas legi ĉi tiujn unuajn n rekordojn el disko, en la donita ordo (noto: apliki ordigon se ĝi estas specifita), kaj nur tiam eblos resendi rekordojn de n+1 pluen. La plej interesa afero estas, ke la problemo ne estas en la specifa efektivigo en la DBMS, sed en la originala difino laŭ la normo:
…la vicoj unue estas ordigitaj laŭ la kaj tiam limigita per faligado de la nombro da vicoj specifita en la de la komenco...
-SQL:2016, Parto 2, 4.15.3 Derivitaj tabeloj (noto: nuntempe la plej uzata normo)
La ŝlosila punkto ĉi tie estas, ke kompenso prenas ununuran parametron - la nombron da rekordoj por salti, kaj jen ĝi. Sekvante ĉi tiun difinon, la DBMS povas nur retrovi ĉiujn rekordojn kaj poste forĵeti la nenecesajn. Evidente, ĉi tiu difino de ofseto devigas nin fari kroman laboron. Kaj eĉ ne gravas ĉu ĝi estas SQL aŭ NoSQL.
Nur iom pli da doloro
La problemoj kun ofseto ne finiĝas tie, kaj jen kial. Se, inter legado de du paĝoj de datumoj el disko, alia operacio enmetas novan rekordon, kio okazos en ĉi tiu kazo?
Kiam ofseto estas uzata por salti rekordojn de antaŭaj paĝoj, en la situacio de aldoni novan rekordon inter legaĵoj de malsamaj paĝoj, vi plej verŝajne ricevos duplikatojn (noto: tio eblas kiam ni legas paĝon post paĝo uzante la ordo laŭ konstruo, tiam meze de nia eligo ĝi povas ricevi novan eniron).
La figuro klare prezentas ĉi tiun situacion. La bazo legas la unuajn 10 registrojn, post kio nova registro estas enmetita, kiu kompensas ĉiujn legitajn registrojn je 1. Tiam la bazo prenas novan paĝon de la sekvaj 10 registroj kaj komenciĝas ne de la 11-a, kiel ĝi devus, sed de la 10-a, duobligante ĉi tiun rekordon. Estas aliaj anomalioj asociitaj kun la uzo de ĉi tiu esprimo, sed ĉi tiu estas la plej ofta.
Kiel ni jam eksciis, ĉi tiuj ne estas problemoj de specifa DBMS aŭ iliaj efektivigoj. La problemo estas en difini paĝigon laŭ la SQL-normo. Ni diras al la DBMS kiun paĝon por preni aŭ kiom da registroj transsalti. La datumbazo simple ne kapablas optimumigi tian peton, ĉar ekzistas tro malmulte da informoj por tio.
Ankaŭ indas klarigi, ke tio ne estas problemo pri specifa ŝlosilvorto, sed prefere kun la semantiko de la konsulto. Ekzistas pluraj pli da sintaksoj kiuj estas identaj en sia problema naturo:
- La kompensa ŝlosilvorto estas kiel menciita antaŭe.
- Konstruo de du ŝlosilvortoj limo [offset] (kvankam limigi mem ne estas tiel malbona).
- Filtrado per malsuperaj limoj, surbaze de viconumero (ekzemple, vico_numero(), viconumero, ktp.).
Ĉiuj ĉi tiuj esprimoj simple diras al vi kiom da linioj transsalti, neniuj aldonaj informoj aŭ kunteksto.
Poste en ĉi tiu artikolo, la kompensa ŝlosilvorto estas uzata kiel resumo de ĉiuj ĉi tiuj opcioj.
Vivo sen OFFSETO
Nun ni imagu, kia estus nia mondo sen ĉiuj ĉi tiuj problemoj. Montriĝas, ke vivo sen ofseto ne estas tiel malfacila: per elekto, vi povas elekti nur tiujn vicojn, kiujn ni ankoraŭ ne vidis (notu: tio estas, tiujn, kiuj ne estis sur la antaŭa paĝo), uzante kondiĉon en kie.
En ĉi tiu kazo, ni komencas de la fakto, ke elektoj estas ekzekutitaj sur ordigita aro (bona malnova ordo per). Ĉar ni havas ordigitan aron, ni povas uzi sufiĉe simplan filtrilon por akiri nur la datumojn kiuj estas malantaŭ la lasta rekordo de la antaŭa paĝo:
SELECT ...
FROM ...
WHERE ...
AND id < ?last_seen_id
ORDER BY id DESC
FETCH FIRST 10 ROWS ONLYTio estas la tuta principo de ĉi tiu aliro. Kompreneble, aferoj fariĝas pli amuzaj kiam oni ordigas laŭ multaj kolumnoj, sed la ideo daŭre estas la sama. Gravas noti, ke ĉi tiu dezajno estas aplikebla al multaj -decidoj.
Ĉi tiu aliro nomiĝas serĉmetodo aŭ paĝigo de klavariloj. Ĝi solvas la flosan rezultoproblemon (notu: la situacio kun skribo inter paĝaj legadoj, priskribita antaŭe) kaj, kompreneble, kion ni ĉiuj amas, ĝi funkcias pli rapide kaj stabile ol la klasika ofseto. Stabileco kuŝas en tio, ke la tempo de procesado de petoj ne pliiĝas proporcie al la nombro de la petita tabelo (noto: se vi volas lerni pli pri la laboro de malsamaj aliroj al paĝigo, vi povas . Vi ankaŭ povas trovi komparajn benchmarkojn por malsamaj metodoj tie).
Unu el la diapozitivoj tiu paĝigo per klavoj, kompreneble, ne estas ĉiopova – ĝi havas siajn limojn. La plej signifa estas ke ŝi ne havas la kapablon legi hazardajn paĝojn (notu: malkonsekvence). Tamen, en la epoko de senfina movo (noto: ĉe la antaŭa fino), ĉi tio ne estas tia problemo. Specifi paĝnumeron por klakado estas ĉiuokaze malbona decido en UI-dezajno (noto: opinio de la aŭtoro de la artikolo).
Kio pri la iloj?
Paĝigo sur klavoj ofte ne taŭgas pro la manko de instrumenta subteno por ĉi tiu metodo. Plej multaj evoluiloj, inkluzive de diversaj kadroj, ne permesas al vi elekti precize kiel paĝigo estos farita.
La situacio estas pligravigita de la fakto, ke la priskribita metodo postulas fin-al-finan subtenon en la uzataj teknologioj - de la DBMS ĝis la plenumo de AJAX-peto en la retumilo kun senfina movo. Anstataŭ specifi nur la paĝnumeron, vi nun devas specifi aron da klavoj por ĉiuj paĝoj samtempe.
Tamen, la nombro da kadroj kiuj subtenas paĝigon sur ŝlosiloj iom post iom kreskas. Jen kion ni havas nuntempe:
- por Java;
- por Ruby;
- и por Django;
- por Python;
- — kriterioj API por JPA-efektivigoj;
- por Perl;
- , mapisto por Node.js .
(Noto: kelkaj ligiloj estis forigitaj pro tio, ke en la momento de la tradukado iuj bibliotekoj ne estis ĝisdatigitaj ekde 2017-2018. Se vi interesiĝas, vi povas rigardi la originan fonton.)
Ĝuste ĉi-momente via helpo estas bezonata. Se vi disvolvas aŭ subtenas kadron kiu faras ajnan uzon de paĝigo, tiam mi petas, mi instigas, mi petegas vin provizi denaskan subtenon por paĝigo sur ŝlosiloj. Se vi havas demandojn aŭ bezonas helpon, mi volonte helpos (, , ) (rimarku: laŭ mia sperto kun Marcus, mi povas diri, ke li vere entuziasmas pri disvastigo de ĉi tiu temo).
Se vi uzas pretajn solvojn, kiujn vi opinias indaj havi subtenon por paĝigo per klavoj, kreu peton aŭ eĉ proponu pretan solvon, se eble. Vi ankaŭ povas ligi al ĉi tiu artikolo.
konkludo
La kialo, kial tia simpla kaj utila aliro kiel paĝigo per klavoj ne estas disvastigita, ne estas ke ĝi estas malfacile efektivigi teknike aŭ postulas ajnan grandan penon. La ĉefa kialo estas, ke multaj kutimas vidi kaj labori kun ofseto - ĉi tiu aliro estas diktita de la normo mem.
Kiel rezulto, malmultaj homoj pensas pri ŝanĝi la aliron al paĝigo, kaj pro tio instrumenta subteno de kadroj kaj bibliotekoj malbone disvolviĝas. Tial, se la ideo kaj celo de senpaga paĝigo estas proksimaj al vi, helpu disvastigi ĝin!
fonto:
Aŭtoro: Markus Winand
fonto: www.habr.com