Die Antwort ist beides für mich, aber Sie sind der Richter für Ihre Situation! Lesen Sie weiter für die Entscheidungskriterien...
Wenn Sie einen großen gehosteten Feature-Service aus externen Daten pflegen möchten, ist es bewährte Praxis, vollständige Überschreibungen bei jeder Aktualisierung zu vermeiden, aus zwei Gründen:
- Große Schreibtransaktionen können anfällig sein
- Große Schreibtransaktionen können erhebliche Ausfallzeiten des Dienstes verursachen
Um beide Probleme zu vermeiden, ist es vorzuziehen, einen CDC (Change Data Capture)-Ansatz zu implementieren und nur Deltas in den Ziel-Feature-Service zu schreiben. Dieser Blog beschreibt zwei Möglichkeiten, dies zu tun:
- Deltas direkt in den Ziel-Feature-Service schreiben
- Eine gehostete Feature-Layer-Ansicht pflegen, die abwechselnd auf zwei Dienste zeigt
- Delta-Transaktionen in den Dienst schreiben, der nicht aktuell die Quelle ist, und dann umschalten, damit er die Ansichtquelle wird
In der üblichen Situation, in der ein Perioden-Delta ein kleiner Bruchteil der Daten ist, kann ein direktes Delta-Schreiben mehrere Sekunden dauern, während beim Umschalten der Ansichtquelle die Ausfallzeit Millisekunden betragen kann, aber doppelt so hohe Speicherkosten verursacht. Wir machen ein Beispiel durch, damit Sie zwischen den Ansätzen wählen können, aber so oder so sind Sie der Gewinner mit CDC!
Hier sind meine Fachbereichsdaten, etwa eine Million Straßen-Adresspunkte in Los Angeles, Kalifornien, die täglich gepflegt werden:
Los Angeles Address Points
Die Aufgabe besteht darin, die tägliche Delta-Transaktion (typischerweise einige hundert Features) mit geringer Ausfallzeit zu berechnen und anzuwenden. Während unsere Kandidaten-Schreibmodi (direkt, Ansichtquellen-Umschaltung) die Ausfallzeit des Dienstes von der Berechnungszeit des Deltas isolieren, ist es immer gut, alle Optimierungen einzubauen, die Sie können. Die Open-Data-Seite der Stadt unterstützt CSV-Download, und CSV ist ein leistungsfähiges Format in spatialen ETL-Werkzeugen, daher ist das die Hälfte des Delta-Berechnungsschritts. Die andere Hälfte besteht darin, den aktuellen Zustand des Feature-Service/der Ansicht zu lesen.
Hier ist meine Optimierung für das Lesen des Feature-Service in LAChangeDetection.fmw (im Blog-Download):
Direct Write After Change Detection
Während das Esri ArcGIS Connector-Paket einen Feature-Service-Leser bereitstellt, habe ich im Streben nach Geschwindigkeit das Lesen des Ziel-Dienstes mit mehreren gleichzeitigen Query-Aufrufen über HTTP implementiert. Ich stellte fest, dass die standardmäßige maximale Datensatzanzahl pro Aufruf (2000) bei 4 gleichzeitigen Anfragen optimale Leistung brachte, ungefähr doppelt so schnell wie der paketierte Leser. Der ChangeDetector-Transformer berechnet das Delta in Sekunden sobald er die Daten hat; das Schreiben des Deltas dauert 3–4 Sekunden für einen typischen täglichen Änderungsdatensatz (wenn Sie den Workspace inspizieren, sehen Sie, dass ich ihn mit Emailer-Transformern instrumentiert habe, um mit Zeitstempelinformationen Rückmeldung zu geben).
Für Personen, die mit einigen Sekunden Ausfallzeit nicht zufrieden sind, ist die Implementierung der Ansichtquellen-Umschaltung nur geringfügig anspruchsvoller. Siehe LAViewSourceSwap.fmw im Blog-Download:
View Source Swapping
Sie sehen Logik im Workspace zum Umschalten zwischen den Diensten "A" und "B“ für Lesen, Schreiben und Quellenumschaltung. Aus diesem Grund werden Änderungen etwas anders erkannt; dieselbe öffentliche URL zum Zugriff auf die Adressdaten als CSV wird gelesen, aber das Delta wird gegenüber dem gehosteten Feature-Layer berechnet, der nicht die aktuelle Quelle für die gehostete Feature-Layer-Ansicht ist und das Delta wird auf diesen Feature-Layer angewendet.
Anschließend muss der aktualisierte Feature-Layer als Quelle für die Feature-Layer-Ansicht umgeschaltet werden. Wie?
Die Antwort erfordert Detektivarbeit durch Inspektion, wie ArcGIS nativ die Ansichtquellen-Umschaltung in den Element-Einstellungen handhabt:
View Source Swap
Was Sie oben sehen, bin ich beim manuellen Durchführen einer Quellenumschaltung mit aktiven Browser-Entwicklertools, gefiltert auf POST-Transaktionen in großer Anforderungszeilenansicht. Während ich durch die Ansichtquellen-Umschaltung klickte, konnte ich sehen, dass das System zwei Aufrufe verwendet: deleteFromDefinition und addToDefinition. Noch besser: Wenn ich einen POST-Aufruf inspiziere, sehe ich die JSON-Nutzlast darin – was Glück ist, da die REST API-Dokumentation für eine No-Code-Person wie mich etwas herausfordernd ist 😉.
Die deleteFromDefinition-Nutzlast ist trivial, aber die addToDefinition JSON-Nutzlast ist riesig. Da ich meine Dienste mit Standardeinstellungen erstellt habe und keine Änderungen vornehmen möchte, habe ich das JSON auf Objekte reduziert, von denen ich dachte, dass sie es wert sind beizubehalten – und natürlich den erforderlichen Verweis auf die gewünschte Quelle. Hier ist das 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 der Produktion könnte ich das JSON bearbeiten um Dinge wie Extent oder Anzeige-Feld anzupassen, aber es ist wahrscheinlich eine bessere Investition, Ihr Layer-Design vorher richtig zu gestalten.
Eines habe ich über die Nutzlast gelernt: In Zeile 15 injiziere ich zur Laufzeit ein Feature-Attribut ins JSON. sourceServiceName ist eine Eigenschaft, die den Dienst angibt, der gerade dazugeschaltet wird; es gibt keinen Verweis auf seine Element-ID oder seine Service-URL. In meinem Fall wechselt der Quellservice-Name bei aufeinanderfolgenden Läufen zwischen „LosAngelesAddressesA“ und „LosAngelesAddressesB“. Wenn eine Delta-Transaktion keine Bearbeitungen enthält dann kein Service Tausch erfolgt.<\/P>
Jetzt, da wir so viel Ausfallzeit wie möglich aus einem Feature-Service-Update herausgeholt haben, liegt es an Ihnen zu entscheiden, ob die durchschnittliche Delta-Transaktion des Zeitraums groß genug ist (viele Tausend Features?), um die zusätzlichen Speicherkosten für den View Source Swap und die garantierte minimale Ausfallzeit zu rechtfertigen.<\/P>
Während ich mich hier auf die Minimierung der Ausfallzeit konzentriere und nicht auf die Laufzeit des gesamten Jobs, dauert es bei Interesse 3-5 Minuten, um die Million Punkte, mit denen ich arbeite, zu aktualisieren. Ich vermute, die Variabilität kommt von den Serverlastbedingungen, von wo die Daten kommen und wohin sie gehen.<\/P>
Danksagungen:<\/STRONG> Ich wurde inspiriert, diesen Beitrag von meinem Esri-Kollegen @SashaLockamy<\/a> zu schreiben, der diesen Workflow zuerst erforscht hat und dem ich dankbar bin, sowie von einigen früheren Arbeiten in einem verwandten Workflow, bei dem File Geodatabases neu veröffentlicht werden. Siehe die erste Präsentation hier<\/A>.<\/P>
