我构建了一个社交安卓应用程序，用户可以通过gps位置查看周围的其他用户。一开始我的用户数量很低，所以一切都很顺利，但现在我的用户人数越来越多(每天大约1500+100)，我发现了我的设计中的一个主要问题。
在我的GoogleAppEngineservlet中，我有一个静态HashMap，它保存了所有的用户配置文件对象，currenty1500，这个数字会随着更多用户的注册而增加。
我为什么这么做
每个请求周围用户的用户都会将自己的gps与其他用户进行比较，并检查他们是否在自己10公里的半径内，平均每5分钟就会发生一次。这就是为什么我不能每次都从数据库中获取用户，因为GAE读/写操作配额会让我分崩离析。
此设计的问题是
随着用户数量的增加，Hashmap每4-6小时就会变为null，我认为这段时间正在缩短，但我不确定。我通过每次检测到它变为空时从数据库重新加载用户来解决这个问题，但这会导致我的用户在30秒内使用DOS，所以我正在寻找更好的解决方案
我猜这是因为哈希图的大小，我说得对吗？
我想知道如何用最大的灵活性管理ALL用户档案。
谢谢。
我不会将这些数据存储在HashMap中，因为如果在多个实例上运行，它不会真正扩展，而且会占用大量内存。
为什么不使用一些不同的存储，比如MongoDB，它也可以在"云中"使用？(例如www.mongohq.com)。
如果要进行扩展，则需要将数据与处理器分离。例如，让x个服务器运行servlet(或者让Google AppEngine自行扩展)，并将数据放在不同的位置(例如，在MongoDB或PostgreSQL中)。
您需要重新思考整个设计。将所有用户存储在一个巨大的HashMap中是无法扩展的(迟早您必须对应用程序进行集群)。此外，您的算法的复杂性相当高——您需要遍历每个用户的整个地图。
一个更具可扩展性的解决方案是使用空间数据库。所有主要的关系数据库和一些NoSQL产品都提供地理空间索引。基本上，数据库查询引擎针对以下查询进行了优化：给我所有接近该给定点的记录。
如果您的应用程序真的很成功，那么即使是内存中的地图也会比企业级地理空间索引慢。