google-maps - 在谷歌地图上加载 100-200K 标记

Question

目前我正在使用 Google Maps v.3 API 在 map 上绘制标记。
我总共有大约 500 个标记。

出于显示目的，我使用 markerCluster 并在浏览器的客户端使用此工具对标记进行分组。

但是，我计划扩大位置数量并假设它可以快速增长到 100K 甚至 200K。

我做了一些压力测试，并意识到当前的解决方案基本上会杀死浏览器和大约 10-20K 标记。

所以我的问题是绘制这么多标记的最佳方法是什么(不需要谷歌地图)？

我读过类似问题的帖子，例如:

Showing many markers in Google Maps

Best solution for too many pins on google maps

基本上人们建议使用一些集群器来显示，我已经使用了。

或者使用融合表来检索数据，这不是一种选择，因为数据必须保留在我的服务器上。另外我假设显示功能受限于融合表。

我正在考虑实现以下方案:

在每个页面缩放/加载 - 发送带有显示 View 边界的 ajax 请求，在所有边上添加大约 30% 并检索标记，这些标记仅属于这个地理区域。
如果用户缩小，则添加 30%，以便我可以快速显示周围的其他标记，然后在后台进一步检索周围的其余标记(更广泛的区域)

当标记的数量超过 50 时，我计划应用聚类来进行显示。但是由于javascript中的markerCluster非常慢，即不是markerCluster而是google本身，因为它仍然应用所有标记的位置，我计划通过将显示 map 的边界分割成大约15 * 15网格在服务器端进行聚类并将标记放入特定的单元格，然后基本上发送到带有内部标记数量的客户端集群(例如，对于热图)。然后将簇显示为标记。

您能否提供一些类似的见解。一般说得通吗。或者这是一种愚蠢的方法，因为 ajax 请求将在每次 map 缩放和移动时发送到服务器，并且基本上用冗余请求使服务器过载？

我想要实现的是对大型标记数据集的良好用户体验(在不到 2 秒的时间内加载)。

Answer 1

你的方法是可靠的。如果可能的话，您需要预先计算集群并将它们缓存在服务器端，其更新策略取决于底层数据集更改的频率。

谷歌地图有大约 20 个缩放级别，具体取决于您在地球上的位置。根据您的数据的聚类程度，如果您总共有 200,000 个标记并且愿意在给定时间在 map 上显示大约 500 个，计算所有群集位置和原始标记，您最终只会存储大约 2n = 400,000 个位置服务器-side 与所有缩放级别相结合。

可能的集群更新策略:

更新添加的每个新标记。如果您需要高度的数据及时性，则可能适用于具有少量写入的读取繁重的应用程序。

按计划更新

如果((自上次聚类传递以来有任何新标记&& 缓存早于 X)|| 自上次聚类传递以来有超过 Y 个新标记)

，则开始更新

将这些标记存储在本地支持地理数据的数据库中可能是有益的。这允许类似 SQL 的语句查询位置。

在客户端，我会考虑在任一侧获取 50% 的 margin ，而不是 30%。 Google 放大 2 的幂。这将允许您显示一个完整的缩放级别。

接下来，如果这个应用程序会被大量使用并且值得优化，我会在客户端放大时记录服务器端。尝试分析您的使用情况，这样您就可以确定用户是否经常放大和缩小。使用实心数字(例如“70% 的用户在检索初始结果后放大，20% 缩小”)，您可以确定是否值得为您的用户预加载下一层缩放数据，以获得 UI react 能力。