0

私は、ユーザーが gps の位置によって周囲の他のユーザーを見ることができるソーシャル android アプリケーションを構築しました。最初はユーザー数が少なかったのでうまくいきましたが、ユーザー数が増えて (毎日約 1500 + 100)、設計上の大きな問題が明らかになりました。

私の Google App Engine サーブレットには、すべてのユーザー プロファイル オブジェクトを保持する静的な HashMap があります。現在は 1500 ですが、この数は登録ユーザーが増えるにつれて増加します。

なぜ私はそれをやっている

周囲のユーザーを要求するすべてのユーザーは、自分の gps を他のユーザーと比較し、自分の半径 10 km 内にいるかどうかを確認します。これは平均で 5 分ごとに発生します。そのため、GAE の読み取り/書き込み操作のクォータが私をバラバラにするため、毎回 db からユーザーを取得することはできません。

このデザインの問題点は

ユーザー数が増えるにつれて、ハッシュマップが 4 ～ 6 時間ごとに null に変わります。この時間が短くなってきていると思いますが、よくわかりません。ユーザーがnullになったことを検出するたびにデータベースからユーザーをリロードすることでこれを修正していますが、これによりユーザーに30秒間DOSが発生するため、より良い解決策を探しています.
ハッシュマップのサイズが原因だと思いますが、そうですか?

すべてのユーザー プロファイルを最大の可用性で管理する方法を知りたいです。

ありがとう。

4

2 に答える 2

1

複数のインスタンスで実行し、さらに多くのメモリを使用すると、実際にはスケーリングされないため、このデータを HashMap に保存しません。

「クラウド内」でも利用できる MongoDB のようないくつかの異なるストレージを使用しないのはなぜですか? (例: www.mongohq.com)。

スケーリングしたい場合は、プロセッサからデータを分離する必要があります。たとえば、x 台のサーバーでサーブレットを実行し (または Google AppEngine にこれをスケーリングさせ)、別の場所 (MongoDB または PostgreSQL など) にデータを配置します。

于 2012-09-30T10:40:29.487 に答える
0

設計全体を再考する必要があります。すべてのユーザーを 1 つの巨大な場所に格納するHashMapと、スケーリングされません (遅かれ早かれ、アプリケーションをクラスター化する必要があります)。また、アルゴリズムの複雑さも非常に高く、ユーザーごとにマップ全体をトラバースする必要があります。

よりスケーラブルなソリューションは、空間データベースを使用することです。すべての主要な関係データベースと一部の NoSQL 製品は、地理空間インデックスを提供しています。基本的に、データベース クエリ エンジンは次のようなクエリ用に最適化されています: Give me all records with near this given point .

アプリケーションが本当に成功した場合、インメモリ マップでさえ、エンタープライズ グレードの地理空間インデックスよりも遅くなります。

于 2012-09-30T10:44:14.950 に答える