Mae'r dyddiau pan nad oedd yn rhaid i chi boeni am optimeiddio perfformiad cronfa ddata wedi mynd. Nid yw amser yn aros yn ei unfan. Mae pob entrepreneur technoleg newydd eisiau creu'r Facebook nesaf, wrth geisio casglu'r holl ddata y gallant gael eu dwylo arno. Mae angen y data hwn ar fusnesau i hyfforddi modelau sy'n eu helpu i wneud arian yn well. Mewn amodau o'r fath, mae angen i raglenwyr greu APIs sy'n caniatΓ‘u iddynt weithio'n gyflym ac yn ddibynadwy gyda llawer iawn o wybodaeth.
Os ydych chi wedi bod yn dylunio Γ΄l-daliadau cymhwysiad neu gronfa ddata am unrhyw gyfnod o amser, mae'n debyg eich bod wedi ysgrifennu cod i redeg ymholiadau tudalenedig. Er enghraifft, fel hyn:
SELECT * FROM table_name LIMIT 10 OFFSET 40
Y ffordd y mae?
Ond os mai dyma sut y gwnaethoch chi eich tudalen, mae'n ddrwg gen i ddweud na wnaethoch chi ddim yn y ffordd fwyaf effeithlon.
Ydych chi am wrthwynebu i mi? . , ΠΈ Maent eisoes yn defnyddio'r technegau yr wyf am siarad amdanynt heddiw.
Enwch o leiaf un datblygwr backend sydd erioed wedi defnyddio OFFSET ΠΈ LIMIT i gyflawni ymholiadau tudalen. Mewn MVP (Isafswm Cynnyrch Hyfyw) ac mewn prosiectau lle defnyddir symiau bach o ddata, mae'r dull hwn yn eithaf perthnasol. Mae'n βgweithio,β fel petai.
Ond os oes angen i chi greu systemau dibynadwy ac effeithlon o'r dechrau, dylech gymryd gofal ymlaen llaw ynghylch effeithlonrwydd cwestiynu'r cronfeydd data a ddefnyddir mewn systemau o'r fath.
Heddiw, byddwn yn siarad am y problemau gyda gweithrediadau a ddefnyddir yn gyffredin (rhy ddrwg) o beiriannau ymholiad tudalen, a sut i gyflawni perfformiad uchel wrth weithredu ymholiadau o'r fath.
Beth sydd o'i le ar OFFSET a LIMIT?
Fel y dywedwyd eisoes, OFFSET ΠΈ LIMIT Maent yn perfformio'n dda mewn prosiectau nad oes angen iddynt weithio gyda symiau mawr o ddata.
Mae'r broblem yn codi pan fydd y gronfa ddata'n tyfu i'r fath faint fel nad yw bellach yn ffitio yng nghof y gweinydd. Fodd bynnag, wrth weithio gyda'r gronfa ddata hon, mae angen i chi ddefnyddio ymholiadau tudalenedig.
Er mwyn i'r broblem hon ddod i'r amlwg, mae'n rhaid bod sefyllfa lle mae'r DBMS yn troi at weithrediad Sganio Tabl Llawn aneffeithlon ar bob ymholiad tudalenedig (er y gall gweithrediadau mewnosod a dileu ddigwydd, ac nid oes angen data hen ffasiwn arnom!).
Beth yw βsgan bwrdd llawnβ (neu βsgan bwrdd dilyniannolβ, Sgan Dilyniannol)? Mae hwn yn weithrediad lle mae'r DBMS yn darllen pob rhes o'r tabl yn ddilyniannol, hynny yw, y data sydd ynddo, ac yn eu gwirio i weld a ydynt yn cydymffurfio ag amod penodol. Gwyddys mai'r math hwn o sgan bwrdd yw'r arafaf. Y ffaith yw pan fydd yn cael ei weithredu, mae llawer o weithrediadau mewnbwn / allbwn yn cael eu perfformio sy'n cynnwys is-system disg y gweinydd. Gwaethygir y sefyllfa gan yr hwyrni sy'n gysylltiedig Γ’ gweithio gyda data sydd wedi'i storio ar ddisgiau, a'r ffaith bod trosglwyddo data o ddisg i'r cof yn weithrediad sy'n defnyddio llawer o adnoddau.
Er enghraifft, mae gennych gofnodion o 100000000 o ddefnyddwyr ac rydych chi'n rhedeg ymholiad gyda'r lluniad OFFSET 50000000. Mae hyn yn golygu y bydd yn rhaid i'r DBMS lwytho'r holl gofnodion hyn (ac nid oes eu hangen arnom hyd yn oed!), eu rhoi yn y cof, ac ar Γ΄l hynny, dyweder, adroddwyd 20 canlyniad yn LIMIT.
Gadewch i ni ddweud y gallai edrych fel hyn: "dewiswch resi o 50000 i 50020 o 100000". Hynny yw, yn gyntaf bydd angen i'r system lwytho 50000 o resi i gwblhau'r ymholiad. Ydych chi'n gweld faint o waith diangen y bydd yn rhaid iddi ei wneud?
Os nad ydych chi'n fy nghredu, edrychwch ar yr enghraifft a greais gan ddefnyddio'r nodweddion .
Enghraifft yn db-fiddle.com
Yno, ar y chwith, yn y cae Schema SQL, mae cod sy'n mewnosod 100000 o resi yn y gronfa ddata, ac ar y dde, yn y maes Query SQL, dangosir dau ymholiad. Mae'r un cyntaf, araf, yn edrych fel hyn:
SELECT *
FROM `docs`
LIMIT 10 OFFSET 85000;
Ac mae'r ail, sy'n ateb effeithiol i'r un broblem, fel hyn:
SELECT *
FROM `docs`
WHERE id > 85000
LIMIT 10;
Er mwyn cyflawni'r ceisiadau hyn, cliciwch ar y botwm Run ar frig y dudalen. Ar Γ΄l gwneud hyn, rydym yn cymharu gwybodaeth am yr amser cyflawni ymholiad. Mae'n ymddangos bod gweithredu ymholiad aneffeithiol yn cymryd o leiaf 30 gwaith yn hirach na gweithredu'r ail un (mae'r tro hwn yn amrywio o redeg i redeg; er enghraifft, efallai y bydd y system yn adrodd bod yr ymholiad cyntaf wedi cymryd 37 ms i'w gwblhau, ond bod gweithrediad y ail - 1 ms).
Ac os oes mwy o ddata, yna bydd popeth yn edrych hyd yn oed yn waeth (i gael eich argyhoeddi o hyn, edrychwch ar fy gyda 10 miliwn o resi).
Dylai'r hyn yr ydym newydd ei drafod roi rhywfaint o fewnwelediad i chi o sut mae ymholiadau cronfa ddata yn cael eu prosesu mewn gwirionedd.
Sylwch, po uchaf yw'r gwerth OFFSET β po hiraf y bydd y cais yn ei gymryd i'w gwblhau.
Beth ddylwn i ei ddefnyddio yn lle'r cyfuniad o OFFSET a LIMIT?
Yn lle cyfuniad OFFSET ΠΈ LIMIT Mae'n werth defnyddio strwythur a adeiladwyd yn unol Γ’'r cynllun canlynol:
SELECT * FROM table_name WHERE id > 10 LIMIT 20
Mae hwn yn weithred ymholiad gyda thudaleniad yn seiliedig ar y cyrchwr.
Yn lle storio rhai cyfredol yn lleol OFFSET ΠΈ LIMIT a'u trosglwyddo gyda phob cais, mae angen i chi storio'r allwedd gynradd ddiwethaf a dderbyniwyd (fel arfer dyma ID) A LIMIT, o ganlyniad, ceir ymholiadau tebyg i'r uchod.
Pam? Y pwynt yw, trwy nodi'n benodol dynodwr y rhes olaf a ddarllenwyd, eich bod yn dweud wrth eich DBMS lle mae angen iddo ddechrau chwilio am y data angenrheidiol. Ar ben hynny, bydd y chwiliad, diolch i'r defnydd o'r allwedd, yn cael ei wneud yn effeithlon; ni fydd yn rhaid i linellau y tu allan i'r ystod benodol dynnu sylw'r system.
Gadewch i ni edrych ar y gymhariaeth perfformiad ganlynol o wahanol ymholiadau. Dyma ymholiad aneffeithiol.
Cais araf
A dyma fersiwn wedi'i optimeiddio o'r cais hwn.
Cais cyflym
Mae'r ddau ymholiad yn dychwelyd yn union yr un faint o ddata. Ond mae'r un cyntaf yn cymryd 12,80 eiliad i'w gwblhau, a'r ail yn cymryd 0,01 eiliad. Ydych chi'n teimlo'r gwahaniaeth?
Problemau posib
Er mwyn i'r dull ymholi arfaethedig weithio'n effeithiol, rhaid i'r tabl fod Γ’ cholofn (neu golofnau) sy'n cynnwys mynegeion unigryw, dilyniannol, megis dynodwr cyfanrif. Mewn rhai achosion penodol, gall hyn bennu llwyddiant defnyddio ymholiadau o'r fath i gynyddu cyflymder gweithio gyda'r gronfa ddata.
Yn naturiol, wrth adeiladu ymholiadau, mae angen i chi ystyried pensaernΓ―aeth benodol y tablau a dewis y mecanweithiau hynny a fydd yn gweithio orau ar y tablau presennol. Er enghraifft, os oes angen i chi weithio mewn ymholiadau gyda llawer iawn o ddata cysylltiedig, efallai y bydd yn ddiddorol i chi erthygl.
Os ydym yn wynebu'r broblem o golli allwedd gynradd, er enghraifft, os oes gennym fwrdd gyda pherthynas lawer-i-lawer, yna'r dull traddodiadol o ddefnyddio OFFSET ΠΈ LIMIT, yn sicr o fod yn addas i ni. Ond gall ei ddefnyddio arwain at ymholiadau a allai fod yn araf. Mewn achosion o'r fath, byddwn yn argymell defnyddio allwedd gynradd sy'n cynyddu'n awtomatig, hyd yn oed os mai dim ond i drin ymholiadau tudalenedig sydd ei hangen.
Os oes gennych ddiddordeb yn y pwnc hwn - , ΠΈ - nifer o ddeunyddiau defnyddiol.
Canlyniadau
Y prif gasgliad y gallwn ddod iddo yw, ni waeth beth yw maint y cronfeydd data yr ydym yn sΓ΄n amdanynt, mae angen dadansoddi cyflymder cyflawni ymholiad bob amser. Y dyddiau hyn, mae scalability datrysiadau yn hynod bwysig, ac os yw popeth wedi'i ddylunio'n gywir o'r cychwyn cyntaf o weithio ar system benodol, gall hyn, yn y dyfodol, arbed y datblygwr rhag llawer o broblemau.
Sut ydych chi'n dadansoddi ac yn optimeiddio ymholiadau cronfa ddata?
Ffynhonnell: hab.com