目前，我正在使用Google Maps v.3 API在地图上绘制标记。 我总共有大约500个标记。
出于显示目的，我在浏览器的客户端使用此工具使用markerCluster和组标记。
但是，我计划扩大位置数量，并假设它可以快速增长到100K甚至200K。
我做了一些压力测试，并意识到当前的解决方案基本上会杀死浏览器和大约10-20K标记。
所以我的问题是什么是绘制那么多标记的最佳方法（不是必要的谷歌地图）？
我读过有类似问题的帖子，例如：
Showing many markers in Google Maps
Best solution for too many pins on google maps
基本上人们建议使用某些群集器进行显示，我已经使用过。
或者使用融合表来检索数据，这不是一个选项，因为数据必须保留在我的服务器上。此外，我假设显示功能受到融合表的限制。
我正在考虑实施以下方案：
在每个页面上缩放/加载 - 发送带有显示视图边界的ajax请求，在所有边上添加约30％并检索仅属于此地理区域的标记。 如果用户缩小，则会添加30％，以便我可以快速显示其他标记，然后在背景中进一步搜索其余部分（更广泛的区域）
当标记数超过50时 - 我计划将聚类应用于显示目的。但由于javascript中的markerCluster非常慢，即不是markerCluster而是谷歌本身，因为它仍然应用所有标记的位置，我打算通过在大约15 * 15网格中分割显示的地图的边界来在服务器端进行聚类然后将标记放入特定的单元格中，然后基本上将内部标记的数量发送给客户端集群（例如，用于热图）。然后将群集显示为标记。
你能不能给一些有相似之处的人提供一些见解。一般来说它是否有意义。或者这是一种愚蠢的方法，因为ajax请求将在每个地图缩放和移位时发送到服务器，并且基本上使冗余请求超载服务器？
我想要实现的是在大型标记数据集上的良好用户体验（在不到2秒的时间内加载）。
答案 0 :(得分：10)
你的方法很扎实。如果可能的话，您将要预先计算群集并在服务器端缓存它们，其更新策略由基础数据集更改的频率决定。
谷歌地图有大约20个缩放级别，具体取决于你在这个星球上的位置。根据您的数据的聚集程度，如果您总共有200,000个标记，并且愿意在给定时间在地图上显示大约500个，那么计算所有群集位置和原始标记，您最终只会存储大约2n = 400,000位于服务器端的所有缩放级别的位置。
可能的群集更新策略：
将这些标记存储在本地支持地理数据的数据库中可能是有益的。这允许类似SQL的语句查询位置。
客户方面，我会考虑在任何一方获得50％的保证金，而不是30％。 Google放大了2的幂。这将允许您显示一个完整的缩放级别。
接下来，如果此应用程序将被大量使用并且优化是值得的，我会在客户端放大时记录服务器端。尝试分析您的使用情况，以便您可以确定用户是否经常放大和缩小。使用实数（例如＆＃34; 70％的用户在检索初始结果后放大，20％缩小＆＃34;），您可以确定是否值得为用户预加载下一层缩放数据，为了获得UI响应能力。