Mongodb 为客户提供地理空间新闻

我正在开发一个应用程序，用户将根据其位置接收基于地理位置的信息。服务器应该能够处理数量庞大的连接客户端>100k

现在我想出了4种方法来处理用户的位置

方法-无地理空间索引：

应用程序服务器只保存一个已连接客户端的列表，它们位于不同的位置。 每当有可用的信息时，服务器就会在整个列表上循环，并检查客户机是否在给定的半径范围内

怀疑：非常昂贵

方法-在应用程序服务器中处理地理空间索引：

应用程序服务器确实维护了一个包含所有连接客户端的R树，并且它们位于同一位置。 所以我在看

怀疑：使用JSI更新地理空间索引的成本非常高

方法-让数据库“mongoDb”进行地理空间索引/计算：

应用服务器只保存对已连接客户端（连接）的引用，并将该引用的密钥及其位置保存到mondoDb中。 当新信息可用时，服务器可以查询数据库以从附近的所有客户端获取密钥

Pro：我想mongoDb的地理空间索引实现确实比我在应用服务器上做的要好得多

怀疑：客户四处奔波，迫使我频繁更新地理空间索引。我可以这样做吗？还是我遇到了性能问题

使用二维数组接近自己的“索引”

今天我想用二维数组创建一个非常简单的索引。外部数组表示经度，内部数组表示纬度。 假设3度经度/高度就足够精确了。 我可以通过以下方式收到给定区域中的用户列表：

ArrayList userList=data[91][35]//91.25489880712891,35.6086997858； //我还需要获得周围阵列中的用户90；35, 92;35 ... //如果我需要更高的精度，我可以再使用一个十进制数据[912][356]

Pro：我将拥有快速的读写访问权限，而无需查询数据库

怀疑：极点处的半径较短。丑陋的黑客

---

如果有人能给我指出正确的方向，我将不胜感激。

MongoDB用于地理空间索引的索引基于geohash，它基本上将二维空间转换为一维键，适合于B树索引。虽然这比R树索引的效率要低一些，但它比场景1的效率要高得多。我还认为，在数据库级别使用空间查询过滤数据比在上面创建自己的空间索引策略更高效、更易于维护

MongoDB需要注意的主要一点是，不能将几何体列用作切分键，尽管可以使用另一个键切分包含几何体字段的集合。此外，如果您希望执行任何聚合查询（您的问题还不清楚），几何体字段必须是管道中的第一个字段

还有一个geohaystack索引，它基于小桶，并针对基于小区域的搜索进行了优化，请参阅，这在您的案例中可能很有用

就速度而言，B树索引上的插入和搜索本质上是O（logn），请参阅，如果没有索引，则搜索将是O（n），因此不需要很长时间，索引与没有索引之间的性能差异将是巨大的

---

如果您担心大量写入会减慢速度，您可以调整，这样您就不必等待大多数副本响应每次写入（默认设置），但如果您丢失主副本，则可能会导致数据不一致。

感谢您的回答，我想geohaystack索引适合我的情况。MongoDB文档没有回答我的问题的地方是，对索引的更新将如何影响性能，以及这样做是否是一个好主意。最终，测试是无可替代的，但即使索引对写性能有影响，这也会被读性能所抵消。使用MongoDB，您可以调整所谓的写入问题，即如果不等待大多数副本响应，写入将更快返回，但如果丢失主副本，则可能会导致数据不一致。@user3211074。我已经用B-Tree上的一些信息更新了我的答案，并在Mongo中写下了关注点，这可能有助于回答您的问题。我想询问您实际查询的更多信息，以便更好地给出场景4的观点，但请确保您已接受答案。那么，您选择场景3了吗？我尝试了场景3，但性能测试的结果并不令人惊讶。今天我尝试了场景4。它非常简单，性能非常好。我使用了一个hashMap，键为“long；lat”（四舍五入到1个小数点），该键的值是一个连接用户的列表。它非常适合我的用例。