現在、すべてのコンテンツ エンティティが MongoDB に格納されている 1 つのデプロイ済みアプリケーションで、組み込みの Mongo コマンドを使用して、特定の半径内にあるgeoNearすべてのエンティティlatとプロパティを収集しています。lonこのデータ セットは、並列化された検索モジュールに入力され、ユーザーのクエリごとにフィルター処理されます。パフォーマンスは、アプリがこれまでに持っていたトラフィック レベルに対して十分強力です。
使用される本当に基本的なアプローチは、Mongo サイトで 10gen が持っているものとまったく同じです。
http://www.mongodb.org/display/DOCS/Geospatial+Indexing/
このアプローチにはいくつかの問題が組み込まれており、10gen が現在うまくいっていることを理解しています。
MongoDB GeoNearの結果を距離以外でソートしていますか?
MongoDB の geoNear はドキュメント内のフィールドのサブセットを返すことができますか?
https://jira.mongodb.org/browse/SERVER-1982
問題のクライアントは、開発チームが成長するにつれて、この機能のデータ アーキテクチャを刷新して、新しい開発者にとってコードをもう少し直感的にすることを検討しています。すべてを説明した後、彼らは、Mongo のこの比較的新しい機能をアーキテクチャのコア コンポーネントにすることに躊躇しているため、範囲指定クエリへのアプローチを変更することに関心があります (他のすべてのフィルタが適用される最初の限定されたデータ セットを取得するため)。適用）
強力な代替手段があるかどうかに興味があります。ロジックのこの部分を開発する任務を負う人物として、私はいくつか思いつくことができますが、それらの長所/短所を推測することしかできません。これをグーグルで調べた後、私が思いついたのは次のとおりです。
オブジェクト自体を Mongo に保存してから、ObjectId を、空間インデックス作成をサポートする SQL サーバー上の SQL テーブルの空間座標に関連付けます。このアプローチがすべての空間データを単一のインデックスに配置するのが好きですが、ここで豊富な SQL の才能は MySQL に傾いています。MySQL の空間インデックス作成の実装は、ドキュメントから、mongo のものとよく似た後付けのようです。また、私の知る限りでは、MyISAM テーブルのみに固定されます。
SQL を介した専用の空間ソリューションに関する限り、Web 上で最も多くのドキュメントを見つけることができるのは、PostGIS を使用した Postgres です。現在、haversign 距離計算を使用した半径検索だけを行っているため、これの強みの 1 つは、ベクトルとポリゴンを使用したより高度な制限のサポートであり、将来的には領域ベースの制限のようなものにスケールアップできるようになります。ここでの主な制限は、社内に Postgres の人材がまったくいないことです。これにより、新しい雇用が必要になるかどうかはわかりません。
オブジェクト自体の別の NoSQL ソリューションを検討し、位置メタデータをそれらに埋め込んだままにします。Neo4j は、この部門で多くのことを約束しているようです: http://www.oscon.com/oscon2011/public/schedule/detail/19822 ドキュメントには確かにいくつかの説得力のある例があります。
コア ミッションの目的として空間インデックスを実装するキー値ストレージ ソリューションがあるかどうかに興味がありますか? そうでない場合、責任の適切な分離と最大限の保守性のために、どのアプローチが最も推奨されますか?