服务器端集群？

Question

我拼命寻找可以处理多达 50 000 个标记的正确 解决方案（如果服务器可以处理，为什么不更多） 虽然在我的服务器上很容易，但我已经这样做了好几天了。

---

概念是这样的：

---

• 集群服务器的最佳解决方案/语言是什么 边？我不是在寻找大量的工作代码，但我需要被推向正确的方向。
• 如何 "cache" 或 "mark" 已经加载的簇/标记，以便您 当地图正在缩放 in/out 或平移时，不会重新加载已经加载的标记/集群？

---

理论：

正确的方法似乎与此类似：

• 如果地图缩小了，有很多标记，在server
中处理聚类
• 如果地图放大到所有标记不再适合视口的点，则仅聚类视口中的标记 - 还有服务器
• 如果缩放太大以至于视口中的标记数量变小（例如 < 500）、cluster in browser via JS

---

我可以在服务器端使用的数据，也可以通过 JSON:

发送到浏览器

• 发出请求时通过 ajax 将地图边界发送到服务器
• 来自数据库查询的标记总数
• 来自数据库查询的标记坐标
• 可能是我目前没有意识到的其他重要/有用的东西

Answer 1

我正在使用具有 50,000 100,000 个多边形的 google 地图应用程序 事实证明，将多边形组织成一系列区域（工作表逻辑、区域或类似区域）的可能性非常有用。使用通过 ajax 发送到服务器的已显示区域数组以及您绑定的坐标允许我 select 只有尚未显示的区域，从而减少带宽分配和渲染时间多边形，

剩下的攻略就对了。为了进行更彻底的评估，应该 in-depth 技术在社交中几乎不可行。

对于服务器端语言，它们都很好，我个人现在正在使用 PHP 和带有 PDO 驱动程序的框架 Yii2 MySQL。重要的是使用一个环境可以非常轻松高效地访问数据库。

在这些条件下，使用良好的群集组织以及在缩放级别允许时向区域显示多边形使应用程序 google 地图表现非常出色

请注意，标记的出现速度比多边形更快，因为它涉及的坐标数量和图形特征更少。

像你这样的笼统问题很难在网上找到好的答案。对于区域取决于您管理的区域的大小和标记的平均密度。对于不靠近极点的区域，您可以使用一小部分坐标。或者如果您的地理点具有与区域相关的某些属性，您可以使用它们。您可以在线找到 link 缩放区域的近似尺寸的公式。还取决于标记的收集是如何完成的。就我而言，在收集过程中，我评估了一些满足此需求的属性。

为了检查一个标记或一组标记是否已经在地图中，我使用简单的矢量并使用它（通过 ajax）与服务器进行动态交换。第一次向量是空的，向量逐渐包含 "know" 已经显示的元素。