Vairāk

SQL vaicājums ArcGIS modeļa atlases rīkā notiek ļoti lēni

SQL vaicājums ArcGIS modeļa atlases rīkā notiek ļoti lēni


Esmu strādājis, lai atrastu īsākos ceļus no dzīvojamo māju kvartālu sērijas (formas fails ar daudzstūra centriem) līdz vairākām atpūtas zonām. Man kopumā ir 9 OD izmaksu matricas (spēļu laukumi 1000 m attālumā, spēļu laukumi 600 m attālumā, spēļu laukumi 300 m attālumā un pēc tam atpūtas un zaļās atpūtas zonas no jauna).

Tā kā katram galamērķa daudzstūrim (spēles laukumi, gren rec zonas, rekreācijas zonas) ir vairāki ieejas punkti, OD izmaksu matricā ir vairāki maršruti uz katru galamērķi. Man vajag tikai īsāko no šiem maršrutiem.

Tāpēc esmu izveidojis modeli, lai izietu cauri katrai OD izmaksu matricai un izvēlētos īsāko maršrutu no katra bloka uz katru uzskaitīto galamērķi.

Pirms tam esmu darījis tikai apmēram trīs modeļus, un man šķiet, ka tas ir diezgan neapstrādāts.

Modelis sastāv no šādiem elementiem:

1. daļa - Atkārto, izmantojot OD izmaksu matricas failus 2. daļa - Iekļauts 1. daļā - Eksportē visus maršrutus no viena bloka uz atsevišķu formas failu, izmantojot atkārtotu rindu atlasi un kopēšanas funkciju 3. daļa - ligzdota 2. daļā - Šeit modelis atkārtots galamērķa ID (katram galamērķa daudzstūrim ir savs ID, tāpat kā visiem tā perimetra galamērķa punktiem), atlasa visus ierakstus ar vienādiem galamērķa ID un saglabā tos jaunā formas failā. Tad tas paņem šo formas failu, izmanto 'Aprēķināt vērtību', lai atlasītu mazāko attāluma vērtību, un, izmantojot citu atlases rīku ar šādu SQL vaicājumu, tiek atlasīts ieraksts ar mazāko attālumu un saglabāts kā atsevišķs formas fails.

"Total_Leng" = %output_value %

kur % output_value % ir vērtība, ko nodod rīks “Aprēķināt vērtību”

Šī pēdējā atlases rīka atkārtošana ilgst no 3 līdz 6 minūtēm. Modelis darbojas jau 6 dienas, un tas ir izgājis tikai 600 no 2400 ierakstiem no PIRMĀ no deviņiem formas failiem.

Lielākā problēma ir 3. daļa. Esmu pārliecināts, ka ir efektīvāka alternatīva atlases saglabāšanai kā formas faili. Es domāju, ka būtu iespēja saglabāt atlases atmiņā, bet es tiešām to nevaru atrast, un es izlasīju, ka modeļu veidotājs nav tik lielisks, lai strādātu no atmiņas.

Vai ir kādi ieteikumi, kā uzlabot veiktspēju? Šī modeļa rezultāti ir labi, taču tas ir vienkārši pārāk lēns. Es meklēju līdzīgas problēmas, bet neko konkrētu neatradu. Varbūt kādam šeit ir kādi ieteikumi? Es zinu, ka es varētu paveikt labāku darbu ar Python, bet es nevaru atļauties laiku, lai iekļūtu Python, pārsniedzot pamatus (ko es zinu - pašus pamatus).

Tālāk esmu pievienojis modeļa attēlus, ja nepieciešams, es varētu pievienot arī python skriptus.


Es atbildēšu uz savu jautājumu. Pēc dažiem pētījumiem es atklāju, ka atbilde ir izmantot funkciju slāņus (skat. ESRI palīdzības lapu), nevis saglabāt starpposma rezultātus formas failos. Atlases rīks, kas aizņēma līdz 6-7 minūtēm, tagad aizņem apmēram 0,9 sekundes.

Diezgan atšķirība!


SQL Server lēni izvēlieties no lielas tabulas

Vaicājuma izpilde dažreiz aizņem līdz 4 minūtēm, kas nav pieņemami.

Es nevaru veikt sadalīšanu utt., Jo izmantoju SQL Server standarta versiju, un Enterprise ir pārāk dārga.

Es arī domāju, ka galds ir diezgan mazs, lai būtu tik lēns.

Es domāju, ka problēma ir klauzulā ORDER BY, jo db ir jāiet cauri daudz lielākam datu kopumam.

Ir kādas idejas, kā to padarīt ātrāk?

Varbūt relāciju datu bāze nav laba ideja šāda veida datiem.

Dati vienmēr tiek paņemti pēc CreatedAt DESC pasūtījuma


Es varu SELECT my_func (x, y, z), kur x, y un z ir jebkura vērtību kombinācija, kas tai tiktu nodota pirmajā vaicājuma piemērā, un datu bāze tikko nemirgo. Es tiešām pakasu galvu par šo.

Iemesls, kāpēc man ir nepieciešama šī funkcija, ir ļaut man izpildīt atskaiti programmā SugarCRM. Pārskatu rakstīšanas spraudnis (KReports) dod man piekļuvi noteiktām datu bāzes entītijām un attiecībām, taču ir vairāki skaitļi, kuriem pārskats neļauj piekļūt. Pielāgotā funkcija ir izveidota, lai atgrieztu skaitļus (desmit no tiem) katrai rindai, kuru atgriež galvenais pārskats, faktiski sniedzot lietotājam 10xN vērtību rakurstabulu.

Ziņojumā tiek atgrieztas tikai dažas rindas katru reizi, kad tas atgriežas, un tas mani mulsināja. Šie rezultāti ir sagrupēti no pamatā esošajiem datiem, kas ir daudz lielāki. Pielāgotā funkcija tiek izpildīta (es pieņemu) galvenajā datu kopā pirms tam tiek piemērota GROUP BY, un tā tiek izsaukta par kārtību vairāk reizes, nekā es domāju.

Ja man šajā pārskatā būtu pilnīga kontrole pār SQL ģenerēšanu, es iekšējā vaicājumā atlasītu 30 (grupas) rindas un pēc tam ietītu to ārējā vaicājumā, lai izsauktu pielāgoto funkciju šajā mazākajā datu kopā. Šķiet, ka, lai to novērstu, man būs jāizmanto cits ziņošanas rīks.


Atšķirība noteikti ir tajā, kā tiek optimizēts vaicājums. Jums vajadzētu apskatīt izpildes plānus, lai iegūtu vairāk informācijas.

Pirmais ieteikums ir 1. tabulas indekss (2. sleja, datums, klienta ID).

Tomēr, tā kā tabula2 ir tik maza, jūs patiešām vēlaties izveidot braukšanas galdu savienošanai. Tas liecina par alternatīvu 1. tabulas indeksu (ClientId, Column2, Date). Vispirms tam vajadzētu veikt savienošanu, kas ievērojami samazinātu apstrādājamo rindu skaitu.

Es nojaušu, ka šeit notiek tas, ka pirmajā vaicājumā WHERE klauzula pieprasa datuma vērtību katram savienojuma ierakstam, bet otrajā vaicājumā tam nav jānotiek. Viena iespēja ir tāda, ka vaicājumu optimizētājs pilnībā izlaiž 2. tabulas vērtību meklēšanu, izpildot klauzulu WHERE jūsu otrajā vaicājumā.

Ņemiet vērā, ka klauzula WHERE tiek izpildīta pirms GROUP BY, tāpēc šie vaicājumi, šķiet, ir identiski, izņemot klauzulu WHERE.


1 Atbilde 1

Šķiet, ka neliela plāna daļa atšķiras atkarībā no tā, vai ir filtrs. Es cenšos apkopot notiekošo, bet tas ir nopietns apmulsums, cenšoties visu saskaņot. Nezinot tādu lietu definīcijas kā 1. tabula. Indekss 9 un 2. tabula. Indekss 38 būs ļoti grūti saņemt konkrētu palīdzību ar visdārgākajiem operatoriem, kas jums šeit ir.

Pa to laiku man ir daži vispārīgi veiktspējas ieteikumi, izņemot skata sarežģītības samazināšanu un varbūt apsvēršanu vienkāršāku skatu sniegšanā 130 kolonnas (mēģiniet nekrist ar acīm, skatoties uz šo pievienošanās diagrammu):

(1) pārliecinieties, ka jūsu statistika ir atjaunināta visās tabulās. Gandrīz katra darbība parāda milzīgu plaisu starp aprēķinātajām un faktiskajām rindām, kas varētu palīdzēt izskaidrot optimāli optimizējošās izvēles.

(2) atbrīvoties no diviem uzmeklējumiem, pievienojot šādus rādītājus šādiem rādītājiem (iespējams, kā slejas IEKLĀT):

(3) daži no šiem izteicieniem ir satraucoši, piem.

Nopietni? Rūpīgi apskatiet šo klauzulu (un šķiet, ka skats ir pakaišots ar desmitiem šo). Neviens cilvēks to nevarēja izdarīt apzināti. Tātad, kāds smadzeņu mirušo kodu ģenerators radīja šo putru?


Aprēķiniet kopējo nokrišņu daudzumu jebkurā laikā

Mums līdz šim ir slānis, kurā katra stacija ir apdzīvota ar kopējo nokrišņu daudzumu, kas aprēķināts no visiem laikrindu tabulas ierakstiem. Tagad mēs vēlamies piesaistīt nokrišņu stacijas ar kopējo nokrišņu daudzumu noteiktā laika periodā, piemēram, nedēļā, mēnesī, trīs dienu periodā vai jebkurā patvaļīgā laika periodā.

  • Atveriet Slāņa rekvizīti pēdējā sadaļā izveidotā vaicājuma slāņa lapu un noklikšķiniet uz tā Avots cilni.
  • Noklikšķiniet uz zilā zīmuļa ikonas, lai atvērtu Rediģēt vaicājuma slāni dialoglodziņš.

  • Tieši aiz laikrindu tabulas nosaukuma ievietojiet WHERE klauzulu ar diapazona parametru.
    KUR :: r: timeRange

  • Noklikšķiniet uz zīmuļa ikonas, lai atvērtu rindas redaktoru parametra definēšanai.
  • Aizpildiet visu nepieciešamo informāciju, kā parādīts šajā ekrānuzņēmumā:
    1. Lauks vai izteiksme - ierakstiet datums Laiks.
    2. Datu veids - izvēlieties Datums.
    3. Noklusējuma vērtība - noņemiet atzīmi no izvēles rūtiņas.
    4. Tabulas nosaukums, kuram lauks pieder - tips USGS_RAINFALL_TIMESERIES_IL.

  • Klikšķis Pabeigts.
  • Apstipriniet SQL vaicājuma slāni.
  • Klikšķis Nākamais.
  • Klikšķis Pabeigt.

Ja noklikšķināsit uz Laiks cilni uz Slāņa rekvizīti lapā, jūs redzēsit, ka laika iestatījumi tika automātiski definēti. Kad definējat datuma tipa diapazona parametru, slānis tiek automātiski informēts par laiku un sāks ievērot kartes un laika slīdņa iestatījumus.

Kartē parādās laika slīdnis.

Jūs redzēsit stacijas ar nokrišņu mērījumiem šajā nedēļā.

Izmantojiet laika slīdni, lai pārietu uz citu nedēļu, vai mainiet laika iestatījumus, lai skatītu rezultātus citā laika periodā. Ja vēlaties, varat iestatīt laika periodu uz divām nedēļām vai jebkuru patvaļīgu laika ilgumu, un jūs redzēsit, ka karte tiek atjaunināta ar dinamiski aprēķinātu kopējo nokrišņu daudzumu šajā laika periodā.


Vaicājumu optimizētājam ir vairāki operatori, lai gan izpildes dzinējam ir diezgan maz. Ilustrācijai es izmantošu jūsu tabulu vienkāršotu versiju - (SQL Fiddle).

Ņemot vērā šīs tabulas un datus, aplūkosim trīsvirzienu UNION vaicājuma ievades koku:

Loģiskajam savienotāja operatoram ir viena izeja un trīs bērnu ievades. Pēc uz izmaksām balstītas optimizācijas izvēlētais fiziskais koks ir apvienošanās savienība ar trim ievadiem:

Optimizatora izvade tiek pārstrādāta tādā formā, ar kuru izpildes dzinējs (bez n-ary sapludināšanas savienotāja) var rīkoties šādi:

Pēc optimizācijas pārrakstīšana atver n-ary PhyOp_MergeUnion vairākos apvienošanas savienības operatoros. Ievērojiet, kā visas paredzamās izmaksas paliek saistītas ar “sākotnējo” arodbiedrības operatoru - pārējiem izmaksu aprēķins ir nulle.

Tas, ka optimizētājs pamato arodbiedrības, kurās tiek izmantoti vairāki operatori, sniedz vienu skaidrojumu, kāpēc tas neuzskata, ka jūsu pirmais piemērs ir jāpārraksta uz to pašu plānu kā otrais piemērs (trīsceļu savienība ir viena koka mezgls).

Otrs iemesls ir tas, ka nav ierobežojumu, lai panāktu “pārklāšanās trūkumu”. Pirms tiek ieviesti ierobežojumi, nevar garantēt, ka savienība starp boo un koo neražos dublikātus, tāpēc mēs iegūstam dublikātu noņemšanas plānu (šajā gadījumā apvienošanās savienība):

Pievienojot šādus ierobežojumus, tiek nodrošināts, ka nosacījumu, kas nepārklājas, nevar pārkāpt, ja vaicājuma plāni netiek atcelti.

Tagad optimizētājam ir droši vienkārši savienot:

Tomēr, pat ievērojot šos ierobežojumus, trīsceļu savienības vaicājums joprojām parādās kā trīs arodbiedrības, jo optimizētājs parasti neapsver iespēju sadalīt vairākus operatorus, lai izpētītu alternatīvas. N-ary operatora lieta ir ļoti noderīga, lai kontrolētu meklēšanas telpu, to sadalot, bieži vien būtu neproduktīvi, ņemot vērā optimizētāja mērķi ātri atrast labu plānu.

Rakstot kā UNION un UNION ALL, n-ary operatoru vairs nevar izmantot (veidi neatbilst), tāpēc kokam ir atsevišķi mezgli:


Aklās SQL injekcijas ievainojamības

Daudzi SQL ievadīšanas gadījumi ir aklas ievainojamības. Tas nozīmē, ka lietojumprogramma neatgriež SQL vaicājuma rezultātus vai informāciju par jebkādām datu bāzes kļūdām savās atbildēs. Aklās ievainojamības joprojām var izmantot, lai piekļūtu neatļautiem datiem, taču izmantotās metodes parasti ir sarežģītākas un grūtāk izpildāmas.

Atkarībā no ievainojamības veida un iesaistītās datubāzes, lai izmantotu aklas SQL injekcijas ievainojamības, var izmantot šādas metodes:

  • Varat mainīt vaicājuma loģiku, lai izraisītu konstatējamu atšķirību lietojumprogrammas atbildē atkarībā no viena nosacījuma patiesuma. Tas var ietvert jauna nosacījuma ievadīšanu kādā Būla loģikā vai nosacītas kļūdas izraisīšanu, piemēram, dalīt ar nulli.
  • Varat nosacīti izraisīt laika aizturi vaicājuma apstrādē, ļaujot secināt nosacījuma patiesumu, pamatojoties uz laiku, kas nepieciešams, lai lietojumprogramma atbildētu.
  • Izmantojot OAST metodes, varat aktivizēt tīkla darbību ārpus joslas. Šī tehnika ir ārkārtīgi spēcīga un darbojas situācijās, kad citas metodes to nedara. Bieži vien jūs varat tieši izfiltrēt datus, izmantojot ārpus joslas esošo kanālu, piemēram, ievietojot datus jūsu meklētā domēna DNS uzmeklēšanā.

Lasīt vairāk


Kā izmantot tuvuma izsekošanas rīku

Tuvuma izsekošanas rīks analizē atsevišķu entītiju pārvietošanas punktu datu kopas - katrai funkcijai ir jābūt atrašanās vietai, laikam un entītijas identifikatoram. Šeit ir piemērs tam, kā tas izskatās, izmantojot datu paraugus:

Identifikators var būt virkne vai ciparu lauks - tas kalpo, lai identificētu izsekojamo entītiju, piemēram, ierīces ID vai nosaukumu. Šeit ir svarīgi atzīmēt, ka atsevišķu cilvēku izsekošanai ir stingri jāievēro vietējie un federālie noteikumi un privātuma likumi. Lūdzu, pārskatiet šo balto grāmatu, kurā ir izklāstīta paraugprakse privātuma izsekošanai.

Rīka parametri

Lai sāktu darbu ar tuvuma izsekošanu, vispirms pievienojiet punktu punktu ArcGIS Pro kartei un iespējojiet laiku). Tagad jūs esat gatavs aizpildīt rīka parametrus, izmantojot ievades slāni.

  1. Norādiet vienuma ID lauku. Tas norāda katras entītijas identifikatoru.
  2. Norādiet izsekojamās entītijas - tam ir nepieciešams unikālais ID (no tā paša lauka kā 1. darbība) un sākuma laiks. Ir laiks, kad vēlaties sākt ierakstīt tuvuma notikumus. 1970. gada 1. janvāris ir iestatīts kā noklusējums, ja nav norādīts laiks.
  3. Iestatiet tuvuma parametrus. Šeit jūs iestatīsit telpisko un laika slieksni, kas nosaka tuvuma notikumu - tas būs atkarīgs no tā, cik tuvu telpā un laikā vēlaties definēt “kontaktu”, bet arī no jūsu datu izšķirtspējas un GPS precizitātes.

Tagad jūs esat gatavs darbināt rīku - vienkārši noklikšķiniet uz Palaist.

Rezultātā tiek parādīta objektu klase, kas attēlo pirmo tuvuma notikumu katrai definētajai entītijai. Neviena funkcija netiek atgriezta, ja jūsu uzņēmums nav lejup pa straumi no interesējošās vienības. Atribūtu tabulā tiks uzskaitītas entītijas, kas atradās lejup pa straumi no interesējošām entītijām, ņemot vērā rīkā norādītos parametrus.

Papildus iepriekš minētajiem iestatījumiem varat arī atgriezt izsekošanas celiņu izvadi, kurā ir redzamas visas funkcijas, kas bija lejup pa notikumu. Tas ir ļoti noderīgi, lai laika gaitā vizualizētu atrašanās vietas. Varat palaist rīku Reconstruct Tracks, lai izveidotu lineārus ceļus starp vietām, lai palīdzētu vizualizēt.

Visbeidzot, ir divi izvēles parametri, kurus varat izmantot, lai noregulētu tuvuma notikumus:

  1. Iestatiet atstarpes pielaidi. Tas attiecas uz situācijām, kad visus notikumus starp diviem tuvuma notikumiem vēlaties uzskatīt par vienu ilgstošu notikumu, pat ja funkcijas starp tuvuma notikumiem tehniski neatbilst tuvuma parametriem. Tas var palīdzēt izlabot situācijas, kad GPS ieraksti netiek sinhronizēti laikā, neskatoties uz to, ka tie ir iegūti no tuvumā palikušiem ierakstiem (skat. Attēlu zemāk). Nepieļaujamās pielaides mainīs tikai notikuma ilgumu un nemainīsies notikuma gadījumā.

  1. Iestatiet atribūta izteiksmi. Atribūtu izteiksme ļauj iestatīt papildu prasības tuvuma notikumam. Piemēram, ēkā ar vairākiem līmeņiem, iespējams, vēlēsities Tuvuma izsekošana indivīdi, kas ieņēma tādu pašu līmeni. Šeit tuvuma notikumam būs jāatbilst jau definētajiem tuvuma parametriem, taču tam jābūt vienādam arī atribūtam level. Šajā gadījumā mēs pievienosim papildu izteiksmi $ target [“level”] == $pievienoties [“līmenis”] definēt šo prasību.

Jūs varat uzzināt vairāk par to, kā atrašanās vietas izlūkošana uzlabo COVID-19 sadarbību, un izlasīt balto grāmatu par ģeogrāfiskās informācijas sistēmām koronavīrusa plānošanai un reaģēšanai. Vietas izlūkošanas resursus skatiet COVID-19 ĢIS centrā. Koronavīrusa reaģēšanas risinājumu lapa piedāvā karšu un lietotņu kolekciju, ko sabiedrības veselības aģentūras var izmantot, lai izprastu vīrusa ietekmi un dalītos ar informāciju par pandēmiju ar savu kopienu.


Skatīties video: ArcGIS Enterprise: Managing ArcGIS Server