私は、10 Gを超えるような大量のデータを処理するための概念実証を検討しています。これには、1秒あたり少なくとも200回以上の書き込みと、1秒あたり約50回以上の空間関連データの読み取りが必要です。これも成長しているシステムです。現在、パフォーマンス上の理由から、この大量のデータをNoSqlビッグテーブルのようなデータベースに移動することを検討しています。
私はMongoDBとcassandraを検討し、詳しく調べました。私の読書に関する限り、
Mongodb:-ライターロックの問題があるようです-stackoverflowの投稿の1つは、複数のサーバーが必要ない場合にこのデータベースを提案しました-インデックスはメモリに保持されます。したがって、インデックスの増加が大きいほど、パフォーマンスが低下すると言われます-利点は、Mongodbが空間データとインデックス作成を直接サポートし、近くの場所を見つけるなどの機能を備えていることです-この投稿を参照してください CassandraまたはMongoDB For Our Locationベースのアプリケーション mongodbを最良の選択として提案する
カサンドラ:
-関連するデータベースの中で最高のようです-書き込みと読み取りのパフォーマンスが優れているようです-空間インデックスをネイティブにサポートしていませんが、ジオハッシュを介して拡張できます
私の心は、その優れたドキュメントと空間データの直接サポートのために、実際にmongodbに出かけています。このような大きなシステムにmongodbを使用した経験がない人はいますか?私は実際にパフォーマンスのためにmongodbiostatにたくさんの投稿を見ています。
Mongodbが適していない場合、誰かがcassandraを使用したジオハッシュに関するいくつかの指針を与えることができますか?ハッシュを作成するためのリンク http://code.google.com/p/geospatialweb/ を見ました。しかし、クエリなどの方法について質問がありますか?
これは古い質問であり、質問に直接回答しないことはわかっていますが、クエリによっては、Cassandraが最適なオプションではない場合があります。また、クエリを機能させるにはMongoDBでのインデックス作成も問題になる可能性があります(私自身の経験では)。Mongoは、重い地理データとクエリの場合、Cassandraよりもわずかに優れています。
ElasticSearchも検討することをお勧めします。これは、データの形状と実行するクエリの種類によっては、おそらく最善の解決策です。あなたがあなたの質問を投稿したとき、それは今日よりも選択肢が少なかったようです。
Cassandra + Solrを試してください。これは役立つかもしれません: http://digbigdata.com/geospatial-search-cassandra-datastax-enterprise/
よろしく、ゴーサムクマール
tl; dr
Elassandra CassandraとElasticSearchの組み合わせ。
未来からのちょっとしたアップデート。
私は現在、ビッグデータリアルタイムシステムのコンセプトを作成しています。また、地理空間データを保存し、大規模なクエリを実行する必要があります。昨日、データを適切に配置し、地理空間インデックスとバウンディングボックスのようなクエリをサポートできるようにする方法について多くの調査を行いました。
私が最初に読んだのはPostgreSQL + Postgisでしたが、最大のインスタンスは最大200k書き込み/秒に制限されています。
2つ目は地理空間データベース Tile38 で、クエリはスケーリングできますが、書き込みはスケーリングできません。これを使用する唯一の方法は、データを手動でシャーディングすることです。
3つ目はMongoDBでした。必要な地理空間機能をサポートする優れたドキュメントが見つかるためですが、書き込みをスケーリングできるかどうかを判断するのは困難でした。
つまり、最後のデータベースはCassandraでした。このデータベースは、水平書き込みスケーリングと障害テイクオーバーでよく知られています。 Cassandraとのトレードオフは、データのクエリはパフォーマンスが良くなく、すぐに使用できる地理空間をサポートしないことです。大規模なデータのクエリには、Tracker1のようにElasticSearchが適しています。今日、私はCassandraとElasticSearchで構成された Elassandra と呼ばれる新しいデータベースを見つけました。これにより、大規模な書き込みとほぼリアルタイムでの大規模なデータの読み取りが可能になります。これまでのところ、セットアップとメンテナンスに最小限の労力で、最善のソリューションを提供しています。
また、現時点ではCassandraを使用して、空間インデックスソリューションを探しています。全文検索と属性検索を提供するためにLuceneを使用し、それに伴って部分インデックスのサポートも提供しています。これもチェックします。
現在の実装は、単純なツリー(グリッドベース)に基づいて情報をシャーディングするように見えます。各シャードはLuceneインデックスであり、特定のサイズを超えると、インデックスはxまたはyで分割されます。そして、そのようなシャードはバイナリ表現を持っているので(グリッド内の位置は2ビットで構成され、次のレベルは次の2ビットなど)、検索は位置によって発行され、位置/グリッド解像度の接頭辞が付いたシャードハットによって応答されます。シンプルなシステムは今のところうまく機能していますが、現時点では生産的に使用されていません。