Una missionum typicarum in omnibus applicationibus, quibus nota est, notitias quaerit secundum certas normas et eam in forma facili ad lectam proferebat. Addi possunt etiam optiones ad genus, adjunctio et paging. Negotium est, in doctrina, levi, sed cum solvendo, multae tincidunt faciunt numerum errorum, qui postea causam productivam patiuntur. Studeamus varias optiones considerare pro solvendo hoc problemate et commendationes emittere ad efficacissimam exsecutionem eligendam.
Page optionem # I "
Optio simplicissima quae in mentem venit est ostentatio paginae paginae proventuum inquisitionum in forma classica maxime sua.
Dicamus applicationis vestri database relativa utitur. In hoc casu, ut informationes hac forma exhibeas, necesse est duos SQL queries currere:
- Ordines pro pagina obtine.
- Numerum linearum computare criteriis quaestionibus respondentem - id est paginas proponere necesse est.
Inspice primam interrogationem utens experimentum MS SQL database in exemplum pro MMXVI servo. Ad hoc utemur mensa Sales.SalesOrderHeader:
SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
Quaestio superior reddet primos 50 ordines e elencho, descendendo ad tempus additi, id est per 50 ordines recentissimos.
Celeriter in basim currit, sed consilium exsecutionis inspiciamus et I/O statistica:
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.Potes obtinere I/O statistica pro singulis interrogationibus currentibus STATISTICA IO DE imperium in inquisitione temporis.
Ut videre potes ex consilio exsecutionis, optio maxime intensiva est ut omnes ordines a fonte mensae ad tempus adiectos disponat. Et dubium est, quo plures ordines in tabula apparuerint, eo "durius" genus erit. In praxi, huiusmodi condiciones vitandae sunt, sic adiiciamus indicem additicii et vide an copia consumptio mutata sit;
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.
Multum melius patet. Sed omnesne problemata solvuntur? Quaesitum est ut quaeramus ordines ubi totalis sumptus bonorum $100 excedit, inmutemus;
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.Ridiculam condicionem habemus: quaesitum consilium non multo peius est quam priore, sed numerus actualis lectionum logicalium paene duplo maior est quam cum plena mensa scan. Explicatio est - si indicem compositum ex indice iam exsistente facimus et totum pretium bonorum in secundo campo addimus, iterum 165 logicum legitimum habebimus:
CREATE INDEX IX_SalesOrderHeader_OrderDate_SubTotal on Sales.SalesOrderHeader(OrderDate, SubTotal);
Haec exemplorum series diu continuari potest, sed duae praecipuae cogitationes, quas hic exprimere volo, sunt;
- Addere novam quamlibet regulam vel ordinem ad interrogationem inquisitionis notabilem ictum habere potest celeritas investigationis.
- Sed si solam partem notitiarum demere et non omnes eventus qui quaestioni responderet, multi modi sunt ad talem interrogationem optimize.
Nunc ad alteram quaestionem de qua in ipso initio transeamus - eum qui numerum monumentorum numerat quae criterium inquisitionis satisfaciunt. Idem sumamus exemplum - exquirendo ordines qui plus quam $ 100 sunt;
SELECT COUNT(1) FROM Sales.SalesOrderHeader
WHERE SubTotal > 100
Composito indice supra indicato obtinemus;
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.Quod quaesitum est per totum indicem non mirum est, cum campus SubTotal priore loco non sit, quaesitio ergo eo uti non potest. Problema solvitur addendo alium indicem in SubTotal agro, et per consequens solum 48 logicum legit.
Plura exempla petitionum quantitatum numerandi dare potes, sed essentia eadem manet; accipientes partem datam et summam computantes sunt duae petitiones fundamentaliter diversaeet sua quaeque ad optimizationem requirit. In universum non poteris invenire compositiones indices qui in utraque quaestione aeque bene operantur.
Ideoque unum ex maximis requisitis declarari debet cum explicatio talis solutionis inquisitionis est an vere magni momenti sit negotium videre numerus rerum inventarum. Saepe ut nulla. Navigatio autem per numeros paginas specificas, ut arbitror, ββsolutio est scopo valde angusto, cum plerique missiones paginae similes "ire ad proximam paginam" spectant.
Page optionem # I "
Sumamus usores non curo scire numerum rerum inventarum. S conantur paginae simpliciorem reddere:
Re quidem vera, una res mutata est quod nullo modo ad certos paginas numeros navigandum est, et nunc haec tabula non indiget scire quot possunt esse ut eam ostendant. Sed quaestio oritur - quomodo novit mensa an pagina altera data sit (ut recte nexum "nexum" ostendat?
Responsio valde simplex est: plus e monumento datorum legere potes quam ad ostentationem opus est, et praesentia huius "additionalis" recordationis ostendet num altera portio sit. Hoc modo , tantum postulo ut unam petitionem persequaris ut unam paginam notitiarum , quae signanter ad effectum deducitur , et facilius ad huiusmodi functionem sustinendam mittat . In usu meo erat casus cum nollet numerare totalem numerum monumentorum celeritatum traditio proventuum 4-5 temporibus.
Plures optiones interfaces usorum ad hanc accessionem sunt: ββ"retro" et "proferre" mandata, ut in exemplo supra, "auro plus" conjunctionem, quae simpliciter addit novam portionem ad proventus propositos, "librum infinitum", quod operatur in principio "plus oneris"", sed signum ut proximam partem accipias, est utentis ad librum omnium eventuum exhibitorum ad finem. Quidquid solutionis visualis, principium notitiae sampling manet idem.
Nuances paginae implementation
Omnia exempla interrogationis supra posita "comite+" utuntur, cum ipsa quaestio specificat quo ordine eventum ordinum et quot ordines reddantur necesse est. Primum inspiciamus quonam modo commodissime parametri in hoc casu transitum instituant. Pluribus modis in usu veni;
- Vide numerum paginae rogatae (pageIndex), magnitudo paginae (pageSize).
- Vide numerum tabulae primae ut reddendum (startIndex), maximus numerus monumentorum in eventum (comitem).
- Sequentia numerus recordationis primi ut reddatur (startIndex), sequentia numerus recordi ultimi reddendus est (endIndex).
Primo aspectu videri potest quod hoc ita sit quod nulla differentia sit. Sed hoc non est ita - optio commodissima et universalis est secunda (startIndex, count). Huius rei plures sunt rationes;
- Ad +1 ingressum probationis accessio supra posita, optio prima cum pageIndex et paginaSize perquam incommodum est. Exempli gratia, 50 nuntia per paginam ostendere volumus. Secundum algorithmum supra, legere debes plus quam necesse est. Si hoc "+1" non impletur in calculonis, evenit ut pro prima pagina monumenta petamus ab 1 ad 51, pro secunda - ab 51 ad 101, etc. Si magnitudinem paginae indicas 51 et paginam indicem auges, secunda pagina ab 52 ad 102 redibit, etc. Itaque, in prima optione, unicus modus est ad conjunctionem rite efficiendam ut ad proximam paginam accedat, servo probationis "extra" linea, quae admodum implicata erit.
- Tertia optio omnino sensum non facit, cum in plurimis databases quaestionibus currere debebis comitem potius quam indicem ultimi recordi praeterire. StartIndex subtrahens ab endIndex potest esse operatio arithmetica simplex, sed hic superflua est.
Nunc describere incommoda paginae per "cinguli + quantitatis" persequendae sunt:
- Quaelibet pagina sequens recuperans carior erit et tardior quam prior, quia database adhuc opus erit per omnia monumenta "ab initio" secundum criteria quaestionis et voluptua, et tunc in fragmento desiderato desinet.
- Non omnes DBMSs aditus sustinere possunt.
Sunt alterna, sed sunt etiam imperfecta. Prima harum aditus appellatur "keyset paging" vel "modus quaerendi" et haec est: post acceptam portionem, potes meminisse campi valores in ultimis in pagina monumentis, ac deinde utere ut obtineas. altera portio. Exempli gratia sequentis interrogationis cucurrimus:
SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
Et in ultimo recordo cepimus valorem ordinis date '2014-06-29'. Deinde ut proximam paginam id facere conemur:
SELECT * FROM Sales.SalesOrderHeader
WHERE OrderDate < '2014-06-29'
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY
Problema est OrdinisDate campum non-unicum esse et condicionem supra definitam multum desiderare ordines requisitos verisimile est. Ut huic interrogationi unambiguitatem addere debes, agrum singularem conditioni addere (id quod 75074 est ultimum valorem clavis primariae a prima portione);
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
Haec optio recte laborabit, sed generatim difficile erit optimizare cum condicio OR operator continet. Si valor primariae clavis augetur ut OrdoDate augetur, condicio simplicior fieri potest, tantum filtrum a SalesOrderID relinquendo. At si nulla est stricta relatio inter valores primariae clavis et campi, quo effectus sortitur, hoc OR in plerisque DBMSs vitari non potest. Exceptio, quam novimus, est PostgreSQL, quae plene comparationem tuplam sustinet, et condicio illa scribi potest "UBI (OrderDate, SalesOrderID)" ('2014-06-29', 75074)". Clavem compositam cum his duobus agris positam, huius modi quaesitum satis facile esse debet.
Alter locus inveniri potest, verbi gratia, in aut - Cum petitio, praeter notitias, peculiarem identificatorem reddit, quo proximam partem notitiarum consequi possis. Si hic identifier vitam illimitata habet (ut in Comsos DB), haec magna via est ad paginas deducendi cum transitu sequentium inter paginas (optionem #2 supra memoratam). Potest incommodis: non omnibus DBMSs; FRUSTUM proximum consequens identifier vitam limitatam habere potest, quae plerumque non convenit ad exsequendam commercium usoris (qualis est volumen API ElasticSearch).
Complexum eliquare
Porro negotium inpediamus. Puta est necessitas ad efficiendum inquisitionem sic dictam multimodis, quae omnibus ex tabernis interretialibus est familiarissima. Exempla superiora in mensa ordines fundata non admodum illustrant in hoc casu, ut transeas ad mensam productam ex database AdventureWorks:
Quae est idea post inquisitionem multiformis? Re vera in singulis elementis colum numero monumentorum quae huic critioni obviare ostenditur attentis odio delectus in ceteris generibus.
Exempli gratia, si categoriam Bikes eligendo et nigrum colorem in hoc exemplo, mensa tantum dapibus nigris ostendet, sed:
- Uterque criterium in Categoriis group, numerus productorum ex illo categoria in nigro ostendetur.
- Pro unaquaque criterii "Colorum" circulo, numerus birotarum huius coloris ostendetur.
Hic exemplum est effectus output pro talibus conditionibus:
Si categoriam "Vestimentorum" etiam reprehendo, mensa etiam vestes nigras quae in genere sunt ostendet. Numerus productorum nigrorum in sectione "coloris" etiam secundum novas conditiones calculare poterit, tantum in sectione "Categoriae" nihil mutabitur... Spero haec exempla sufficere ad algorithmum inquisitionis facietae consuetum intelligere.
Nunc cogitemus quomodo hoc in relatione relationis effici possit. Uniuscuiusque coetus criteriis, ut Categoria et Color, quaesitum separatum requiret:
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
Quid hac solutione mali? Valde simplex est - non bene scandere. Quaelibet colum sectio requirit interrogationem separatam ad quantitates calculandi, et hae interrogationes facillimae non sunt. In tabernis online, quaedam categoria plures duodenas colum sectiones habere possunt, quae res gravis effectus esse potest.
Solet autem post haec dicta solutiones aliquas proferre, scilicet:
- Quantitas omnis in unam quaestionem valet. Technice hoc potest uti keyword UNIONIBUS, sed non multum adiuvabit - database adhuc singula fragmenta ex integro exsequi debebunt.
- Cache quantitatum. Hoc mihi suggeritur omni fere tempore problema describere. Cavendi causa hoc generaliter impossibile est. Dicamus nos habere 10 "facetes", quorum unumquodque habet 5 valores. Valde haec condicio "modica" comparatur ad ea quae in eisdem thesauris online conspici possunt. Electio elementi unius faceti afficit quantitates in aliis 9 aliis, id est, pro unaquaque compositione re- gularum quantitatum diversae esse possunt. In nostro exemplo exstant summae 50 criteria quae usor deligere potest, ergo 250 compositiones possibilis erunt, satis memoria vel tempus non est ad talem notitiarum seriem implendam. Hic obicere potes et dicere non omnes coniunctiones reales esse et rarius utens plus quam 5-10 criteria eligere. Imo, fieri potest ut pigrum onerandum et cella quantitatem solum quae semper delectae sunt, sed quo plura exstant, eo minus efficax talis cella erit ac magis notabilis responsio temporis problematum erit (praesertim si e. notitia paro mutationes regulariter).
Fortunate talis quaestio iam diu satis efficaces solutiones habuit, quae praevidere operantur in magnis voluminibus notitiarum. Pro quavis harum optionum, sensum facit recalculationem oculorum dividere et proventus paginas in duas parallelas vocationum ministranti accipere et usoris interfaciem ordinare ita ut notitias onerantium per facies "non impedit" cum ostensione Search Results.
- Plenam recalculationem "oculorum" quam raro fieri potest voca. Exempli gratia, omnia non computare omni tempore inquisitionis mutationes criteria quaestionis, sed inveniunt totum numerum eventuum qui hodiernis conditionibus aequant et usorem promptum ad demonstrandum - "1425 monumenta inventa, demonstrant?" Usor pergere potest vel mutare verba investigationis vel deprimendo "ostendere" deprimendo. Solum in secundo casu omnes petitiones obtinendi proventus et quantitates recalculantes in omnibus "facets" exsecutioni mandabuntur. In hoc casu, ut facile perspicis, roganti agere debebis ut summam eventorum summam obtineat atque optimam. Haec methodus in multis parvis thesauris reperiri potest. Patet, hoc problema non est panacea, sed in casibus simplicibus bonum compromissum esse potest.
- Utere tormentis quaesitis ad inveniendas eventus et facetias numerandas, ut Solr, ElasticSearch, Sphinx et alii. Omnes hi ad "faces" aedificandas ordinantur et hoc satis efficaciter ex inverso indice faciunt. Quomodo tormenta quaesita operantur, cur in talibus efficaciora sunt quam ad databases generales, quae exercitia et foveae sunt - hoc est thema pro articulo separato. Hic animum intendere volumus ad id quod inquisitionis machinamentum non potest substitui pro repositione principali, adhibetur ut additamentum: quaelibet mutationes in datorum principalium, quae ad inquisitionem pertinentes sunt, in indice inquisitionis synchronised; Quaesitio machinae plerumque intervenit tantum cum engine inquisitionis et datorum principalium non accedere. Inter praecipua puncta hic certo modo ordinare hanc synchronizationem. Refert requisita in "tempus reactionem". Si tempus inter mutationem datorum principalis et eius "manifestationum" in inquisitione critica non est, ministerium creare potes quod recenter mutatis singulis momentis et indices quoslibet exquirit. Si vis quam brevissimum tempus responsionis, aliquid simile efficere potes mittere updates ut investigationis servitium.
Inventiones
- Exsequens paginae server latus complicatio notabilis est et solum sensum facit ad celeriter crescendum vel simpliciter ampla data copia. Nulla prorsus exacta recipe quomodo "magnus" vel "celeriter crescens" aestimare possit, sed accessum sequi volo:
- Si plenam datorum collectionem recipiens, ratione temporis et servientis transmissionis retis, aptat ad requisita consuetudinaria perficiendi, punctum in exsequendo paginae in calculonis latere nihil deest.
- Locus esse potest ubi nullae difficultates perficiendi in proximo futuro exspectantur, cum parum notitiae sit, sed collectio data constanter crescit. Si aliquae copiae notitiarum in futuro puncto priori amplius satisfacere non possunt, melius est statim paginas incipere.
- Si nulla est stricta exigentia negotii ut numerum proventuum exhibeat vel paginas numeros exhibeas, et ratio tua inquisitionem non habet, melius est haec puncta non efficere et optionem #2 considerare.
- Si manifesta necessitas est inquisitionis manifestae, duas optiones sine sacrificio perficiendi habes:
- Noli computare omnes quantitates omni tempore mutationes criteria quaestionis.
- Utere tormentis quaesitis ut Solr, ElasticSearch, Sphinx et alii. Sed sciendum est non posse subrogationem datorum praecipuorum, et additamentum ad principale repositorium pro solvendis quaestionibus solvendis.
- Etiam in inquisitione oculata, sensum efficit scindendi retrevalationem proventuum paginarum et in duas petitiones parallelas numerandas. Quantitates numerandi longiores consequi possunt quam consecutiones, dum eventus utentis graviores sunt.
- Si SQL database ad quaerendum uteris, quaelibet codicis mutatio ad hanc partem pertinentia bene probata sit ad faciendum debitam quantitatem notitiarum (excedente volumine in datorum vivo). Expedit etiam vigilantia interrogationis executionis temporis in omnibus instantia datorum, et praesertim in "vivere" unum. Etiamsi omnia subtilia cum interrogatione consiliorum in scaena evolutionis, prout volumen notitiarum crescit, res notabiliter mutare potest.
Source: www.habr.com