Atlas のコマンドデータ同期

データレイヤーを使用する

MongoDB Enterprise Advanced をアプリケーションの信頼できるデータレイヤーとして使用します。オペレーション エンティティをBSONドキュメントとして保存し、運用ワークフローに一致するコレクションに整理します。 MongoDB は、同じデータベース内のさまざまなドキュメントシェイプ をサポートしています。位置データ、マップ オブジェクト、チャット メッセージ、アラート、およびファイルを 1 つの固定スキーマに強制せずに保存します。

この柔軟なドキュメントモデルを活用して、すべてのアプリケーション機能を 1 つのデータプラットフォーム上で構築できます。 MongoDBを使用して、ダッシュボード、API、コマンド ワークフロー、下流システムを提供します。データベース全体を再設計せずに新しい権限エンティティを追加します 。

MongoDBへの Edge 接続

エッジ同期プラットフォームである Disto を エッジ同期提携するとして使用します。 GitHub プラグインは、 ATK デバイスをローカル最初のピア間キャッシュに接続します。 Atlas は、ロケーション、マップ、チャット、組織データを共有するためのフィールドアプリケーションを構成します。ネットワーク アクセスが変更された場合、または失敗した場合に、近くのデバイス間でナビゲーション データを同期します。

次に、Disto MongoDB Connector を使用して Disto をMongoDBに接続します。 コネクタは、Disto とMongoDB間でドキュメントを同期し、2 つのシステム間で同時に実行された変更を解決します。

データに基づく構築

コマンド センターでローカルにMongoDB Enterprise Advanced を実行します。 MongoDBデータレイヤーを使用して、コマンドセンター ダッシュボードやその他の目的のアプリケーションを構築します。データ レイヤーとアクセス レイヤーを配置することで、ストレージと同期サービスを個別に構築するのではなく、アプリケーションの機能に焦点を当てます。

このパターンを使用して次の操作を行います。

• さまざまな目的データをドキュメントとして保存します。

• 標準のドライバーと API を使用してアプリケーションをMongoDBに接続します。

• 切断された同期には Disto と統合します。

• 1 つの共有データレイヤーをコマンドセンターのアプリケーションに公開します。

• 新しいオペレーション ワークフローが発生したときに、アプリケーションを拡張します。

タグの変更

ターゲット エッジは、フィールドデバイスがアクションデータの作成および交換するレイヤーであり、接続が変更または失敗する可能性がある点で操作されているユーザーとデバイスを含みます。

Atlas は、ロケーション、マップ、チャット、組織データを共有するためのフィールドアプリケーションを提供します。 GitHub プラグインはそのデータをキャプチャし、ピア間キャッシュを介して近くのデバイス全体で同期します。 GitHub は、CPU と . の両方の利用可能なトランスポートを使用します。 Disto は、キャッシュ内の複数のデバイス間でデータを中継することもできます。

エッジは、アプリケーションデータの別のソースとして機能します。 Disto はそのデータを利用可能な状態に保持し、デバイス間で移動します。 MongoDB は同期されたドキュメントを保存し、コマンドセンターのアプリケーションで使用できるようにします。

コマンドセンター統合

MongoDB Enterprise Advanced は、中央アプリケーションデータレイヤーを提供します。ダッシュボードはMongoDBからオペレーション データを読み取り、マップ、ノード ステータス ビュー、通信フィードを通じて表示します。

Disto MongoDB Connector は、Disto とMongoDBの変更をリッスンします。これらの変更をもう 1 つのシステムに適用し、2 つのデータ ストアを整合性のある状態に維持します。

MongoDBで構築されたアプリケーションは、Atlas デバイスに直接接続せずに、メッセージ ドキュメントのクエリと更新を行います。 Disto は、切断された エッジ デバイス との間の配信を処理します。この統合により、Atlas デバイスに対して直接コマンドセンター アプリケーションを構築するのではなく、 MongoDBに対してコマンドセンターアプリケーションを構築できます。

この設計が回復力がある理由

MongoDB はoperation データを保存します。 Disto はフィールドデバイスを同期させます。 Atlas は、フィールドアプリケーションを提供します。 コネクタ は両方の環境をリンクし、同時変更を解決します。

これにより、各分離は 1 つの責任に集中できます。 MongoDB はアプリケーションデータレイヤーを提供し、Ditty はコマンドライン エッジ全体でデータを同期し、ATK はフィールドエクスペリエンスを提供します。

この設計により、デバイスやネットワーク条件ごとに個別のストレージモデルを実装することなく、MongoDB のドキュメントモデルに対してアプリケーション機能を構築できます。

コレクションに位置データを保存するtrack

フィールドアクター からの位置データとステータス データには、trackコレクションを使用します。これらのドキュメントをクエリして、コマンドセンター マップに現在のデバイスと古いデバイスを表示します。

{
   "_id": "ANDROID-4486046569cda611", // document identifier
   "_r": false,                       // soft-delete flag
   "c": "MDB Actor 2",                // display name
   "d": "ANDROID-4486046569cda611",   // source device
   "e": "MDB Actor 2",                // actor callsign
   "j": 19.451227,                    // latitude
   "l": -99.139832,                   // longitude
   "o": 1776886448640,                // stale time
   "w": "a-f-G-U-C"                   // CoT type
}

圧縮されたスキーマは、同期されたドキュメントを ATK によって生成されたデータに近いものに保持します。 MongoDB、別の リレーショナル マッピングレイヤーを必要とせずにドキュメントが保存されます。

コレクションにメッセージを保存するchat

フィールドユーザーとコマンド ワークフロー間で交換されるメッセージには、chatコレクションを使用します。コレクションは、メッセージテキスト、送信者、部屋、タイムスタンプのフィールドを持つ、追跡とは異なるシェイプを使用します。

{
   "_id": "b547f0b4-c371-4aff-ac1d-3bafe110a9e1", // message identifier
   "_r": false,                                   // soft-delete flag
   "authorType": "a-f-G-U-C",                     // sender CoT type
   "b": 1776735193948,                            // message timestamp
   "d": "COMMAND-VEHICLE",                        // source device
   "e": "COMMAND",                                // sender callsign
   "msg": "Command",                              // message text
   "room": "Ditto",                               // room name
   "roomId": "ChatContact-Ditto"                  // room identifier
}

MongoDB、空のロケーション フィールドを追加したり、両方のエンティティを同じ構造に強制したりすることなく、アプリケーションはtrack ドキュメントと並行してメッセージ ドキュメントを保存できます。

マップ オブジェクトをmapitem コレクションに保持する

永続的なマップ グラフィックと共有組織オブジェクトには、mapitemコレクションを使用します。

MongoDB のドキュメントモデルを使用して、アプリケーションに必要な形状で各オペレーション エンティティを保存します。 track、mapitem、chat は異なるデータとアクセス パターンを表すため、別々のコレクションに保存します。このアプローチでは、すべてのオペレーション データを 1 つの固定的なスキーマに強制せずに、マップ、ステータス、通信機能を構築できます。

1 つのコミット関数に各コレクションを使用し、すべてのコレクションを 1 つのMongoDBデータレイヤーに保持します。既存のコレクションを再設計せずに、フィールドまたは新しいタスク エンティティを追加します。

1 つの柔軟なデータレイヤーに対するビルド

MongoDBに対してダッシュボード、API、コマンドセンターのワークフローをビルドします。各コレクションの目的に従ってクエリを実行し、 エッジから受け取ったドキュメント構造を保持します。

このアプローチを使用して、次の操作を行います。

• Disto とMongoDB間のデータ変換を削減します。

• 各オペレーション エンティティを簡単にクエリできるようにしてください。

• 関連のないドキュメントを再設計せずに新しいフィールドを追加します。

• すべてのデバイスやワークフローに対して個別のストレージモデルを作成せずに、アプリケーションを拡張します。