「ご相談があります」と相談して、これだけキッチリ答えてくれた上司や同僚は、今迄いなかったと思う

ご相談があります。

1,A1,30,33.59543503,130.3980676
2,A1,30,33.59525629,130.3993336
3,A1,30,33.59323656,130.3984967
4,A1,30,33.59261097,130.3963509
5,A1,30,33.59212837,130.3954712
6,A1,30,33.59243223,130.3971234
7,A1,30,733.5927897,130.3996554
1,A2,60,33.59398255,130.3959787
2,A2,60,33.59364294,130.3985965
3,A2,60,33.59328547,130.3976095
4,A2,60,33.59278499,130.3969657
5,A2,60,33.59265988,130.3953564
6,A2,60,33.59285649,130.4020941
1,A3,120,33.59401761,130.3947008
2,A3,120,33.59389249,130.3972542
3,A3,120,33.5928558,130.3972972
4,A3,120,33.5920336,130.3982198
5,A3,120,33.59205147,130.3995288
6,A3,120,33.5924447,130.3997862
7,A3,120,33.59274856,130.4001081

のように記載されたcsvファイルあります。 A1はカフェの位置座標、A2は飲食店の位置座標、A3は、居酒屋の位置座標、この他、B1からH2までの種類の店舗の位置座標のデータがあります。

一方現在、PostGISを使ったマルチエージェントシミュレーション(MAS)を作成しております。このMASは、帰路の駅に向う途中に気になる店舗があったら、その店舗に立ち因る、という動きをさせたいと思っています。

このMASのシミュレータはすでに完成しており、エージェントも稼動しておりますが、上記の「立ち寄り」のアルゴリズムはまだ実装しておりません。 各エージェントは、エージェント単位に嗜好を持っており、例えば、帰路の途中にカフェ(A1)を、自分の位置から半径15メートル以内に見つけらたら、そこに立ち寄らせたいと思っています。

でご相談なのですが、このような実装を行うに際して、上記のCSVファイルは、どのように利用するのが良いでしょうか。
(1)CSVファイルとして全てを纒めておき、シミュレータ開始前に全部をメモリ上に格納しておき、A1(カフェ)とエージェントの距離が15メートル以内にはいったか否かを随時計算する
(2)CSVファイルをPostgresSQLのDBに格納しておき、上記と同じ処理を行う。
(3)その他

観点は、「計算時間または計算負荷ができるだけ軽量に行える」ということになります。エージェントは1000～10000作って動かすので、時間がかかるのは困るのです。本件についてアドバイスを頂けますようお願いします。

計算負荷を軽減し、効率的にエージェントの「立ち寄り」アルゴリズムを実装するためには、以下のアプローチが考えられます。

アプローチの比較

(1) CSVファイルをすべてメモリにロードして距離計算

メリット:

  • 実装がシンプル。
  • 外部データベースに依存しないため、環境構築が容易。

デメリット:

  • メモリ消費が大きい。特に店舗データが増えると、メモリ上で全てを保持するのが困難になる場合がある。
  • エージェントが増えた場合、すべての店舗との距離を計算する処理が重くなる可能性が高い。

適用場面:

  • 店舗データが少ない場合や、エージェント数が少ない場合に有効。

(2) PostgreSQL + PostGIS を利用する

メリット:

  • PostGIS の空間インデックス機能を使うことで、店舗検索の計算負荷が大幅に軽減される。
    • ST_DWithin を用いることで、指定距離内の店舗を効率よく取得可能。
  • データの永続性が高く、今後店舗データを増やしたり更新する場合の対応が容易。
  • 複雑なクエリが実行可能で、たとえばカテゴリ別の店舗をエージェントの嗜好に基づいてフィルタリングできる。

デメリット:

  • 初期設定やクエリのチューニングに多少の手間がかかる。
  • 外部データベースへのアクセスによる若干のオーバーヘッド。

適用場面:

  • 店舗データやエージェント数が多い場合。
  • データの拡張性やメンテナンス性を重視する場合。

(3) その他の選択肢: ハイブリッド方式

方法:

  • CSVデータをシミュレータ起動時にPostGISにロードし、シミュレーション中はPostGISを利用する。
  • シミュレーション後に、必要に応じて結果を再度CSVや他の形式にエクスポート。

メリット:

  • PostGISの性能を活用しつつ、データ管理はCSVベースでシンプルに保てる。
  • データがPostGISにあるため、他の分析ツールやダッシュボードにも容易に接続可能。

デメリット:

  • CSVのロード処理が必要。
  • PostGISの初期設定が求められる。

推奨アプローチ

(2) PostgreSQL + PostGIS の利用を推奨します。
以下の理由によります：

  1. 計算負荷の軽減: PostGISの空間インデックスを利用することで、エージェントと店舗の距離計算が効率化されます。
  2. 柔軟性: 店舗データが拡張されても問題なく対応可能。
  3. スケーラビリティ: エージェント数が増加しても処理時間を抑えることが可能。

実装例: PostGISでの距離計算

  1. CSVデータをPostGISに格納する
    CREATE TABLE stores ( id SERIAL PRIMARY KEY, type VARCHAR(10), preference INT, geom GEOMETRY(POINT, 4326) ); COPY stores(type, preference, geom) FROM 'path/to/stores.csv' WITH (FORMAT CSV, DELIMITER ',', HEADER TRUE, GEOMETRY 'POINT(longitude latitude)');

     

  2. 距離計算クエリ
    エージェントの位置 (33.595, 130.398) を例とします:

    SELECT id, type, preference, ST_Distance(geom, ST_MakePoint(130.398, 33.595)::geography) AS distance FROM stores WHERE ST_DWithin(geom::geography, ST_MakePoint(130.398, 33.595)::geography, 15);

     

  3. エージェントの嗜好を反映したクエリ
    SELECT id, type, preference, distance FROM ( SELECT id, type, preference, ST_Distance(geom, ST_MakePoint(130.398, 33.595)::geography) AS distance FROM stores WHERE type = 'A1' AND ST_DWithin(geom::geography, ST_MakePoint(130.398, 33.595)::geography, 15) ) sub WHERE preference = 1; -- エージェント嗜好がカフェ(A1)の場合

     

システム構成例

  1. PostGISをバックエンドとしたシミュレータ
    • シミュレーション開始時にPostGISへ接続。
    • 各エージェントが特定の地点を通過するたびに、クエリで立ち寄り候補店舗を取得。
  2. CSV管理を維持したデータフロー
    • 必要に応じてPostGISのデータをCSVにエクスポート。
    • シミュレータ結果を再度CSV形式で保存可能。

これらを基に、システム全体の効率化を図ることをお勧めします。

 

未分類

Posted by ebata