【问题标题】:Query 1 million records from MySQL into an array in PHP [closed]在 PHP 中将 100 万条记录从 MySQL 查询到数组中 [关闭]
【发布时间】:2016-03-01 19:06:54
【问题描述】:

我的最终目标是将 300 万条记录发送到 Google Maps API 以显示为标记,但在此之前......

我什至无法将 100 万个加载到 PHP 数组中。每个元素的数据为 18 位,有 2 列和 100 万行。

查询只是一个直接的SELECT *,但是当我循环遍历并将正确的记录存储在数组中时内存不足。我试过使用 SplFixedArray 但也没有任何运气。

我需要找到一个很好的方法来批处理并将其拆分 - 在运行一些测试之后,我可以将大约 500k 拉入一个数组而不会达到内存限制(已经是 512M!),所以我可以这样做吗在 2 或 3 个查询中?在页面加载之前,我仍然需要将全部数据保存到服务器端的数组中,并且我可以将它传递给 Maps,所以我假设批处理它不会解决这个问题,因为它仍然会在内存中?

编辑:有一个很大的评论链正在增长,但大多数人都同意这是一个坏主意,出于某种原因。所以 我的 解决方案是将它拉回到大约 300k 点,这可以通过少得多的头部撞击来实现。

【问题讨论】:

  • 不要这样做.....大量数据占用大量内存。为了让您了解需要多少内存,read this.... 然后停止尝试对 Google Maps API 进行 DDOS 攻击
  • @MarkBaker 所以这不可能吗?不粗鲁,但我很好奇。而且我不应该做任何事情,它将数组加载到我自己的站点上,然后将其加载到 gmap 中 - 我认为这不会导致 Google 额外的服务器负载
  • 如果您使用 Google Maps API 请求绘制 3000000 个数据点,那么这将被 google 拒绝,就好像这是一次攻击.....您遇到过任何企业吗试图用这么多的数据来做到这一点?他们不这样做是有充分理由的
  • 那么也许你需要和你的客户谈谈他们所要求的不切实际......你肯定已经看到其他网站是如何做到这一点的,通常总结点数一个区域,直到您放大该区域,以便在任何请求下实际上只绘制有限数量的点
  • @Tom 您能否详细说明“在页面加载之前,我仍然需要将全部数据保存到服务器端的数组中,并且我可以将其传递给 Maps”。我仍然不明白你为什么需要它。

标签: php mysql arrays


【解决方案1】:

尝试将数百万个地图标记输入谷歌地图确实没有任何意义。

从内存角度或性能角度来看,这根本不可行。想想那个数据的大小——即使每个标记只有一个字节的数据,也就是 3 兆字节。但实际上,每个标记至少需要大约 20 个字节,仅用于坐标和 JSON 标记,所以在您开始为每个标记添加描述之前,这是 60 兆字节。您的系统将无法以足够快的速度将其传输到 Google 以使其在网络上可用。即使您可以,Google 也不会接受您在每次有人想查看您的地图时向他们发送大量数据。

在任何情况下,地图上的所有这些标记无论如何都无法使用;他们会掩盖整个地图和彼此,只会弄得一团糟。

即使是一次向 Google 发送几百个地图标记,也是在推动它。发送数百万是不可能的。

那么你能做些什么呢?其他网站如何设法同时拥有数以百万计的标记?答案很简单——他们没有。他们只向 Google 发送正在显示的地图部分的标记。

在更宽的缩放级别上,您甚至不会显示标记;你会有一个预渲染的热图,显示你的覆盖范围。在更近的缩放级别下,您只会加载正在显示的区域的地图图钉。随着地图的移动,您会加载更多内容。

Xfinity wifi map 就是一个很好的例子。他们在地图上有数十万个点,但一次加载的标记绝不会超过几十个。快速且易于管理。

【讨论】:

  • 感谢您的深入回复,预渲染的热图是个好主意,它非常符合我需要的最终结果,所以我会再研究一下
【解决方案2】:

提出将 1 M 记录提取到客户端是否是一个好主意的问题,并假设它是必要的。了解 MySQL 客户端协议的工作原理很重要。有两种模式 - 一种将整个数据集一次存储在客户端 (STORE_RESULT) 中,并为整个数据集分配内存,而另一种模式一次获取一行,仅为当前行分配内存 (@ 987654323@)。为了避免内存问题,您的客户端需要使用USE_RESULT 模式。

对于一些示例,请查看:

http://php.net/manual/en/mysqlinfo.concepts.buffering.php

您想要无缓冲的查询。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2017-01-31
    • 2011-07-14
    • 2018-11-19
    • 1970-01-01
    • 2019-02-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多