Grote schrijftransacties kunnen aanzienlijke service-uitvaltijd veroorzaken<\/LI><\/OL>Om beide problemen te vermijden is het beter om een CDC<\/A> (change data capture) aanpak te implementeren en alleen deltas naar de doel-feature service te schrijven. Deze blog beschrijft twee manieren om dit te doen:<\/P>- Deltas direct naar de doel-feature service schrijven<\/LI>
- Onderhoud een
gehoste feature layer view<\/A> die afwisselend naar twee services wijst- Schrijf delta-transacties naar de service niet<\/STRONG> momenteel de bron en
wissel<\/A> deze om de bron van de view te zijn<\/STRONG><\/LI><\/UL><\/LI><\/OL>In de gebruikelijke situatie waarin een periode-delta een klein deel van de data is, kan een directe delta-schrijfoperatie enkele seconden duren, terwijl bij een view source swap de uitvaltijd milliseconden kan zijn, maar met tweemaal de opslagkosten.<\/EM> We doen een uitgewerkt voorbeeld zodat je kunt kiezen tussen de benaderingen, maar hoe dan ook ben jij de winnaar met CDC!<\/STRONG><\/P>Hier is mijn vakinhoudelijke data, over ongeveer een miljoen straat adrespunten in Los Angeles<\/A>, Californië, dagelijks onderhouden:<\/P>
Los Angeles Address Points<\/span><\/span><\/P>De taak is om de dagelijkse delta-transactie te berekenen en toe te passen (typisch enkele honderden features) met lage uitvaltijd, en hoewel onze kandidaat schrijfmodi (direct, view source swap) de service-uitvaltijd van de taak isoleren van de berekeningstijd van de delta, is het altijd goed om optimalisaties in te bouwen waar mogelijk<\/STRONG>. De open data site van de stad ondersteunt CSV-download, en CSV is een performante indeling in ruimtelijke ETL-tools, dus dat is de helft van de delta-berekeningsstap. De andere helft is het lezen van de huidige staat van de feature service/view.<\/P>Hier is mijn optimalisatie voor het lezen van feature services, in LAChangeDetection.fmw<\/STRONG> (in de blog download):<\/P>
Direct Write After Change Detection<\/span><\/span><\/P>Hoewel het
Esri ArcGIS Connector<\/A>-pakket een feature service reader levert, heb ik in mijn zoektocht naar snelheid het lezen van de doelservice geïmplementeerd met meerdere gelijktijdige Query<\/A>-aanroepen via HTTP. Ik ontdekte dat het standaard maximum aantal records per oproep (2000<\/STRONG>) bij 4 gelijktijdige verzoeken<\/STRONG> optimale prestaties gaf, ongeveer het dubbele van het pakketgeleverde reader-tarief. De ChangeDetector<\/A>-transformer berekent de delta in seconden zodra hij de data heeft, daarna duurt het schrijven van de delta 3-4 seconden voor een typische dagelijkse wijzigingsset (als je de workspace inspecteert zie je dat ik hem heb uitgerust met Emailer-transformers die wat tijdstempelinformatie terugsturen).<\/P>Voor mensen die niet tevreden zijn met enkele seconden service-uitvaltijd, is het implementeren van view source swap slechts iets uitdagender, zie LAViewSourceSwap.fmw<\/STRONG> in de blog download:<\/P>
View Source Swapping<\/span><\/span><\/P>Je zult logica zien in de workspace om te schakelen tussen "A" en "B" services voor lezen, schrijven en bronwissel. Om deze reden worden wijzigingen iets anders gedetecteerd; dezelfde openbare URL die toegang geeft tot adresdata als CSV wordt gelezen, maar de delta wordt berekend ten opzichte van de gehoste feature layer die niet<\STRONG> de huidige bron is voor de gehoste feature layer view, en de delta wordt toegepast op die feature layer.<\P>Dan moet de bijgewerkte feature layer worden gewisseld om bron te zijn voor de feature layer view. Hoe? <\STRONG>
Het antwoord vereist wat speurwerk door te inspecteren hoe ArcGIS native view source swap afhandelt in iteminstellingen:<\P>
View Source Swap<\span>
Wat je hierboven ziet is dat ik handmatig een bronwissel uitvoer maar met actieve browserontwikkelaarstools, gefilterd op POST-transacties in grote verzoekrijweergave. Terwijl ik door de view source swap klikte zag ik dat het systeem twee oproepen gebruikt,
deleteFromDefinition en addToDefinition. Nog beter, als ik een POST-oproep inspecteer kan ik zien welke JSON-payload erin wordt gebruikt - wat geluk is want de REST API-documentatie is wat uitdagend voor iemand zonder codeerkennis zoals ik <<EMOJI_0>><\span>.
De deleteFromDefinition payload is triviaal , maar de addToDefinition JSON payload is enorm . Echter , omdat ik mijn services met standaardinstellingen heb gemaakt die ik niet wil wijzigen , heb ik JSON teruggebracht tot objecten die ik waard vond te behouden , en natuurlijk verwijzing naar gewenste bron . Hier is JSON :
{
"layers": [
{
"currentVersion": 11.5,
"id": 0,
"name": "LosAngelesAddresses",
"type": "Feature Layer",
"cacheMaxAge": 30,
"displayField": "Street_Name",
"description": "",
"copyrightText": "",
"defaultVisibility": true,
"adminLayerInfo": {
"viewLayerDefinition": {
"sourceServiceName": "@Value(_nextSourceName)",
"sourceLayerId": 0,
"sourceLayerFields": "*"
}
},
"geometryType": "esriGeometryPoint",
"objectIdField": "OBJECTID",
"uniqueIdField": {
"name": "OBJECTID",
"isSystemMaintained": true
},
"useStandardizedQueries": true,
"minScale": 0,
"maxScale": 0,
"extent": {
"xmin": -13210040.1828,
"ymin": 3989386.3054,
"xmax": -13153020.1132,
"ymax": 4073637.6182,
"spatialReference": {
"wkid": 102100,
"latestWkid": 3857
}
},
"spatialReference": {
"wkid": 102100,
"latestWkid": 3857
},
"globalIdField": "",
"maxRecordCount": 2000,
"standardMaxRecordCount": 32000,
"standardMaxRecordCountNoGeometry": 32000,
"tileMaxRecordCount": 8000,
"maxRecordCountFactor": 1,
"capabilities": "Query"
}
]
}In productie zou ik JSON kunnen bewerken om dingen aan te passen indien gewenst , zoals extent of display field , maar waarschijnlijk is het beter om je laagontwerp vooraf goed te krijgen .
Een belangrijk ding dat ik leerde over payload staat op regel 15 waar ik tijdens runtime een feature-attribuut injecteer in JSON , sourceServiceName is een eigenschap die sleutel geeft aan service die wordt gewisseld in , er is geen verwijzing naar item-ID of service-URL . In mijn geval wisselt sourceServiceName tussen 22LosAngelesAddressesA22 en 22LosAngelesAddressesB22 bij opeenvolgende runs . Als enige delta-transactie geen bewerkingen bevat dan geen service swap vindt plaats.<\/P>
Nu we zoveel mogelijk downtime uit een feature service update hebben geperst als we kunnen, is het aan jou om te bepalen of de delta-transactie van de gemiddelde periode groot genoeg is (duizenden features?) om de extra opslagkosten van view source swap en gegarandeerde minimale downtime te rechtvaardigen.<\/P>
Hoewel ik me hier richt op het minimaliseren van downtime, niet op de uitvoeringstijd voor de hele taak, duurt het voor degenen die nieuwsgierig zijn 3-5 minuten om de miljoen punten waarmee ik werk te verversen. Ik vermoed dat de variabiliteit komt door serverbelasting waar de data vandaan komt en naartoe gaat.<\/P>
Erkenningen:<\/STRONG> Ik werd geïnspireerd om deze post te schrijven door mijn Esri-collega @SashaLockamy<\/a> die deze workflow als eerste onderzocht, en aan wie ik dankbaar ben, en wat eerder werk in een gerelateerde workflow waarbij file geodatabases opnieuw worden gepubliceerd, zie de eerste presentatie hier<\/A>.<\/P>
