答えは私にとっては両方ですが、あなたの状況に応じて判断してください！ 続きを読んで決定基準を確認してください...
外部データから大規模なホストされたフィーチャ サービスを維持したい場合、2つの理由から各リフレッシュ時に完全な上書きを避けることがベストプラクティスです：
- 大規模な書き込みトランザクションは脆弱になり得る
- 大規模な書き込みトランザクションはサービスのダウンタイムが大きくなる可能性がある
これら両方の問題を回避するために、CDC（変更データキャプチャ）アプローチを実装し、ターゲット フィーチャ サービスにデルタのみを書き込むことが望ましいです。 このブログではこれを行う2つの方法を説明します：
- デルタを直接ターゲット フィーチャ サービスに書き込む
- ホストされたフィーチャ レイヤ ビューを維持し、それを交互に2つのサービスにポイントする
- 現在ソースではないサービスにデルタ トランザクションを書き込み、その後スワップしてビュー ソースにする
通常、期間デルタがデータのごく一部である場合、直接デルタ書き込みは数秒かかることがありますが、ビュー ソース スワップの場合はダウンタイムがミリ秒単位で済みます。ただしストレージコストは2倍になります。 どちらの方法でもCDCを使うことで勝者になれますので、例を使って選択できるようにします！
ここに私の対象データがあります。カリフォルニア州ロサンゼルスの約100万件の住所ポイントで、毎日メンテナンスされています：
Los Angeles Address Points
仕事は、低ダウンタイムで日次デルタ トランザクション（通常数百フィーチャ）を計算して適用することです。候補となる書き込みモード（直接書き込み、ビュー ソース スワップ）はジョブのサービス ダウンタイムをデルタ計算時間から隔離しますが、可能な限り最適化を組み込むことは常に良いことです。市のオープンデータサイトはCSVダウンロードをサポートしており、CSVは空間ETLツールでパフォーマンスの良い形式なので、それがデルタ計算ステップの半分です。もう半分はフィーチャ サービス／ビューの現在状態を読み取ることです。
フィーチャ サービス読み取りの最適化はこちらです。ブログダウンロード内のLAChangeDetection.fmw：
Direct Write After Change Detection
Esri ArcGIS Connectorパッケージはフィーチャ サービス リーダーを提供しますが、高速化を目指して複数同時HTTPによるQuery呼び出しでターゲット サービス読み取りを実装しました。デフォルト最大レコード数（2000）で4同時リクエストが最適なパフォーマンスで、パッケージリーダーのおよそ2倍でした。ChangeDetectorトランスフォーマーはデータ取得後数秒でデルタ計算し、その後典型的な日次変更セットで3～4秒かけてデルタを書き込みます（ワークスペースにはEmailerトランスフォーマーでタイムスタンプ情報送信も組み込んでいます）。
数秒のサービス ダウンタイムでは満足できない方には、ビュー ソース スワップ実装もわずかに難しいだけです。ブログダウンロード内のLAViewSourceSwap.fmwをご覧ください：
View Source Swapping
ワークスペースには「A」と「B」サービス間で読み取り・書き込み・ソース スワップを切り替えるロジックがあります。そのため変更検出も少し異なります。同じ公開URLからCSVとして住所データを読みますが、デルタ計算はホストされたフィーチャ レイヤ ビューの現在ソースではないホスト フィーチャ レイヤと比較し、そのレイヤにデルタを書き込みます。
そして更新されたフィーチャ レイヤをフィーチャ レイヤ ビューのソースとしてスワップする必要があります。どうやって？
答えは調査作業が必要で、ArcGISがアイテム設定内でビュー ソース スワップをネイティブにどのように処理しているか調べました：
View Source Swap
上記は私が手動でソース スワップ操作中にブラウザ開発者ツールを有効にし、大きなリクエスト行ビューでPOSTトランザクションのみ記録したものです。ビュー ソース スワップ操作中にシステムが2つの呼び出しdeleteFromDefinitionとaddToDefinitionを使っていることがわかりました。さらに良いことに、任意のPOST呼び出しのJSONペイロードも確認できました。REST APIドキュメントは私のようなノーコードユーザーには少し難しいので幸運でした 😉.
deleteFromDefinitionペイロードは簡単ですが、addToDefinition JSONペイロードは巨大です。ただし私はサービスをデフォルト設定で作成したため変更予定はなく、保持すべきと思われるオブジェクトだけJSONから切り出し、もちろん目的ソースへのポインターも含めました。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"
}
]
}本番環境では必要ならJSON編集で範囲や表示フィールドなど調整できますが、おそらく事前にレイヤ設計を正しく行う方が良い投資でしょう。
ペイロードについて学んだ重要な点は15行目付近で、実行時にフィーチャ属性として注入するsourceServiceNameプロパティはスワップされるサービス自体をキー付けしており、そのアイテムIDやサービスURLへの参照はありません。私の場合、このソース サービス名は連続実行ごとに「LosAngelesAddressesA」と「LosAngelesAddressesB」を切り替えています。もしデルタ トランザクションに編集が含まれていなければサービス スワップが発生します。<\/P>
これで、フィーチャ サービスの更新からダウンタイムをできるだけ絞り出しました。平均期間のデルタ トランザクションが十分に大きいかどうか（数千のフィーチャ？）は、ビュー ソース スワップと保証された最小ダウンタイムの追加ストレージ コストを正当化するかどうかはあなた次第です。<\/P>
ここではダウンタイムの最小化に焦点を当てていますが、ジョブ全体の実行時間について興味がある方のために言うと、私が扱っている100万ポイントのリフレッシュには3～5分かかっています。データの送受信元のサーバー負荷状況によって変動しているのだと思います。<\/P>
謝辞:<\/STRONG> この投稿を書くきっかけとなったのは、Esri の同僚@SashaLockamy<\/a>で、彼が最初にこのワークフローを探求し、感謝しています。また、ファイル ジオデータベースが再公開される関連ワークフローにおける先行事例もあり、最初のプレゼンテーションはこちら<\/A>をご覧ください。<\/P>
