Změnit Detekci nebo Přepnout Zobrazení Zdrojového Kódu? Vítězem je....

bharold

Odpověď je obojího typu pro mě, ale vy buďte soudcem ve své situaci!  Čtěte dále pro kritéria rozhodnutí...<\/P>

Pokud chcete udržovat velkou hostovanou feature službu z externích dat, je nejlepší praxí vyhnout se úplným přepisům při každé aktualizaci, ze dvou důvodů:<\/P>

1. Velké zápisové transakce mohou být křehké<\/LI>
2. Velké zápisové transakce mohou způsobit významné výpadky služby<\/LI><\/OL>

   Abychom se vyhnuli oběma problémům, je vhodnější implementovat přístup CDC<\/A> (change data capture) a zapisovat pouze delty do cílové feature služby.  Tento blog popíše dva způsoby, jak to udělat:<\/P>

   1. Zápis delt přímo do cílové feature služby<\/LI>
   2. Udržovat
   hostovaný pohled na feature vrstvu<\/A> s tím, že ho střídavě nasměrujete na dvě služby
   • Zapisovat delta transakce do služby která není<\/STRONG> právě zdrojem, pak ji
   vyměnit<\/A>, aby byla<\/STRONG> zdrojem pohledu<\/LI><\/UL><\/LI><\/OL>V běžné situaci, kdy je periodická delta malým zlomkem dat, může přímý zápis delt trvat několik sekund, zatímco u výměny zdroje pohledu může být výpadek v milisekundách, ale má dvojnásobné náklady na úložiště.<\/EM>  Uděláme si praktický příklad, abyste si mohli vybrat mezi přístupy, ale tak či tak jste vítězem používáním CDC!<\/STRONG><\/P>Zde jsou moje data z dané oblasti, asi milion bodů adres ulic v Los Angeles<\/A>, Kalifornie, udržovaných denně:<\/P>

   Los Angeles Address Points<\/span><\/span><\/P>Úkolem je vypočítat a aplikovat denní delta transakci (typicky nízké stovky prvků) s nízkým výpadkem a zatímco naše kandidátní režimy zápisu (přímý, výměna zdroje pohledu) izolují výpadek služby úlohy od času výpočtu delty, je vždy dobré zabudovat jakékoli optimalizace, které můžete<\/STRONG>. Městský otevřený datový portál podporuje stažení CSV a CSV je výkonný formát v prostorových ETL nástrojích, takže to je polovina kroku výpočtu delty.  Druhá polovina je čtení aktuálního stavu feature služby\u002Fpohledu.<\/P>Zde je moje optimalizace pro čtení feature služby v LAChangeDetection.fmw<\/STRONG> (v downloadu blogu):<\/P>Direct Write After Change Detection<\/span><\/span><\/P>Zatímco balíček

   Esri ArcGIS Connector<\/A> poskytuje čtečku feature služby, v honbě za rychlostí jsem implementoval čtení cílové služby pomocí více současných Query<\/A> volání přes HTTP.  Zjistil jsem, že výchozí maximální počet záznamů na volání (2000<\/STRONG>) ve 4 současných požadavcích<\/STRONG> poskytuje optimální výkon, přibližně dvojnásobek rychlosti zabalené čtečky.  Transformátor ChangeDetector<\/A> vypočítá deltu během sekund poté, co má data, pak zápis delty trvá 3-4 sekundy pro typickou denní změnu (pokud si prohlédnete workspace, uvidíte, že jsem ho vybavil transformátory Emailer pro zasílání časových údajů).<\/P>

   Pro lidi nespokojené s několika sekundami výpadku služby je implementace výměny zdroje pohledu jen o něco složitější, viz LAViewSourceSwap.fmw<\/STRONG> v downloadu blogu:<\/P>View Source Swapping<\/span><\/span><\/P>V workspace uvidíte logiku pro přepínání mezi službami "A" a "B" pro čtení, zápis a výměnu zdroje.  Z tohoto důvodu jsou změny detekovány trochu jinak; stejná veřejná URL adresa přistupující k adresním datům jako CSV je čtena, ale delta se počítá vůči hostované feature vrstvě, která není<\\/STRONG> aktuálním zdrojem hostovaného pohledu feature vrstvy a delta se aplikuje na tuto feature vrstvu.<\\/P><\\/P>A pak musí být aktualizovaná feature vrstva vyměněna tak, aby byla zdrojem pro pohled feature vrstvy.  Jak?<\\/STRONG><\\/P><\\/P>Přesná odpověď vyžaduje trochu detektivní práce při zkoumání toho, jak ArcGIS nativně zpracovává výměnu zdroje pohledu v nastavení položky:<\\/P><\\/P>View Source Swap<\\/span><\\/span><\\/P>Pohledíte-li na obrázek nahoře, vidíte mě ručně provádět výměnu zdroje s aktivními nástroji pro vývojáře prohlížeče filtrovanými na zaznamenávání POST transakcí ve velkém zobrazení řádků požadavků.  Při klikání přes výměnu zdroje pohledu jsem viděl systém používat dva volání,

   deleteFromDefinition<\\/A> a addToDefinition<\\/A>.  Ještě lépe, pokud si prohlédnu jakékoli POST volání, mohu vidět JSON payload použitý v něm - což je štěstí, protože dokumentace REST API je trochu náročná pro člověka bez kódování jako jsem já 😉<\\/span>.<\\/P>Položka deleteFromDefinition payload je triviální, ale JSON payload addToDefinition je obrovský.  Nicméně protože jsem své služby vytvořil s výchozími nastaveními bez plánovaných změn, zkrátil jsem JSON na objekty považované za důležité a samozřejmě požadovaný ukazatel na požadovaný zdroj.  Zde je JSON:<\\/P>{
\u0022layers\u0022: [
{
\u0022currentVersion\u0022: 11.5,
\u0022id\u0022: 0,
\u0022name\u0022: \u0022LosAngelesAddresses\u0022,
\u0022type\u0022: \u0022Feature Layer\u0022,
\u0022cacheMaxAge\u0022: 30,
\u0022displayField\u0022: \u0022Street_Name\u0022,
\u0022description\u0022: \u0022\u0022,
\u0022copyrightText\u0022: \u0022\u0022,
\u0022defaultVisibility\u0022: true,
\u0022adminLayerInfo\u0022: {
\u0022viewLayerDefinition\u0022: {
\u0022sourceServiceName\u0022: \u0040Value(_nextSourceName),
\u0022sourceLayerId\u0022: 0,
\u0022sourceLayerFields\u0022: \u0022*\u0022
}
},
\u0022geometryType\u0022: \u0022esriGeometryPoint\u0022,
\u0022objectIdField\u0022: \u0022OBJECTID\u0022,
\u0022uniqueIdField\u0022: {
\u0022name\u0022: \u0022OBJECTID\u0022,
\u0022isSystemMaintained\u0022: true
},
\u0022useStandardizedQueries\u0022: true,
\u0022minScale\u0022: 0,
\u0022maxScale\u0022: 0,
\u0022extent\u0022: {
\u0022xmin\u0022: -13210040.1828,
\u0022ymin\u0022: 3989386.3054,
\u0022xmax\u0022: -13153020.1132,
\u0022ymax\u0022: 4073637.6182,
\u0022spatialReference\u0022: {
\u0022wkid\u0022: 102100,
\u0022latestWkid\u0022: 3857
}
},
\u0022spatialReference\u0022: {
\u0022wkid\u0022: 102100,
\u0022latestWkid\u0022: 3857
},
\u0022globalIdField\u0022: \ufffd,
\ufffdmaxRecordCount 2000,
"standardMaxRecordCount": 32000,
"standardMaxRecordCountNoGeometry": 32000,
"tileMaxRecordCount": 8000,
"maxRecordCountFactor": 1,
"capabilities": "Query"
}
]
}<\\/code><\\/pre>Ve výrobním prostředí bych mohl JSON upravit podle potřeby například rozsah nebo zobrazované pole, ale pravděpodobně je lepší investovat do správného návrhu vrstvy předem.<\\/P>Jedna klíčová věc o payload jsem se naučil na řádku 15 kde injektuji atribut prvku do JSON za běhu, sourceServiceName<\\/STRONG> je vlastnost určující službu která se právě mění dovnitř<\\/STRONG>, neexistuje žádná reference na její ID položky nebo URL služby.  V mém případě se název zdrojové služby střídá mezi "LosAngelesAddressesA" a "LosAngelesAddressesB" při po sobě jdoucích bězích.  Pokud žádná delta transakce neobsahuje úpravy pak žádná služba swap nastane.<\/P>Takže nyní, když jsme vytěžili co nejvíce času bez výpadku z aktualizace feature služby, je na vás, zda je delta transakce za průměrné období dostatečně velká (několik tisíc prvků?), aby ospravedlnila dodatečné náklady na úložiště kvůli přepnutí zdroje pohledu a zaručenému minimálnímu výpadku.<\/P>Zatímco se zde zaměřuji na minimalizaci výpadku, nikoli na dobu běhu celého úkolu, pokud je někdo zvědavý, trvá obnovení milionu bodů, se kterými pracuji, 3-5 minut.  Předpokládám, že variabilita pochází z podmínek zatížení serveru, odkud data přicházejí a kam jdou.<\/P>Poděkování:<\/STRONG>  Byl jsem inspirován k napsání tohoto příspěvku mým kolegou z Esri @SashaLockamy<\/a> , který jako první prozkoumal tento pracovní postup, a kterému jsem vděčný, a také některé předchozí práce v souvisejícím pracovním postupu, kde jsou file geodatabases znovu publikovány, viz první prezentace zde<\/A>.<\/P>

bharold

Hello everyone.  If you downloaded the blog attachment with workspace source files before 5:45 am PDT Friday 3rd October then please do so again, I simplified the LAViewSourceSwap.fmw workspace to remove unnecessary parameters which were artifacts of development testing.