Joan da datu-basearen errendimendua optimizatzeaz kezkatu beharrik ez zenuen garaia. Denbora ez da geldirik. Enpresari teknologiko berri guztiek hurrengo Facebook sortu nahi dute, eskura ditzaketen datu guztiak biltzen saiatzen diren bitartean. Enpresek datu hauek behar dituzte dirua irabazten laguntzen dieten ereduak hobeto prestatzeko. Baldintza horietan, programatzaileek informazio kopuru handiarekin azkar eta fidagarritasunez lan egiteko aukera ematen duten APIak sortu behar dituzte.
Denbora luzez aplikazio edo datu-baseen backend-ak diseinatzen aritu bazara, ziurrenik kodea idatzi duzu orridun kontsultak egiteko. Adibidez, honela:
SELECT * FROM table_name LIMIT 10 OFFSET 40
Nola dagoen?
Baina horrela egin baduzu zure orria, barkatu esatea ez duzula modu eraginkorrenean egin.
Niri aurka egin nahi al didazu? . , ΠΈ Gaur hitz egin nahi dudan teknikak erabiltzen ari dira jada.
Aipatu inoiz erabili ez duen backend garatzaile bat gutxienez OFFSET ΠΈ LIMIT orrialdedun kontsultak egiteko. MVPn (Gutxieneko Produktu Bideragarria) eta datu kopuru txikiak erabiltzen dituzten proiektuetan, ikuspegi hau nahiko aplikagarria da. "Funtzionatzen du", nolabait esateko.
Baina hutsetik sistema fidagarriak eta eraginkorrak sortu behar badituzu, aldez aurretik zaindu beharko zenuke sistema horietan erabiltzen diren datu-baseak kontsultatzearen eraginkortasunaz.
Gaurkoan, orridun kontsulta-motorren inplementazio arruntekin (txarregia) dauden arazoei buruz hitz egingo dugu, eta nola lortu errendimendu handia kontsulta horiek exekutatzen direnean.
Zer gertatzen da OFFSET eta LIMIT-ekin?
Esan bezala, OFFSET ΠΈ LIMIT Ondo funtzionatzen dute datu kopuru handiekin lan egin behar ez duten proiektuetan.
Arazoa sortzen da datu-basea zerbitzariaren memorian sartzen ez den tamainaraino hazten denean. Hala ere, datu-base honekin lan egiten duzunean, orridun kontsultak erabili behar dituzu.
Arazo hau ager dadin, egoera bat egon behar du DBMSak taula osoko eskaneatu eragiketa ez-eragingarri batera jotzen duen orri-kontsulta bakoitzean (txertatzeko eta ezabatzeko eragiketak gerta daitezkeen bitartean, eta ez dugu datu zaharkitu behar!).
Zer da "taula osoa eskaneatzea" (edo "taula sekuentziala eskaneatzea", eskaneatu sekuentziala)? DBMSak taulako errenkada bakoitza sekuentzialki irakurtzen duen eragiketa da, hau da, bertan dauden datuak, eta baldintza jakin bat betetzen duten egiaztatzen du. Taulen eskaneaketa mota hau motelena dela ezagutzen da. Kontua da exekutatzen denean, zerbitzariaren disko azpisistema inplikatzen duten sarrera/irteera eragiketa asko egiten direla. Egoera larriagotu egiten da diskoetan gordetako datuekin lan egitearekin loturiko atzerapenengatik, eta datuak diskotik memoriara transferitzea baliabideen erabilera intentsiboa izateak.
Adibidez, 100000000 erabiltzaileren erregistroak dituzu eta kontsulta bat exekutatzen duzu eraikuntzarekin OFFSET 50000000. Horrek esan nahi du DBMSak erregistro horiek guztiak kargatu beharko dituela (eta ez ditugu behar ere!), memorian jarri eta horren ostean, demagun, 20 emaitza hartu beharko ditu. LIMIT.
Demagun honelakoa izan daitekeela: "hautatu 50000tik 50020ra bitarteko errenkadak 100000tik". Hau da, sistemak lehenik 50000 errenkada kargatu beharko ditu kontsulta osatzeko. Ikusten al duzu alferrikako zenbat lan egin beharko duen?
Ez badidazu sinesten, begiratu funtzioak erabiliz sortu dudan adibideari .
Adibidea db-fiddle.com webgunean
Han, ezkerrean, zelaian Schema SQL, 100000 errenkada txertatzen dituen kodea dago datu-basean, eta eskuinaldean, eremuan Query SQL, bi kontsulta erakusten dira. Lehenengoa, motela, honelakoa da:
SELECT *
FROM `docs`
LIMIT 10 OFFSET 85000;
Eta bigarrena, arazo beraren konponbide eraginkorra dena, honelakoa da:
SELECT *
FROM `docs`
WHERE id > 85000
LIMIT 10;
Eskaera hauek betetzeko, botoian klik egin besterik ez dago Run orriaren goialdean. Hau eginda, kontsultaren exekuzio denborari buruzko informazioa konparatzen dugu. Eraginkorra ez den kontsulta bat exekutatzeko bigarrena exekutatzeko baino 30 aldiz gehiago behar izaten da (denbora hau exekuzio batetik bestera aldatu egiten da; adibidez, sistemak jakinarazi dezake lehenengo kontsulta 37 ms behar izan duela amaitzeko, baina exekuzioak bigarren - 1 ms).
Eta datu gehiago egonez gero, dena are okerrago izango da (honetaz konbentzitzeko, begiratu nire 10 milioi errenkadarekin).
Aztertu berri dugunak datu-baseen kontsultak benetan nola prozesatzen diren jakiteko aukera emango dizu.
Kontuan izan zenbat eta balio handiagoa izan OFFSET β Zenbat eta denbora gehiago beharko du eskaerak betetzeko.
Zer erabili behar dut OFFSET eta LIMIT konbinazioaren ordez?
Konbinazio baten ordez OFFSET ΠΈ LIMIT Merezi du eskema honen arabera eraikitako egitura erabiltzea:
SELECT * FROM table_name WHERE id > 10 LIMIT 20
Hau kontsultaren exekuzioa da kurtsorean oinarritutako orriketarekin.
Oraingoak lokalean gorde beharrean OFFSET ΠΈ LIMIT eta bidali eskaera bakoitzarekin, jasotako azken gako nagusia gorde behar duzu (normalean hau da ID) Eta LIMIT, ondorioz, aurrekoaren antzeko kontsultak lortuko dira.
Zergatik? Kontua da irakurritako azken errenkadaren identifikatzailea esplizituki zehaztuz, zure DBMS-a esango diozula non hasi behar duen beharrezko datuak bilatzen. Gainera, bilaketa, giltzaren erabilerari esker, modu eraginkorrean egingo da; sistema ez da zehaztutako barrutitik kanpoko lerroekin distraitu beharko.
Ikus ditzagun hainbat kontsultaren errendimenduaren konparaketari. Hona hemen eraginkortasunik gabeko kontsulta bat.
Eskaera motela
Eta hona hemen eskaera honen bertsio optimizatua.
Eskaera azkarra
Bi kontsultak datu kopuru bera itzultzen dute. Baina lehenengoak 12,80 segundo behar ditu osatzeko, eta bigarrenak 0,01 segundo. Diferentzia sentitzen al duzu?
Arazo posibleak
Proposatutako kontsulta-metodoak modu eraginkorrean funtziona dezan, taulak indize sekuentzial esklusiboak dituen zutabe bat (edo zutabeak) izan behar du, esate baterako, osoko identifikatzaile bat. Kasu zehatz batzuetan, horrek datu-basearekin lan egiteko abiadura handitzeko kontsulta horiek erabiltzearen arrakasta erabaki dezake.
Jakina, kontsultak eraikitzerakoan, taulen arkitektura espezifikoa kontuan hartu behar duzu eta lehendik dauden tauletan ondoen funtzionatuko duten mekanismoak aukeratu behar dituzu. Adibidez, erlazionatutako datu-bolumen handiak dituzten kontsultetan lan egin behar baduzu, agian interesgarria irudituko zaizu Artikulu.
Lehen gako bat galtzearen arazoaren aurrean bagaude, adibidez, askotariko harremana duen mahai bat badugu, orduan erabiltzearen ikuspegi tradizionala. OFFSET ΠΈ LIMIT, guri egokituko zaigula bermatuta dago. Baina erabilerak kontsulta motelak sor ditzake. Horrelako kasuetan, automatikoki gehitzen den lehen gako bat erabiltzea gomendatuko nuke, orrialdedun kontsultak kudeatzeko soilik beharrezkoa bada ere.
Gai hau interesatzen bazaizu - , ΠΈ - Hainbat material erabilgarria.
Emaitzak
Atera dezakegun ondorio nagusia zera da: edozein datu-baseen tamainaz ari garen, beti beharrezkoa da kontsultaren exekuzio-abiadura aztertzea. Gaur egun, soluzioen eskalagarritasuna oso garrantzitsua da, eta sistema jakin batean lan egiten den hasieratik dena behar bezala diseinatzen bada, honek, etorkizunean, garatzailea arazo askotatik salba dezake.
Nola aztertzen eta optimizatzen dituzu datu-basearen kontsultak?
Iturria: www.habr.com