Mga resulta sa pagpangita ug mga isyu sa performance

Usa sa kasagaran nga mga senaryo sa tanan nga mga aplikasyon nga nahibal-an namon mao ang pagpangita sa mga datos sumala sa piho nga pamatasan ug gipakita kini sa usa ka dali basahon nga porma. Mahimo usab nga adunay dugang nga mga kapilian alang sa paghan-ay, paggrupo, ug paging. Ang tahas, sa teorya, gamay ra, apan kung gisulbad kini, daghang mga developer ang naghimo sa daghang mga sayup, nga sa ulahi hinungdan sa pag-antus sa produktibo. Atong sulayan ang paghunahuna sa lainlaing mga kapilian sa pagsulbad niini nga problema ug paghimo og mga rekomendasyon alang sa pagpili sa labing epektibo nga pagpatuman.

Opsyon sa paging #1

Ang pinakasimple nga kapilian nga naa sa hunahuna mao ang usa ka panid-sa-panid nga pagpakita sa mga resulta sa pagpangita sa labing klasiko nga porma niini.

Ingnon ta nga ang imong aplikasyon naggamit ug relational database. Sa kini nga kaso, aron ipakita ang kasayuran sa kini nga porma, kinahanglan nimo nga modagan ang duha nga mga pangutana sa SQL:

• Pagkuha og mga laray alang sa kasamtangan nga panid.
• Kalkulahin ang kinatibuk-ang gidaghanon sa mga linya nga katumbas sa mga criteria sa pagpangita - kini gikinahanglan aron sa pagpakita sa mga panid.

Atong tan-awon ang una nga pangutana gamit ang usa ka pagsulay nga database sa MS SQL ingon usa ka pananglitan AdventureWorks alang sa 2016 server. Alang niini nga katuyoan atong gamiton ang Sales.SalesOrderHeader nga lamesa:

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

Ang pangutana sa ibabaw ibalik ang una nga 50 ka mga order gikan sa lista, nga gisunud sa pagkanaog nga petsa sa pagdugang, sa ato pa, ang 50 nga labing bag-o nga mga order.

Kini dali nga nagdagan sa base sa pagsulay, apan atong tan-awon ang plano sa pagpatuman ug mga istatistika sa I/O:

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.

Makuha nimo ang I/O statistics para sa matag pangutana pinaagi sa pagpadagan sa SET STATISTICS IO ON command sa query runtime.

Sama sa imong makita gikan sa plano sa pagpatuman, ang labing daghang kapilian nga kapanguhaan mao ang paghan-ay sa tanan nga mga laray sa gigikanan nga lamesa sa petsa nga gidugang. Ug ang problema mao nga ang daghang mga laray nga makita sa lamesa, ang "mas lisud" ang paghan-ay. Sa praktis, ang ingon nga mga sitwasyon kinahanglan nga likayan, busa atong idugang ang usa ka indeks sa petsa sa pagdugang ug tan-awon kon ang konsumo sa kapanguhaan nausab:

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.

Dayag nga kini nahimong mas maayo. Apan nasulbad ba ang tanang problema? Usbon nato ang pangutana aron pangitaon ang mga order diin ang kinatibuk-ang kantidad sa mga butang milapas sa $100:

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.

Kami adunay usa ka kataw-anan nga kahimtang: ang plano sa pangutana dili labi ka daotan kaysa sa una, apan ang tinuud nga gidaghanon sa mga lohikal nga pagbasa hapit doble ang kadako kaysa sa usa ka tibuuk nga pag-scan sa lamesa. Adunay usa ka paagi sa paggawas - kung maghimo kita usa ka composite index gikan sa naa na nga indeks ug idugang ang kinatibuk-ang presyo sa mga butang ingon ikaduha nga uma, makakuha na usab kita 165 nga lohikal nga pagbasa:

CREATE INDEX IX_SalesOrderHeader_OrderDate_SubTotal on Sales.SalesOrderHeader(OrderDate, SubTotal);

Kini nga serye sa mga pananglitan mahimong ipadayon sa dugay nga panahon, apan ang duha ka panguna nga mga hunahuna nga gusto nako ipahayag dinhi mao ang:

• Ang pagdugang ug bisan unsang bag-ong sukdanan o paghan-ay sa usa ka pangutana sa pagpangita mahimong adunay dakong epekto sa katulin sa pangutana sa pagpangita.
• Apan kung kinahanglan naton nga ibawas ang bahin lamang sa datos, ug dili tanan nga mga resulta nga motakdo sa mga termino sa pagpangita, adunay daghang mga paagi aron ma-optimize ang ingon nga pangutana.

Karon magpadayon kita sa ikaduhang pangutana nga gihisgutan sa sinugdanan - ang usa nga nag-ihap sa gidaghanon sa mga rekord nga makatagbaw sa sukdanan sa pagpangita. Atong kuhaon ang parehas nga pananglitan - pagpangita alang sa mga order nga labaw sa $100:

SELECT COUNT(1) FROM Sales.SalesOrderHeader
WHERE SubTotal > 100

Tungod sa composite index nga gipakita sa ibabaw, atong makuha:

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.

Ang kamatuoran nga ang pangutana moagi sa tibuok index dili ikatingala, tungod kay ang SubTotal field wala sa unang posisyon, mao nga ang pangutana dili makagamit niini. Ang problema masulbad pinaagi sa pagdugang ug laing index sa SubTotal field, ug isip resulta naghatag lang kini ug 48 ka lohikal nga pagbasa.

Makahatag ka ug pipila ka mga pananglitan sa mga hangyo alang sa pag-ihap sa gidaghanon, apan ang esensya nagpabilin nga pareho: Ang pagdawat sa usa ka piraso sa datos ug pag-ihap sa kinatibuk-ang kantidad mao ang duha ka lain-laing mga hangyo, ug ang matag usa nagkinahanglan sa kaugalingon nga mga lakang alang sa pag-optimize. Sa kinatibuk-an, dili nimo makit-an ang kombinasyon sa mga indeks nga parehas nga molihok alang sa duha nga mga pangutana.

Tungod niini, usa sa importante nga mga kinahanglanon nga kinahanglan nga ipatin-aw sa diha nga ang pagpalambo sa ingon nga usa ka solusyon sa pagpangita mao ang importante ba alang sa usa ka negosyo nga makita ang kinatibuk-ang gidaghanon sa mga butang nga nakit-an. Kanunay mahitabo nga dili. Ug ang pag-navigate pinaagi sa piho nga mga numero sa panid, sa akong opinyon, usa ka solusyon nga adunay usa ka pig-ot nga sakup, tungod kay kadaghanan sa mga senaryo sa paging sama sa "adto sa sunod nga panid."

Opsyon sa paging #2

Ibutang nato nga ang mga tiggamit walay pagtagad sa pagkahibalo sa kinatibuk-ang gidaghanon sa mga butang nga nakit-an. Atong sulayan nga pasimplehon ang panid sa pagpangita:

Sa tinuud, ang bugtong butang nga nabag-o mao nga wala’y paagi sa pag-navigate sa piho nga mga numero sa panid, ug karon kini nga lamesa dili kinahanglan mahibal-an kung pila ang mahimo aron ipakita kini. Apan mitungha ang pangutana - giunsa pagkahibalo sa lamesa kung adunay mga datos alang sa sunod nga panid (aron husto nga ipakita ang link nga "Sunod")?

Ang tubag yano ra kaayo: mahimo nimong basahon gikan sa database ang usa pa nga rekord kaysa gikinahanglan alang sa pagpakita, ug ang presensya niining "dugang" nga rekord magpakita kung adunay sunod nga bahin. Niining paagiha, kinahanglan ka lang magpadagan sa usa ka hangyo aron makakuha usa ka panid sa datos, nga labi nga nagpauswag sa pasundayag ug nagpadali sa pagsuporta sa ingon nga pagpaandar. Sa akong praktis, adunay usa ka kaso kung ang pagdumili sa pag-ihap sa kinatibuk-ang gidaghanon sa mga rekord nagpadali sa paghatud sa mga resulta sa 4-5 ka beses.

Adunay ubay-ubay nga mga opsyon sa user interface alang niini nga pamaagi: "back" ug "forward" nga mga sugo, sama sa panig-ingnan sa ibabaw, usa ka "load more" nga buton, nga nagdugang lamang og usa ka bag-ong bahin sa gipakita nga mga resulta, "walay katapusan nga scroll", nga nagtrabaho. sa prinsipyo sa "load more" ", apan ang signal aron makuha ang sunod nga bahin mao ang pag-scroll sa user sa tanang gipakita nga resulta hangtod sa katapusan. Bisan unsa ang biswal nga solusyon, ang prinsipyo sa data sampling nagpabilin nga pareho.

Mga nuances sa pagpatuman sa paging

Ang tanan nga mga pananglitan sa pangutana nga gihatag sa ibabaw naggamit sa "offset + count" nga pamaagi, kung ang pangutana mismo nagtino kung unsang pagkasunod-sunod ang mga linya sa resulta ug pila ka mga linya ang kinahanglan ibalik. Una, tan-awon naton kung giunsa ang labing maayo nga pag-organisar sa pagpasa sa parameter sa kini nga kaso. Sa praktis, nakit-an nako ang daghang mga pamaagi:

• Ang serial number sa gipangayo nga panid (pageIndex), page size (pageSize).
• Ang serial number sa unang rekord nga ibalik (startIndex), ang kinatas-ang gidaghanon sa mga rekord sa resulta (ihap).
• Ang sequence number sa unang record nga ibalik (startIndex), ang sequence number sa kataposang record nga ibalik (endIndex).

Sa unang tan-aw morag elementarya kaayo kini nga walay kalainan. Apan dili kini mao - ang labing kombenyente ug unibersal nga kapilian mao ang ikaduha (startIndex, ihap). Adunay daghang mga hinungdan niini:

• Alang sa +1 record proofreading approach nga gihatag sa ibabaw, ang unang opsyon sa pageIndex ug pageSize hilabihan ka dili kombenyente. Pananglitan, gusto namon nga ipakita ang 50 nga mga post matag panid. Sumala sa algorithm sa ibabaw, kinahanglan nimo nga basahon ang usa pa nga rekord kaysa kinahanglan. Kung kini nga "+1" wala gipatuman sa server, kini nahimo nga alang sa una nga panid kinahanglan namon nga mangayo mga rekord gikan sa 1 hangtod 51, alang sa ikaduha - gikan sa 51 hangtod 101, ug uban pa. Kung imong itakda ang gidak-on sa panid nga 51 ug dugangan ang pageIndex, unya ang ikaduhang panid mobalik gikan sa 52 ngadto sa 102, ug uban pa. Sumala niini, sa unang kapilian, ang bugtong paagi sa husto nga pagpatuman sa usa ka buton aron makaadto sa sunod nga panid mao ang pag-proofread sa server sa "dugang" nga linya, nga mahimong usa ka tin-aw kaayo nga nuance.
• Ang ikatulo nga kapilian dili gyud makatarunganon, tungod kay aron makadagan ang mga pangutana sa kadaghanan sa mga database kinahanglan nimo nga ipasa ang ihap kaysa sa indeks sa katapusan nga rekord. Ang pag-ubos sa startIndex gikan sa endIndex mahimo nga usa ka yano nga operasyon sa aritmetika, apan kini dili kinahanglan dinhi.

Karon kinahanglan natong ihulagway ang mga disbentaha sa pagpatuman sa paging pinaagi sa "offset + quantity":

• Ang pagbawi sa matag sunod nga panid mahimong mas mahal ug mas hinay kaysa sa nauna, tungod kay ang database kinahanglan pa nga moagi sa tanan nga mga rekord "gikan sa sinugdanan" sumala sa pagpangita ug paghan-ay nga pamatasan, ug dayon mohunong sa gusto nga tipik.
• Dili tanan nga mga DBMS makasuporta niini nga pamaagi.

Adunay mga alternatibo, apan sila usab dili hingpit. Ang una niini nga mga paagi gitawag nga "keyset paging" o "paagi sa pagpangita" ug mao kini ang mosunod: human makadawat og usa ka bahin, mahinumduman nimo ang mga bili sa field sa katapusang rekord sa panid, ug dayon gamiton kini aron makuha. sunod nga bahin. Pananglitan, among gipadagan ang mosunod nga pangutana:

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

Ug sa katapusang rekord nakuha namo ang kantidad sa petsa sa order '2014-06-29'. Unya aron makuha ang sunod nga panid mahimo nimong sulayan nga buhaton kini:

SELECT * FROM Sales.SalesOrderHeader
WHERE OrderDate < '2014-06-29'
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

Ang problema mao nga ang OrderDate usa ka dili-talagsaon nga natad ug ang kondisyon nga gitakda sa ibabaw lagmit nga mawala ang daghang gikinahanglan nga mga laray. Aron madugangan ang katin-awan sa kini nga pangutana, kinahanglan nimong idugang ang usa ka talagsaon nga natad sa kondisyon (hunahunaa nga ang 75074 mao ang katapusan nga kantidad sa panguna nga yawe gikan sa una nga bahin):

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

Kini nga kapilian molihok sa husto, apan sa kinatibuk-an lisud ang pag-optimize tungod kay ang kondisyon adunay usa ka OR operator. Kung ang bili sa nag-unang yawe motaas samtang ang OrderDate motaas, nan ang kondisyon mahimong pasimplehon pinaagi sa pagbilin lamang ug filter sa SalesOrderID. Apan kung wala’y estrikto nga correlation tali sa mga kantidad sa panguna nga yawe ug sa uma diin ang resulta gisunud, kini nga O dili malikayan sa kadaghanan sa mga DBMS. Ang usa ka eksepsiyon nga akong nahibal-an mao ang PostgreSQL, nga hingpit nga nagsuporta sa mga pagtandi sa tuple, ug ang kondisyon sa ibabaw mahimong isulat nga "WHERE (OrderDate, SalesOrderID) <('2014-06-29', 75074)". Gihatag ang usa ka composite nga yawe uban niining duha ka mga natad, ang pangutana nga sama niini kinahanglan nga sayon ​​​​ra.

Ang ikaduha nga alternatibo nga pamaagi makita, pananglitan, sa ElasticSearch scroll API o Cosmos DB — kung ang usa ka hangyo, dugang sa datos, nagbalik usa ka espesyal nga identifier diin makuha nimo ang sunod nga bahin sa datos. Kung kini nga identifier adunay usa ka walay kinutuban nga kinabuhi (sama sa Comsos DB), nan kini usa ka maayong paagi sa pagpatuman sa paging nga adunay sunud-sunod nga pagbalhin tali sa mga panid (opsyon #2 nga gihisgutan sa ibabaw). Ang posibleng mga disbentaha niini: wala kini gisuportahan sa tanang DBMS; ang moresulta nga sunod-sunod nga tipak identifier mahimong adunay limitado nga kinabuhi, nga kasagaran dili angay alang sa pagpatuman sa interaksyon sa gumagamit (sama sa ElasticSearch scroll API).

Komplikado nga pagsala

Atong pakomplikado ang buluhaton. Ibutang ta nga adunay kinahanglanon nga ipatuman ang gitawag nga faceted search, nga pamilyar kaayo sa tanan gikan sa mga online store. Ang mga pananglitan sa ibabaw nga gibase sa lamesa sa mga order dili kaayo ilustrasyon sa kini nga kaso, busa magbalhin kita sa lamesa sa Produkto gikan sa database sa AdventureWorks:

Unsa ang ideya luyo sa faceted search? Ang kamatuoran mao nga alang sa matag filter nga elemento ang gidaghanon sa mga rekord nga nakab-ot niini nga sukdanan gipakita nga gikonsiderar ang mga filter nga gipili sa tanan nga ubang mga kategorya.

Pananglitan, kon atong pilion ang Bikes category ug ang kolor nga Itom niini nga pananglitan, ang lamesa magpakita lamang og itom nga mga bisikleta, apan:

• Alang sa matag sukdanan sa grupo sa Mga Kategorya, ang gidaghanon sa mga produkto gikan sa kana nga kategorya ipakita sa itom.
• Alang sa matag sukdanan sa grupo nga "Mga Kolor", ang gidaghanon sa mga bisikleta niini nga kolor ipakita.

Ania ang usa ka pananglitan sa resulta nga output alang sa ingon nga mga kondisyon:

Kung imong susihon usab ang kategorya nga "Sinina", ipakita usab sa lamesa ang itom nga mga sinina nga naa sa stock. Ang gidaghanon sa mga itom nga produkto sa seksyon nga "Kolor" usab kalkulado sumala sa bag-ong mga kondisyon, sa seksyon lamang nga "Mga Kategorya" walay mausab ... Nanghinaut ko nga kini nga mga pananglitan igo na aron masabtan ang naandan nga faceted search algorithm.

Karon atong mahanduraw kung giunsa kini ipatuman sa usa ka relational nga basehan. Ang matag grupo sa mga criteria, sama sa Category ug Color, magkinahanglan og bulag nga pangutana:

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

Unsa ang sayup niini nga solusyon? Yano ra kaayo - dili maayo ang pagsukod. Ang matag filter nga seksyon nanginahanglan usa ka lahi nga pangutana aron makalkulo ang gidaghanon, ug kini nga mga pangutana dili ang labing kadali. Sa mga online nga tindahan, ang pipila ka mga kategorya mahimo’g adunay daghang dosena nga mga seksyon sa pagsala, nga mahimo’g usa ka seryoso nga isyu sa pasundayag.

Kasagaran pagkahuman sa kini nga mga pahayag gitanyag ako pipila nga mga solusyon, nga mao:

• Isagol ang tanang ihap sa gidaghanon sa usa ka pangutana. Sa teknikal nga paagi posible kini gamit ang UNION nga keyword, apan dili kini makatabang pag-ayo - ang database kinahanglan pa nga ipatuman ang matag usa sa mga tipik gikan sa wala.
• Mga gidaghanon sa cache. Gisugyot kini kanako halos matag higayon nga maghulagway ako og problema. Ang caveat mao nga kini sa kasagaran imposible. Ingnon ta nga kita adunay 10 ka "facets", nga ang matag usa adunay 5 nga mga kantidad. Kini usa ka "kasarangan" nga kahimtang kung itandi sa makita sa parehas nga mga tindahan sa online. Ang pagpili sa usa ka facet nga elemento makaapekto sa gidaghanon sa 9 sa uban, sa laing pagkasulti, alang sa matag kombinasyon sa mga criteria ang gidaghanon mahimong lahi. Sa among pananglitan, adunay kinatibuk-an nga 50 nga mga kriterya nga mapili sa tiggamit, busa, adunay 250 nga posible nga mga kombinasyon. Dinhi mahimo nimong supakon ug isulti nga dili tanan nga mga kombinasyon tinuod ug ang tiggamit panagsa ra nga mopili labaw pa sa 5-10 nga pamatasan. Oo, posible nga buhaton ang tapolan nga pag-load ug pag-cache sa usa ka gidaghanon sa kung unsa lang ang napili, apan kung daghan ang mga pagpili, labi ka dili kaayo episyente ang ingon nga cache ug labi ka mamatikdan ang mga problema sa oras sa pagtubag (ilabi na kung ang regular nga pagbag-o ang set sa datos).

Maayo na lang, ang ingon nga problema dugay na nga adunay epektibo nga mga solusyon nga magamit matag-an sa daghang mga volume sa datos. Alang sa bisan unsa niini nga mga kapilian, makatarunganon nga bahinon ang pagkalkula pag-usab sa mga bahin ug pagdawat sa panid sa mga resulta sa duha nga managsama nga tawag sa server ug pag-organisar sa interface sa gumagamit sa paagi nga ang pagkarga sa datos pinaagi sa mga bahin "dili makabalda" sa pagpakita sa resulta sa pagpangita.

• Tawga ang usa ka kompleto nga pagkalkula pag-usab sa "mga bahin" nga panagsa ra kutob sa mahimo. Pananglitan, ayaw kalkulaha pag-usab ang tanan sa matag higayon nga mausab ang mga criteria sa pagpangita, apan pangitaa ang kinatibuk-ang ihap sa mga resulta nga mohaum sa kasamtangan nga mga kondisyon ug i-aghat ang tiggamit sa pagpakita kanila - "1425 nga mga rekord ang nakit-an, gipakita?" Ang user mahimong magpadayon sa pagbag-o sa mga termino sa pagpangita o i-klik ang "ipakita" nga buton. Sa ikaduhang kaso ra ang tanan nga mga hangyo alang sa pagkuha sa mga resulta ug pagkalkula pag-usab sa gidaghanon sa tanan nga "mga bahin" ipatuman. Sa kini nga kaso, ingon sa dali nimo makita, kinahanglan nimo nga atubangon ang usa ka hangyo aron makuha ang kinatibuk-ang ihap sa mga resulta ug ang pag-optimize niini. Kini nga pamaagi makita sa daghang gagmay nga mga tindahan sa online. Dayag nga dili kini usa ka panacea alang sa kini nga problema, apan sa yano nga mga kaso mahimo kini usa ka maayong pagkompromiso.
• Gamita ang mga search engine aron makapangita mga resulta ug mag-ihap sa mga bahin, sama sa Solr, ElasticSearch, Sphinx ug uban pa. Ang tanan niini gilaraw aron magtukod og "mga bahin" ug buhaton kini nga episyente tungod sa balit-ad nga indeks. Giunsa ang pagtrabaho sa mga search engine, ngano nga sa ingon nga mga kaso mas epektibo sila kaysa mga database sa kinatibuk-ang katuyoan, kung unsang mga gawi ug mga lit-ag ang naa - kini usa ka hilisgutan alang sa usa ka lahi nga artikulo. Dinhi gusto nakong ipunting ang imong atensyon sa kamatuoran nga ang search engine dili mahimong kapuli sa panguna nga pagtipig sa datos, gigamit kini ingon usa ka pagdugang: bisan unsang mga pagbag-o sa panguna nga database nga may kalabotan sa pagpangita gi-synchronize sa indeks sa pagpangita; Ang search engine kasagaran makig-interact lamang sa search engine ug dili maka-access sa main database. Usa sa labing hinungdanon nga punto dinhi mao kung giunsa ang pag-organisar sa kini nga pag-synchronize nga kasaligan. Kini tanan nagdepende sa mga kinahanglanon sa "panahon sa reaksyon". Kung ang oras tali sa usa ka pagbag-o sa panguna nga database ug ang "pagpadayag" niini sa pagpangita dili kritikal, mahimo ka maghimo usa ka serbisyo nga nangita alang sa bag-o nga nabag-o nga mga rekord matag pipila ka minuto ug gi-index kini. Kung gusto nimo ang labing kadali nga posible nga oras sa pagtubag, mahimo nimong ipatuman ang usa ka butang nga sama transactional nga outbox aron ipadala ang mga update sa serbisyo sa pagpangita.

kaplag

1. Ang pag-implementar sa server-side paging usa ka mahinungdanong komplikasyon ug makatarunganon lamang alang sa paspas nga pagtubo o yano nga dagkong mga set sa datos. Wala'y hingpit nga eksaktong resipe kung unsaon pagtimbang-timbang ang "dako" o "paspas nga pagtubo", apan akong sundon kini nga pamaagi:
   • Kung ang pagdawat sa usa ka kompleto nga koleksyon sa datos, nga gikonsiderar ang oras sa server ug transmission sa network, mohaum sa mga kinahanglanon sa pasundayag sa normal, wala’y punto sa pagpatuman sa paging sa kilid sa server.
   • Mahimong adunay usa ka sitwasyon diin walay mga problema sa pasundayag nga gipaabot sa duol nga umaabot, tungod kay adunay gamay nga datos, apan ang pagkolekta sa datos kanunay nga nagtubo. Kung ang pila ka hugpong sa datos sa umaabot dili na makatagbaw sa miaging punto, mas maayo nga magsugod dayon sa paging.
2. Kung walay estrikto nga kinahanglanon sa bahin sa negosyo nga ipakita ang kinatibuk-ang ihap sa mga resulta o ipakita ang mga numero sa panid, ug ang imong sistema walay search engine, mas maayo nga dili ipatuman kini nga mga punto ug ikonsiderar ang opsyon #2.
3. Kung adunay usa ka tin-aw nga kinahanglanon alang sa faceted nga pagpangita, adunay ka duha nga kapilian nga wala gisakripisyo ang pasundayag:
   • Ayaw kwentahon pag-usab ang tanang gidaghanon sa matag higayon nga mausab ang criteria sa pagpangita.
   • Gamita ang mga search engine sama sa Solr, ElasticSearch, Sphinx ug uban pa. Apan kini kinahanglan nga masabtan nga kini dili mahimong usa ka puli alang sa nag-unang database, ug kinahanglan nga gamiton ingon nga usa ka dugang sa mga nag-unang storage alang sa pagsulbad sa mga problema sa pagpangita.
4. Usab, sa kaso sa faceted search, makatarunganon nga bahinon ang pagkuha sa panid sa mga resulta sa pagpangita ug ang pag-ihap sa duha ka managsama nga mga hangyo. Ang pag-ihap sa gidaghanon mahimong mas dugay kay sa pagkuha sa mga resulta, samtang ang mga resulta mas importante sa tiggamit.
5. Kung naggamit ka usa ka database sa SQL alang sa pagpangita, ang bisan unsang pagbag-o sa code nga may kalabotan sa kini nga bahin kinahanglan nga maayo nga sulayan alang sa pasundayag sa angay nga kantidad sa datos (labaw sa gidaghanon sa live database). Gisugyot usab nga gamiton ang pag-monitor sa oras sa pagpatuman sa pangutana sa tanan nga mga higayon sa database, ug labi na sa "live" nga usa. Bisan kung maayo ang tanan sa mga plano sa pangutana sa yugto sa pag-uswag, samtang ang gidaghanon sa datos motubo, ang sitwasyon mahimong mamatikdan nga mausab.

Source: www.habr.com