Kaixo guztioi! Java + Spring-en mikrozerbitzuak idazten dituen backend garatzaile bat naiz. Tinkoff-en barne produktuen garapen taldeetako batean egiten dut lan.
Gure taldean, DBMS bateko kontsultak optimizatzearen galdera sortzen da maiz. Beti apur bat azkarragoa izan nahi duzu, baina ezin zara beti ondo eraikitako indizeekin konpondu; konponbide batzuk bilatu behar dituzu. Datu-baseekin lan egitean arrazoizko optimizazioen bila sarean ibilaldi horietako batean aurkitu nuen , SQL Performance Explained liburuaren egilea. Artikulu guztiak jarraian irakur ditzakezun blog mota arraroa da hau.
Marcusen artikulu labur bat itzuli nahiko nuke zuretzat. Hein batean, SQL estandarraren arabera offset eragiketaren errendimenduaren arazo zaharrari arreta erakarri nahi dion manifestua dei daiteke neurri batean.
Leku batzuetan egileari azalpen eta iruzkinekin osatuko dut. Horrelako leku guztiak "gutxi gorabehera" bezala aipatuko ditut. argitasun gehiagorako
Sarrera txiki bat
Uste dut jende askok badakiela zein arazo eta geldoa den desplazamendu bidezko orrialdeen hautapenekin lan egitea. Ba al zenekien diseinu eraginkorrago batekin nahiko erraz ordezkatu daitekeela?
Beraz, offset gako-hitzak datu-baseari eskaerako lehen n erregistroak saltatzeko esaten dio. Hala ere, datu-baseak oraindik ere lehen n erregistro hauek irakurri behar ditu diskotik, emandako ordenan (oharra: aplikatu ordenazioa zehazten bada), eta orduan bakarrik posible izango da n+1etik aurrerako erregistroak itzultzea. Interesgarriena da arazoa ez dagoela DBMSko inplementazio espezifikoan, estandarraren araberako jatorrizko definizioan baizik:
β¦ errenkadak lehenik eta behin ordenatzen dira eta, ondoren, mugatuta dago zehaztutako errenkada kopurua jaitsiz hasieratikβ¦
-SQL:2016, 2. zatia, 4.15.3 Taula eratorriak (oharra: gaur egun gehien erabiltzen den estandarra)
Hemen gakoa da desplazamenduak parametro bakarra hartzen duela: saltatu beharreko erregistro kopurua, eta kito. Definizio horri jarraituz, DBMSak erregistro guztiak berreskura ditzake eta gero beharrezkoak ez direnak baztertu. Jakina, offsetaren definizio honek aparteko lan egitera behartzen gaitu. Eta berdin dio SQL edo NoSQL den ere.
Min pixka bat gehiago besterik ez
Offsetarekin arazoak ez dira hor amaitzen, eta hona hemen zergatik. Diskotik bi datu-orri irakurri artean, beste eragiketa batek erregistro berri bat txertatzen badu, zer gertatuko da kasu honetan?
Desplazamendua aurreko orrialdeetako erregistroak saltatzeko erabiltzen denean, orrialde ezberdinen irakurketen artean erregistro berri bat gehitzeko egoeran, ziurrenik bikoiztuak lortuko dituzu (oharra: hori posible da orriz orrialde irakurtzen dugunean eraikitze-ordena erabiliz, orduan gure irteeraren erdian sarrera berri bat lor daiteke).
Irudiak argi erakusten du egoera hori. Oinarriak lehenengo 10 erregistroak irakurtzen ditu, eta ondoren erregistro berri bat txertatzen da, eta horrek irakurritako erregistro guztiak 1ez konpentsatzen ditu. Ondoren, oinarriak hurrengo 10 erregistroetatik orri berri bat hartzen du eta ez da 11.etik abiatzen, behar den bezala, baizik. 10ean, erregistro hau bikoiztuz. Adierazpen honen erabilerarekin lotutako beste anomalia batzuk daude, baina hori da ohikoena.
Dagoeneko jakin dugunez, hauek ez dira DBMS zehatz batekin edo haien inplementazioekin arazoak. Arazoa orria SQL estandarraren arabera definitzean da. DBMSari esaten diogu zein orrialde eskuratu edo zenbat erregistro saltatu. Datu-basea ezin da horrelako eskaera optimizatzeko gai, informazio gutxi baitago horretarako.
Era berean, argitzea komeni da hori ez dela gako-hitz zehatz baten arazoa, kontsultaren semantikarena baizik. Badira beste hainbat sintaxik bere izaera problematikoan berdinak direnak:
- Offset gako-hitza lehen aipatu bezala da.
- Bi gako-hitzen eraikuntza [desplazamendua] muga (nahiz eta muga bera ez den hain txarra).
- Beheko mugen arabera iragaztea, errenkaden zenbakiaren arabera (adibidez, errenkada_zenbakia(), errenkada zenbakia, etab.).
Adierazpen horiek guztiek zenbat lerro saltatu behar diren esaten dizute, informazio edo testuinguru gehigarririk gabe.
Artikulu honetan aurrerago, offset gako-hitza aukera horien guztien laburpen gisa erabiltzen da.
OFFSET gabeko bizitza
Orain imajina dezagun nolakoa izango litzatekeen gure mundua arazo guzti hauek gabe. Ematen du desplazamendurik gabeko bizitza ez dela hain zaila: aukeraketa batekin, oraindik ikusi ez ditugun errenkadak soilik hauta ditzakezu (oharra: hau da, aurreko orrialdean ez zeudenak), non baldintza bat erabiliz.
Kasu honetan, hautaketak ordenatutako multzo batean exekutatzen direnetik abiatzen gara (ordena zaharraren arabera). Multzo ordenatua dugunez, iragazki nahiko sinple bat erabil dezakegu aurreko orrialdeko azken erregistroaren atzean dauden datuak soilik lortzeko:
SELECT ...
FROM ...
WHERE ...
AND id < ?last_seen_id
ORDER BY id DESC
FETCH FIRST 10 ROWS ONLYHori da ikuspegi honen printzipio osoa. Noski, gauzak dibertigarriagoak izaten dira zutabe askoren arabera ordenatzean, baina ideia berdina da. Garrantzitsua da diseinu hau askorentzat aplikagarria dela -erabakiak.
Ikuspegi honi seek metodoa edo gako multzoen orriketa deritzo. Emaitza flotagarriaren arazoa konpontzen du (oharra: lehenago deskribatutako orrialdeen irakurketen arteko idazketaren egoera) eta, noski, guztiok maite duguna, offset klasikoak baino azkarrago eta egonkorrago funtzionatzen du. Egonkortasuna eskaerak prozesatzeko denbora ez dela handitzen eskatutako taula kopuruaren proportzioan datza (oharra: orria egiteko ikuspegi ezberdinen lanari buruz gehiago jakin nahi baduzu, dezakezu . Metodo ezberdinetarako erreferentzia konparatiboak ere aurki ditzakezu bertan).
Diapositibetako bat gakoen bidezko orrialdeketa hori, noski, ez da ahalguztiduna βbadu bere mugakβ. Esanguratsuena da ez duela ausazko orriak irakurtzeko gaitasunik (oharra: koherentziarik gabe). Hala ere, korritze amaigabearen garaian (oharra: aurrealdean), hau ez da horrelako arazoa. Klik egiteko orrialde-zenbaki bat zehaztea erabaki txarra da UI diseinuan, hala ere (oharra: artikuluaren egilearen iritzia).
Zer esan tresnak?
Teklen orria ez da egokia izaten metodo honen euskarri instrumental faltagatik. Garapen-tresna gehienek, hainbat esparru barne, ez dizute aukeratzen orria nola egingo den zehatz-mehatz aukeratzen.
Egoera larriagotu egiten da deskribatutako metodoak erabilitako teknologietan amaierako laguntza behar duelako - DBMStik hasi eta arakatzailean AJAX eskaera bat exekutatzeko korritze amaigabearekin. Orri-zenbakia soilik zehaztu beharrean, orain orri guztietarako gako multzo bat zehaztu behar duzu aldi berean.
Dena den, gakoetan orrialdekatzea onartzen duten markoen kopurua hazten ari da pixkanaka. Hona hemen momentu honetan daukaguna:
- Javarako;
- Rubyrentzat;
- ΠΈ Djangorentzat;
- Pythonentzat;
- β JPA inplementazioetarako irizpideen APIa;
- Perlentzat;
- , Node.js-erako mapatzailea .
(Oharra: esteka batzuk kendu egin ziren itzulpenaren garaian liburutegi batzuk 2017-2018tik eguneratu gabe zeudenez. Interesa baduzu, iturrira begiratu dezakezu.)
Momentu honetan zure laguntza behar da. Orrigintzaren erabileraren bat egiten duen esparru bat garatzen edo onartzen baduzu, orduan eskatzen dizut, eskatzen dizut, erregutzen dizut gakoetan orria egiteko jatorrizko laguntza eskaintzeko. Galderarik baduzu edo laguntza behar baduzu, pozik lagunduko dizut (, , ) (oharra: Marcusekin dudan esperientziatik, esan dezaket oso gogotsu dagoela gai hau zabaltzeko).
Teklen bidez orria egiteko euskarria izatea merezi dutela uste duzun prest dauden irtenbideak erabiltzen badituzu, sortu eskaera edo baita prestaturiko irtenbide bat ere eskaini, ahal bada. Artikulu honetara esteka dezakezu.
Ondorioa
Teklen bidezko orrialdekatzea bezalako ikuspegi sinple eta erabilgarria ez izatearen arrazoia ez da teknikoki ezartzea zaila dela edo ahalegin handia eskatzen duela. Arrazoi nagusia da asko ohituta daudela offsetarekin ikusten eta lan egiten - ikuspegi hau estandarrak berak aginduta dago.
Ondorioz, jende gutxik pentsatzen du orrigintzaren ikuspegia aldatzea, eta horregatik, esparru eta liburutegien laguntza instrumentala gaizki garatzen ari da. Hori dela eta, offset-free orrialdetazioaren ideia eta helburua gertu badaukazu, lagundu zabaltzen!
Iturria:
Egilea: Markus Winand
Iturria: www.habr.com