高性能Webアプリケーションに最適なGISシステム-PostGISとMongoDB

位置データに基づいたWeb /モバイルアプリケーションを作成しています。私はすでにMongoDBに精通しているため、mongoの地理空間インデックスは私のニーズに非常に適していることがわかりました。私は主に単純な/短いロケーションポイントを扱っているので、Mongo 2dのインデックスは私にとって良いです。

その道に沿って、私はその安定/成熟した方法のために、PostGISを選びました。そしてその素晴らしい機能セット。しかし、私のデータは場所に大きく依存しているため、主な懸念事項はパフォーマンスです（ほとんどの場合、db呼び出しの70〜80％が場所を処理します）。

mongoが好きなのは、すでにfoursquareのような高性能Webアプリで使用されているからです。しかし、私はPostGISが主に政府/企業プロジェクト（主に非Web /モバイルアプリ）で使用されるのを見ました。Web /モバイルアプリに適切なGIS dbを選択するために、今は少し混乱していますか？何か提案がありますか？

書き込み負荷（着信データストリーム）が無制限に増加する可能性がある場合（Webプロジェクトの成功により書き込み量が増加する場合）、Mongoを使用します。単一のハイエンドサーバーの機能を超えて成長したら、PostGIS / PostgreSQLでボトルネックを記述します（注目に値しますが、かなり巨大です）。

大量の読み込み負荷（マスター/スレーブレプリケーション）および巨大なデータサイズ（テーブルパーティション分割）に適したPostGIS / PostgreSQLソリューションを設計できますが、書き込み負荷は困難です。あなたはすでにMongoに対して、そしてPostGISの場合、PostGISのはるかに大きな機能セットとコード成熟度であるケースをレイアウトしているので、他の懸念とのバランスを取ります。

私は数年間PostGISを使用していますが、ごく最近、MongoDBを使用して特定のユースケースを処理する方法を調査し始めました。レコードごとにタグの数が異なるOSMデータのように、スパースフィールドを持つポイントデータを扱っていました。MongoDBにはスキーマがないため、これに適しています。このデータのサンプルを各DBのインスタンスにロードしましたが、これが見つかりました。

ポイントデータの単純な保存と取得では、Mongoがうまく機能しているように見えます。バウンディングボックスの地理空間クエリはうまく機能しているようで、全体的なパフォーマンスが非常に良いことがわかりました。mongoimportツールでは、TSVファイルまたはCSVファイルで複合2D座標フィールドを定義できないことがわかりましたが、セットアップも簡単です。JSONを生成するスクリプトを作成するのは非常に簡単なので、これはそれほど大きな問題ではありません。現時点での主な欠点は、地理空間領域の他のほとんどがそこからデータをネイティブに読み取れないことです。https://github.com/springmeyer/mapnik-mongoに実験的なMapnikデータソースプラグインがあるように見えますが、それですべてが見つかりました。

一方、PostGISのセットアップには少し時間がかかります（少なくとも私にとっては）が、前述のように、すぐに使用できる機能が増えています。より高度な空間分析機能を提供することに加えて、他の多くのアプリケーションやライブラリによってネイティブにサポートされています。Mapserver、Mapnik、QGis、GDALなど。私にとって、PostGISは単純なストレージおよび検索システムというよりは、真のGISシステムです。

パフォーマンスに関しては、両方のシステムから非常に迅速にデータを取得できることがわかりました。しかし、PostGISはインデックスの存在からより多くの恩恵を受けているように見えました。MongoDBは、データセット全体（200万レコード）を一度に返すのがわずかに速く、インデックスを使用したクエリを返すのが初めて（初めて）少し遅くなりました。キャッシングに使用するメカニズムについては正確にはわかりませんが、MongoDBでクエリを繰り返すと、2回目には結果がはるかに速く戻ることがわかります。PostGISでも似たようなものが見られますが、同程度ではありません。また、MongoDBを実行していると、PostGISを使用している場合よりも、マシンのメモリ使用量がはるかに多いように見えます。

したがって、私の結論は、デフォルトの地理空間ストレージおよび分析システムとしてPostGISを取り除くつもりはないが、特定のタイプのプロジェクト（つまり、画像タイルおよび/またはポイントデータを表示するWebマップ）ではMongoDBの使用を検討する可能性があるということですデータストアとして。

ロジャー

Mongoのメモリ使用量に関しては、Mongoがインデックスとデータをメモリに取得するためにOSファイルキャッシュに完全に依存していることを指摘する価値があります。「mongoメモリバッファ/インデックスキャッシュ」という概念はないので、試してみてください（またはむしろ、OSは、すべてのデータファイルがキャッシュされるまで、使用可能なすべてのRAMを使用します。