web-dev-qa-db-ja.com

Googleマップに100〜200Kのマーカーを読み込んでいます

現在、地図上にマーカーを描画するためにGoogle Maps v.3 APIを使用しています。マーカーは合計で約500個あります。

表示するために、ブラウザのクライアント側でこのツールを使用して、markerClusterおよびグループマーカーを使用します。

ただし、ロケーション数を拡大する予定であり、100Kまたは200Kまで急速に拡大する可能性があると想定しています。

私はいくつかのストレステストを行いましたが、現在のソリューションは基本的にブラウザーと約10〜20Kのマーカーを殺すことに気づきました。

だから私の質問は、その多くのマーカーを描画するための最良のアプローチは何ですか(Googleマップは必要ありません)?

私は同様の質問のある投稿を読みました、例えば:

Googleマップに多くのマーカーを表示

Googleマップのピンが多すぎる場合の最良の解決策

基本的に、人々は私がすでに使用している表示目的のためにいくつかのクラスタリングを使用することを提案します。

または、データを取得するためにフュージョンテーブルを使用することもできますが、これはオプションです。データがサーバーに残っている必要があるためです。また、フュージョンテーブルでは表示機能が制限されていると思います。

次のシナリオを実装することを考えています:

  • すべてのページでズーム/ロード-表示ビューの境界を含むajaxリクエストを送信し、すべての側面に約30%を追加し、この地理領域のみに該当するマーカーを取得します。ユーザーがズームアウトした場合に30%が追加され、他のマーカーをすばやく表示して、残りの部分をバックグラウンドでさらに取得できます(より広い領域)

  • マーカーの数が50を超える場合は、表示のためにクラスタリングを適用する予定です。しかし、JavaScriptのmarkerClusterは非常に遅い、つまり、markerClusterではなくgoogle自体なので、すべてのマーカーの位置を引き続き適用するため、表示されたマップの境界を約15 * 15グリッドに分割して、サーバー側でクラスタリングを行う予定です。マーカーを特定のセルにドロップし、基本的には内部に多数のマーカーを含むクライアントクラスターに送信します(ヒートマップの場合など)。そして、クラスターをマーカーとして表示します。

同様のことをした人に洞察を与えてください。それは一般的に理にかなっていますか。それとも、マップのズームとシフトのたびにajaxリクエストがサーバーに送信され、基本的に冗長なリクエストでサーバーに過負荷がかかるため、それは愚かなアプローチですか?

私が達成したいのは、マーカーの大きなデータセットでの素晴らしいユーザーエクスペリエンスです(2秒未満でロードするため)。

18
Volder

あなたのアプローチはしっかりしています。可能であれば、クラスターを事前計算してサーバー側にキャッシュし、基になるデータセットが変更される頻度によって更新戦略を決定する必要があります。

Googleマップには、地球上のどこにいるかに応じて、最大20のズームレベルがあります。データがどのようにクラスター化されているかに応じて、合計で200,000のマーカーがあり、特定の時間に約500をマップに表示する場合、すべてのクラスターの場所と元のマーカーを数えると、約2n = 400,000の場所のサーバーのみを格納することになります-すべてのズームレベルを組み合わせた状態。

可能なクラスター更新戦略:

  • 追加されたすべての新しいマーカーで更新します。高度なデータの適時性が必要な場合、書き込みの少ない読み取りが多いアプリケーションで可能です。
  • 定期的に更新する
  • 次の場合に更新を開始します((最後のクラスタリングパス以降に新しいマーカーがあり、&&キャッシュがXより古い)||最後のクラスタリングパス以降にY個を超える新しいマーカーがある)

これらのマーカーを、地理データをネイティブにサポートするデータベースに格納すると、有益な場合があります。これにより、SQLのようなステートメントが場所を照会できます。

クライアント側では、30%ではなく50%のマージンを取得することを検討します。 Googleは2の累乗でズームします。これにより、1つの完全なズームレベルを表示できます。

次に、このアプリケーションが頻繁に使用され、最適化に価値がある場合は、クライアントがズームインしたときにサーバー側でログを記録します。ユーザーが頻繁にズームインまたはズームアウトするかどうかを判断できるように、使用状況をプロファイルしてみてください。 「最初の結果を取得した後にユーザーの70%がズームインし、20%がズームアウトする」などの確かな数値により、UIを取得するために、ユーザーのズームされたデータの次のレイヤーをプリロードする価値があるかどうかを判断できます応答性。

11