Yek ji senaryoyên tîpîk ên di hemî serîlêdanên ku em pê re nas dikin, lêgerîna daneyan li gorî hin pîvanan û nîşandana wê bi rengek hêsan-xwendin e. Di heman demê de dibe ku vebijarkên din jî ji bo veqetandin, komkirin, û rûpelkirinê hebin. Erk, di teorîyê de, piçûk e, lê dema ku wê çareser dikin, gelek pêşdebiran çend xeletiyan dikin, ku paşê dibe sedema zirara hilberînê. Ka em hewl bidin ku ji bo çareserkirina vê pirsgirêkê vebijarkên cûrbecûr binirxînin û ji bo hilbijartina pêkanîna herî bi bandor pêşniyaran formule bikin.
Vebijarka rûpelkirinê #1
Vebijarka herî hêsan a ku di hişê xwe de tê pêşandana rûpelê-rûpelê ya encamên lêgerînê di forma xweya herî klasîk de ye.
Ka em bibêjin serîlêdana we databasek pêwendiyê bikar tîne. Di vê rewşê de, ji bo ku agahdariya di vê formê de nîşan bide, hûn ê hewce ne ku du pirsên SQL bimeşînin:
- Ji bo rûpela heyî rêzan bistînin.
- Hejmara tevahî rêzikên ku bi pîvanên lêgerînê re têkildar in hesab bikin - ev ji bo nîşankirina rûpelan hewce ye.
Ka em li pirsa yekem binihêrin ku databasek testa MS SQL wekî mînak bikar tîne ji bo 2016 server. Ji bo vê mebestê em ê tabloya Sales.SalesOrderHeader bikar bînin:
SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
Lêpirsîna jorîn dê 50 fermanên yekem ji navnîşê vegerîne, li gorî tarîxa zêdebûnê ya daketinê, bi gotinek din, 50 fermanên herî dawîn.
Ew li ser bingeha ceribandinê zû dimeşe, lê em li plana darvekirinê û statîstîkên I/O binêrin:
Table 'SalesOrderHeader'. Scan count 1, logical reads 698, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.Hûn dikarin statîstîkên I/O ji bo her pirsê bi xebitandina fermana SET STATISTICS IO ON di dema xebitandina pirsê de bistînin.
Wekî ku hûn ji plansaziya darvekirinê dibînin, vebijarka herî zêde-çavkaniyê ev e ku meriv hemî rêzên tabloya çavkaniyê li gorî dîroka lê zêdekirî birêkûpêk bike. Û pirsgirêk ev e ku çend rêzikên di tabloyê de xuya bibin, dê dabeşkirin "zehmet" be. Di pratîkê de, pêdivî ye ku ji rewşên weha dûr bikevin, ji ber vê yekê em indeksek li dîroka lêzêdekirinê zêde bikin û bibînin ka xerckirina çavkaniyê guheriye:
Table 'SalesOrderHeader'. Scan count 1, logical reads 165, physical reads 0, read-ahead reads 5, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Diyar e ku ew pir çêtir bûye. Lê hemû pirsgirêk çareser dibin? Ka em lêpirsînê biguhezînin da ku li fermanên ku lêçûna giştî ya tiştan ji 100 $ derbas dibe bigerin:
SELECT * FROM Sales.SalesOrderHeader
WHERE SubTotal > 100
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
Table 'SalesOrderHeader'. Scan count 1, logical reads 1081, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.Rewşek me ya balkêş heye: pilana pirsê ji ya berê ne pir xirabtir e, lê hejmara rastîn a xwendinên mentiqî hema hema du caran ji şanoya tabloya tam mezintir e. Rêyek heye - heke em ji pêvekek berê ya heyî îndekek pêkve çêkin û bihaya giştî ya tiştan wekî qada duyemîn zêde bikin, em ê dîsa 165 xwendinên mantiqî bistînin:
CREATE INDEX IX_SalesOrderHeader_OrderDate_SubTotal on Sales.SalesOrderHeader(OrderDate, SubTotal);
Ev rêze mînakan dikare ji bo demek dirêj berdewam bike, lê du ramanên sereke yên ku ez dixwazim li vir diyar bikim ev in:
- Zêdekirina her pîvanek nû an rêziknameyek li ser pirsek lêgerînê dikare bandorek girîng li ser leza lêgerîna lêgerînê bike.
- Lê ger hewce bike ku em tenê beşek daneyan jê bikin, û ne hemî encamên ku bi peyvên lêgerînê re hevber dikin, gelek awayên xweşbînkirina pirsek weha hene.
Naha em werin ser pirsa duyemîn a ku di destpêkê de hatî behs kirin - ya ku hejmara tomarên ku pîvana lêgerînê têr dike dihejmêre. Werin em heman nimûneyê bigirin - lêgerîna li fermanên ku ji 100 $ zêdetir in:
SELECT COUNT(1) FROM Sales.SalesOrderHeader
WHERE SubTotal > 100
Li gorî indexa pêkhatî ya ku li jor hatî destnîşan kirin, em digirin:
Table 'SalesOrderHeader'. Scan count 1, logical reads 698, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.Rastiya ku pirs di tevahiya pêvekê de derbas dibe ne ecêb e, ji ber ku qada SubTotal ne di pozîsyona yekem de ye, ji ber vê yekê pirs nikare wê bikar bîne. Pirsgirêk bi lê zêdekirina nîşanek din li ser qada SubTotal çareser dibe, û di encamê de ew tenê 48 xwendina mentiqî dide.
Hûn dikarin çend mînakên din ên daxwazên ji bo jimartina mîqdaran bidin, lê esl her wekî xwe dimîne: wergirtina perçeyek daneyê û jimartina mîqdara giştî du daxwazên bingehîn ên cûda ne, û her yek ji bo xweşbîniyê tedbîrên xwe hewce dike. Bi gelemperî, hûn ê nikaribin berhevokek navnîşan bibînin ku ji bo her du pirsan wekhev baş dixebite.
Li gorî vê yekê, yek ji wan hewcedariyên girîng ên ku divê di dema pêşkeftina çareseriyek lêgerînê ya weha de were ronî kirin ev e ku gelo ji bo karsaziyek bi rastî girîng e ku jimareya giştî ya tiştên ku hatine dîtin bibînin. Gelek caran diqewime ku na. Û navîgasyon ji hêla hejmarên rûpelê yên taybetî ve, bi dîtina min, çareseriyek bi çarçoveyek pir teng e, ji ber ku piraniya senaryoyên rûpelkirinê wekî "herin rûpela din" xuya dikin.
Vebijarka rûpelkirinê #2
Ka em bihesibînin ku bikarhêner guh nadin zanîna hejmara giştî ya tiştên hatine dîtin. Ka em hewl bidin ku rûpela lêgerînê hêsan bikin:
Di rastiyê de, tenê tiştê ku guherî ev e ku rêyek tune ku meriv li hejmarên rûpelên taybetî vegere, û naha ev tablo ne hewce ye ku zanibe çend kes dikare hebe da ku wê nîşan bide. Lê pirs derdikeve holê - tablo çawa dizane gelo ji bo rûpela din dane hene (ji bo ku zencîreya "Next" rast nîşan bide)?
Bersiv pir hêsan e: hûn dikarin ji databasê tomarek bêtir ji ya ku ji bo pêşandanê hewce ye bixwînin, û hebûna vê tomara "zêde" dê nîşan bide ka beşek din heye an na. Bi vî rengî, hûn tenê hewce ne ku yek daxwazek bimeşînin da ku yek rûpelek daneyê bistînin, ku bi girîngî performansê çêtir dike û piştgirîkirina fonksiyonek wusa hêsantir dike. Di pratîka min de, rewşek hebû ku redkirina jimartina hejmara giştî ya tomaran 4-5 carî gihandina encaman bilez kir.
Ji bo vê nêzîkbûnê gelek vebijarkên navbeynkariya bikarhêner hene: Fermanên "paş" û "pêş", wekî mînaka li jor, bişkokek "zêdetir barkirin", ku bi tenê beşek nû li encamên xuyakirî zêde dike, "pêça bêdawî", ku dixebite. li ser prensîba "zêdetir barkirin" ", lê îşaretek ji bo bidestxistina beşa din ev e ku bikarhêner hemî encamên ku têne xuyang kirin heya dawiyê bigerin. Çareseriya dîtbarî çi dibe bila bibe, prensîba nimûneya daneyê heman dimîne.
Nuances yên pêkanîna paging
Hemî mînakên pirsnameyê yên ku li jor hatine dayîn nêzîkatiya "offset + count" bikar tînin, dema ku pirs bixwe diyar dike rêzên encam bi kîjan rêzê û çend rêz divê werin vegerandin. Pêşîn, ka em binihêrin ka meriv çawa di vê rewşê de derbasbûna parametreyê çêtirîn organîze dike. Di pratîkê de, ez li çend rêbazan rast hatim:
- Jimareya rêzeya rûpela daxwazkirî (pageIndex), mezinahiya rûpelê (Pîbareya rûpelê).
- Hejmara rêzenivîsa yekem tomar ku tê vegerandin (startIndex), herî zêde hejmara tomarên di encamê de (hejmar).
- Hejmara rêza tomara yekem a ku were vegerandin (startIndex), jimareya rêza tomara paşîn a ku were vegerandin (endIndex).
Di nihêrîna pêşîn de dibe ku xuya bibe ku ev ew çend bingehîn e ku cûdahî tune. Lê ev ne wusa ye - vebijarka herî hêsan û gerdûnî ya duyemîn e (startIndex, hejmartin). Gelek sedemên vê yekê hene:
- Ji bo nêzîkatiya rastkirina têketina +1 ya ku li jor hatî dayîn, vebijarka yekem a bi pageIndex û pageSize re zehf nerehet e. Mînakî, em dixwazin her rûpelê 50 postan nîşan bidin. Li gorî algorîtmaya jorîn, hûn hewce ne ku yek tomarek ji ya pêwîst bixwînin. Ger ev "+1" li ser serverê neyê bicîh kirin, derdikeve holê ku ji bo rûpela yekem divê em tomarên ji 1 heta 51 bixwazin, ji bo ya duyemîn - ji 51 heta 101, hwd. Ger hûn mezinahiya rûpelê 51 diyar bikin û rûpelIndex zêde bikin, wê hingê rûpela duyemîn dê ji 52 vegere 102, hwd. Li gorî vê yekê, di vebijarka yekem de, yekane awayê ku meriv bi rêkûpêk bicîhkirina bişkokek ku biçe rûpela din ev e ku server rêza "zêde" rast bike, ku dê nuwazeyek pir nepenî be.
- Vebijarka sêyem qet ne watedar e, ji ber ku ji bo pêkanîna pirsan di pir databasan de hûn ê hîn jî hewce ne ku jimartinê derbas bikin ne ji navnîşana tomara paşîn. Kêmkirina startIndex ji endIndex dibe ku operasyonek hejmarî ya hêsan be, lê ew li vir zêde ye.
Naha divê em dezawantajên pêkanîna pajingê bi navgîniya "offset + mîqdar" vebêjin:
- Vegerandina her rûpelê paşîn dê ji ya berê bihatir û hêdîtir be, ji ber ku databas hîn jî hewce dike ku hemî tomar "ji destpêkê ve" li gorî pîvanên lêgerîn û rêzkirinê derbas bike, û dûv re li ser perçeya xwestî raweste.
- Ne hemî DBMS dikarin vê nêzîkbûnê piştgirî bikin.
Alternatîf hene, lê ew jî bêkêmasî ne. Yekem ji van nêzîkatiyan jê re "rûpela mifteyê" an "rêbaza lêgerînê" tê gotin û wiha ye: piştî wergirtina beşekê, hûn dikarin nirxên zeviyê di qeyda paşîn a li ser rûpelê de bi bîr bînin, û dûv re wan bikar bînin da ku bistînin. beşa din. Mînakî, me pirsa jêrîn kir:
SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
Û di qeyda paşîn de me nirxa tarîxa fermanê '2014-06-29' girt. Dûv re ji bo ku hûn rûpela din bistînin hûn dikarin vê yekê biceribînin:
SELECT * FROM Sales.SalesOrderHeader
WHERE OrderDate < '2014-06-29'
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
Pirsgirêk ev e ku OrderDate qadek ne-yekane ye û şertê ku li jor hatî destnîşan kirin dibe ku gelek rêzikên pêwîst winda bike. Ji bo ku hûn nezelaliyê li vê pirsê zêde bikin, hûn hewce ne ku zeviyek yekta li şertê zêde bikin (bihesibînin ku 75074 nirxa paşîn a mifteya bingehîn ji beşa yekem e):
SELECT * FROM Sales.SalesOrderHeader
WHERE (OrderDate = '2014-06-29' AND SalesOrderID < 75074)
OR (OrderDate < '2014-06-29')
ORDER BY OrderDate DESC, SalesOrderID DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
Ev vebijark dê rast bixebite, lê bi gelemperî xweşbînkirina wê dijwar be ji ber ku şert operatorek OR-ê dihewîne. Ger nirxa mifteya bingehîn her ku OrderDate zêde dibe zêde dibe, wê hingê rewş dikare bi tenê fîlterek ji hêla SalesOrderID ve hiştin were hêsan kirin. Lê ger têkiliyek hişk di navbera nirxên mifteya bingehîn û qada ku encam jê tê veqetandin tune be, ev OR di piraniya DBMS-an de nayê dûr kirin. Ji îstîsnayek ku ez jê haydar im PostgreSQL e, ku bi tevahî berhevoka piralî piştgirî dike, û şerta jorîn dikare wekî "WHERE (Dîroka Siparîşê, SalesOrderID) < ('2014-06-29', 75074)" were nivîsandin. Bi van her du qadan re mifteyek pêkhatî tê dayîn, pirsek bi vî rengî divê pir hêsan be.
Nêzîkatiyek alternatîfek duyemîn dikare were dîtin, mînakî, di an - gava ku daxwazek, ji bilî daneyê, nasnameyek taybetî vedigerîne ku pê re hûn dikarin beşa din a daneyê bistînin. Ger ev nasnav xwedan jiyanek bêsînor be (wek Comsos DB), wê hingê ev rêgezek girîng e ku meriv rûpela bi veguheztina rêzdar a di navbera rûpelan de bicîh bike (vebijarka #2 ku li jor hatî destnîşan kirin). Dezawantajên wê yên gengaz: ew di hemî DBMS-an de nayê piştgirî kirin; Nasnameya paşîn a ku di encamê de dibe ku heyamek tixûbdar hebe, ku bi gelemperî ji bo pêkanîna danûstendina bikarhêner ne guncaw e (wek API-ya gerokê ya ElasticSearch).
Parzûnkirina kompleks
Werin em peywirê bêtir tevlihev bikin. Bifikirin ku pêdivî ye ku meriv bi navê lêgerîna rûkal, ku ji her kesê ji firotgehên serhêl re pir nas e, bicîh bîne. Mînakên jorîn li ser bingeha tabloya fermanan di vê rewşê de ne pir diyarker in, ji ber vê yekê em werin ser tabloya Hilberê ji databasa AdventureWorks:
Fikra li pişt lêgerîna rûkal çi ye? Rastî ev e ku ji bo her elementek fîlterê hejmara tomarên ku vê pîvanê bicîh tînin tê destnîşan kirin fîlterên ku di hemî kategoriyên din de hatine hilbijartin têne hesibandin.
Mînakî, heke em di vê nimûneyê de kategoriya Bisiklêtan û rengê Reş hilbijêrin, dê tablo tenê bisiklêtên reş nîşan bide, lê:
- Ji bo her pîvanek di koma Kategoriyan de, dê hejmara hilberên ji wê kategoriyê bi reş were xuyang kirin.
- Ji bo her pîvanek koma "Reng" dê hejmara duçerxeyên vî rengî were xuyang kirin.
Li vir mînakek encamek ji bo mercên weha ye:
Ger hûn kategoriya "Cil û berg" jî kontrol bikin, tablo dê cilên reş ên ku di stokê de ne jî nîşan bide. Hejmara hilberên reş ên di beşa "Reng" de jî dê li gorî şert û mercên nû ji nû ve were hesibandin, tenê di beşa "Kategorî" de dê tiştek neyê guhertin... Ez hêvî dikim ku ev mînak bes bin ji bo têgihîştina algorîtmaya lêgerîna rûkal a asayî.
Naha em bifikirin ka ev çawa dikare li ser bingehek têkilî were bicîh kirin. Her komek pîvanan, wekî Kategorî û Reng, dê pirsek cûda hewce bike:
SELECT pc.ProductCategoryID, pc.Name, COUNT(1) FROM Production.Product p
INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
INNER JOIN Production.ProductCategory pc ON ps.ProductCategoryID = pc.ProductCategoryID
WHERE p.Color = 'Black'
GROUP BY pc.ProductCategoryID, pc.Name
ORDER BY COUNT(1) DESC
SELECT Color, COUNT(1) FROM Production.Product p
INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
WHERE ps.ProductCategoryID = 1 --Bikes
GROUP BY Color
ORDER BY COUNT(1) DESC
Çi xeletiya vê çareseriyê heye? Ew pir hêsan e - ew baş pîvan nake. Her beşa parzûnê ji bo hesabkirina mîqdaran pirsek veqetandî hewce dike, û ev pirs ne ya herî hêsan in. Di firotgehên serhêl de, hin kategorî dibe ku bi dehan beşên fîlterê hebin, ku dikare bibe pirsgirêkek performansê ya ciddî.
Bi gelemperî piştî van gotinan hin çareserî ji min re têne pêşkêş kirin, ev jî:
- Hemî hejmartinên hêjmarê di yek pirsê de berhev bikin. Ji hêla teknîkî ve ev bi karanîna keyworda UNION mimkun e, lê ew ê zêde alîkariya performansê neke - databas dê hîna jî neçar be ku her perçeyan ji sifirê pêk bîne.
- mîqdarên cache. Hema hema her gava ku ez pirsgirêkek vedibêjim ev ji min re tê pêşniyar kirin. Hişyar ev e ku ev bi gelemperî ne gengaz e. Em bêjin 10 "rûyên me" hene, ku her yek ji wan 5 nirx hene. Li gorî tiştê ku di heman firotgehên serhêl de têne dîtin, ev rewşek pir "hêz" e. Hilbijartina yek hêmanek rûkê bandorê li mîqdarên di 9 yên din de dike, bi gotinek din, ji bo her berhevoka pîvanan mîqdar dikarin cûda bin. Di mînaka me de bi giştî 50 pîvan hene ku bikarhêner dikare hilbijêre, ji ber vê yekê dê 250 berhevokên muhtemel hebin. Ji bo tijîkirina komek daneyan têra bîranîn an dem tune. Li vir hûn dikarin îtîraz bikin û bibêjin ku ne hemî berhevok rast in û bikarhêner kêm kêm ji 5-10 pîvanan hilbijêrin. Erê, mimkun e ku meriv barkirina tembel bike û hêjmarek tenê ya ku heya niha hatî hilbijartin were cache kirin, lê her ku bêtir hilbijartî hebin, dê cacheyek weha kêmtir bikêr be û dê pirsgirêkên dema bersivdayînê ewqasî berbiçavtir bibin (nemaze heke berhevoka daneyan bi rêkûpêk diguhezîne).
Xweşbextane, pirsgirêkek wusa ji mêj ve xwedan çareseriyên pir bi bandor e ku bi pêşbînîkirî li ser jimarên mezin daneyan dixebitin. Ji bo yek ji van vebijarkan, maqûl e ku ji nû ve hesabkirina rûkan û wergirtina rûpela encamê li du bangên paralel ji serverê re were dabeş kirin û navbeynkariya bikarhêner bi vî rengî organîze bike ku barkirina daneyan ji hêla rûkan ve "destwerdanê neke" li pêşandana encamên lêgerînê.
- Ji nû ve hesabkirina bêkêmasî ya "rûpelan" bi qasî ku gengaz dibe bang bikin. Mînakî, her gava ku pîvanên lêgerînê diguhezin, her tiştî ji nû ve nehesibînin, lê di şûna wê de jimareya giştî ya encamên ku bi şert û mercên heyî re têkildar in bibînin û ji bikarhênerê bixwazin ku wan nîşan bide - "1425 tomar hatin dîtin, nîşan bidin?" Bikarhêner dikare guhertina peyvên lêgerînê bidomîne an jî bişkoja "nîşan bide" bikirtîne. Tenê di rewşa duyemîn de dê hemî daxwazên ji bo bidestxistina encaman û ji nû ve hesibandina mîqdaran li ser hemî "alîyan" bêne bicîh kirin. Di vê rewşê de, wekî ku hûn dikarin bi hêsanî bibînin, hûn ê neçar bibin ku bi daxwazek ji bo bidestxistina hejmara giştî ya encaman û xweşbîniya wê re mijûl bibin. Ev rêbaz dikare di gelek firotgehên piçûk ên serhêl de were dîtin. Eşkere ye, ev ji bo vê pirsgirêkê ne dermanek e, lê di rewşên hêsan de ew dikare lihevkirinek baş be.
- Motorên lêgerînê bikar bînin ku encaman bibînin û rûyên hejmartin, wek Solr, ElasticSearch, Sphinx û yên din. Hemî ew ji bo avakirina "rûpelan" hatine sêwirandin û ji ber nîşana berevajîkirî vê yekê pir bi bandor dikin. Merivên lêgerînê çawa dixebitin, çima di rewşên weha de ew ji databasên gelemperî bi bandortir in, çi pratîk û xeletî hene - ev mijarek ji bo gotarek cihê ye. Li vir ez dixwazim bala we bikişînim ser vê yekê ku motora lêgerînê nikare bibe şûna hilanîna daneya sereke; ew wekî pêvek tê bikar anîn: her guhertinên di databasa sereke ya ku ji bo lêgerînê re têkildar in di navnîşa lêgerînê de têne hevdem kirin; Motora lêgerînê bi gelemperî tenê bi motora lêgerînê re têkilî dike û nagihîje databasa sereke. Li vir yek ji xalên herî girîng ev e ku meriv çawa vê hevdemkirinê bi pêbawer organîze dike. Ew hemî bi daxwazên "dema reaksiyonê" ve girêdayî ye. Ger dema di navbera guheztina databasa sereke û "nîşandana" wê ya di lêgerînê de ne krîtîk be, hûn dikarin karûbarek biafirînin ku her çend hûrdeman li tomarên nû yên guhertî digere û wan navnîş dike. Heke hûn dema bersivê ya herî kurt dixwazin, hûn dikarin tiştek wekî bicîh bikin ji bo şandina nûvekirina karûbarê lêgerînê.
vebiguherin
- Bicîhkirina rûpela server-aliyê tevliheviyek girîng e û tenê ji bo berhevokên daneya zû-mezin an bi tenê mezin watedar e. Ji bo nirxandina "mezin" an "zû-zêde" reçeteyek bêkêmasî ya rast tune, lê ez ê vê nêzîkatiyê bişopînim:
- Ger wergirtina berhevokek bêkêmasî ya daneyan, girtina dema serverê û veguheztina torê li ber çavan bigire, li gorî hewcedariyên performansê bi normalî tevdigere, çu xalek ji pêkanîna pakirinê li aliyê serverê tune.
- Dibe ku rewşek hebe ku di pêşerojek nêzîk de pirsgirêkên performansê neyên hêvî kirin, ji ber ku daneya hindik heye, lê berhevkirina daneyan bi domdarî mezin dibe. Ger di pêşerojê de hin komek daneyan êdî xala berê têr neke, çêtir e ku hûn tavilê dest bi rûpelkirinê bikin.
- Ger ji hêla karsaziyê ve hewceyek hişk tune ku jimara giştî ya encaman nîşan bide an hejmarên rûpelan nîşan bide, û pergala we motora lêgerînê tune, çêtir e ku hûn van xalan bicîh nekin û vebijarka #2-ê bifikirin.
- Ger ji bo lêgerîna rûbirû pêdivîyek zelal hebe, bêyî ku hûn performansê bikin du vebijarkên we hene:
- Her gava ku pîvanên lêgerînê diguhezin hemî jimareyan ji nû ve nehesibînin.
- Motorên lêgerînê yên wekî Solr, ElasticSearch, Sphinx û yên din bikar bînin. Lê divê were fêm kirin ku ew nikare bibe şûna databasa sereke, û divê ji bo çareserkirina pirsgirêkên lêgerînê wekî pêvekek hilanîna sereke were bikar anîn.
- Di heman demê de, di doza lêgerîna rûkal de, maqûl e ku vegerandina rûpela encamên lêgerînê û hejmartin li du daxwazên paralel were dabeş kirin. Dibe ku hejmartina hêjmaran ji bidestxistina encaman dirêjtir bigire, dema ku encam ji bikarhêner re girîngtir in.
- Heke hûn ji bo lêgerînê databasek SQL bikar tînin, her guheztina kodê ya ku bi vê beşê ve girêdayî ye divê ji bo performansa li ser mîqdara guncan a daneyê baş were ceribandin (ji qebareya di databasa zindî de derbas dibe). Di heman demê de tê pêşniyar kirin ku çavdêriya dema pêkanîna pirsê li ser hemî nimûneyên databasê, û nemaze li ser ya "zindî" bikar bînin. Her çend di qonaxa pêşkeftinê de bi plansaziyên lêpirsînê re her tişt baş bû, her ku hêjmara daneyê mezin dibe, dibe ku rewş bi baldarî biguheze.
Source: www.habr.com