MYSQL 巨大的记录并找到每个最近的点

Question

当我遇到 MySQL 时，我遇到了一些麻烦。 我有一个存储车辆日志的表 deviceLog 包括： 1.设备ID 2.日期时间 3. 纬度 4. 经度

设备将每分钟将日志存储到数据库中。 这意味着一辆车每天有 1440 条记录。
假设我有 5000 辆汽车，那么每天表中将有大约 720 万行日志数据。

每个月我都需要生成每辆车的设备位置报告。这与另一个表名相关，即 POI （兴趣点），其中存储： 1. 地点名称 2. 纬度 3. 经度

的最终输出应该是： DeviceID、DateTimer、LocationName（根据deviceLog提供的纬度、经度）

对于 LocationName，我创建了一个调用存储过程的函数，通过发送行的纬度和经度来检索它，它将从 POI 表中返回 LocationName

CREATE DEFINER=`root`@`localhost` PROCEDURE `SPGetGeoName`(IN `xLat` DOUBLE, IN `xLon` DOUBLE, OUT `xLocationName` NVARCHAR(1500))
BEGIN

declare lon1 float; declare lon2 float;
    declare lat1 float; declare lat2 float;
    declare dist float; declare pi float;
    set pi = 3.1415926;
    set dist=1.9;
    set lon1 = xLon-dist/abs(cos(radians(xLat))*69);
    set lon2 = xLon+dist/abs(cos(radians(xLat))*69);
    set lat1 = xLat-(dist/69); set lat2 = xLat+(dist/69);

SET xLocationName = (SELECT locationName FROM poiTest 
                WHERE longitude BETWEEN lon1 AND lon2 AND 
                      latitude BETWEEN lat1 AND lat2 AND
                      3956 * 2 * ASIN(SQRT( POWER(SIN((xLat-latitude)* pi/180 / 2), 2) +COS(xLat*pi/180) * COS(latitude*pi/180) *POWER(SIN((xLon-longitude) * pi /180 / 2), 2) )) < dist 
                      ORDER BY 3956 * 2 * ASIN(SQRT( POWER(SIN((xLat-latitude)* pi/180 / 2), 2) +COS(xLat*pi/180) * COS(latitude*pi/180) *POWER(SIN((xLon-longitude) * pi /180 / 2), 2) )) ASC limit 1);


END

结果如每辆车 15 秒 1 个月，粗略计算大约需要 1 天才能生成整个报告。

有没有办法克服这个问题？

CREATE TABLE `deviceLog` (
   `tripID` int(11) NOT NULL AUTO_INCREMENT,
   `latitude` float NOT NULL,
   `longitude` double NOT NULL,
   `rssi` smallint(6) NOT NULL,
   `speed` float NOT NULL,
   `course` float NOT NULL,
   `hdop` float NOT NULL,
   `dateTimer` datetime NOT NULL,
   `gpsStat` tinyint(4) NOT NULL,
   `unitStat` varchar(12) NOT NULL,
   `battVolt` varchar(6) NOT NULL,
   `fuelLevel` varchar(6) NOT NULL DEFAULT '0',
   `fuelData` varchar(6) NOT NULL DEFAULT '0',
   `ignVolt` varchar(6) NOT NULL,
   `odoMeter` decimal(10,2) NOT NULL,
   `deviceID` varchar(16) NOT NULL,
   `chksum` varchar(2) NOT NULL,
   `resol` varchar(1024) DEFAULT NULL,
   `driverID` varchar(20) DEFAULT NULL,
   `geoFences` varchar(255) DEFAULT NULL,
   `poiLoc` varchar(255) DEFAULT NULL,
   `eventStat` varchar(2) DEFAULT NULL,
   `IOStat` varchar(4) DEFAULT NULL,
   `groupID` varchar(2) DEFAULT NULL,
   PRIMARY KEY (`tripID`),
   KEY `deviceID` (`deviceID`),
   KEY `dateTimer` (`dateTimer`)
 ) ENGINE=MyISAM AUTO_INCREMENT=3423023 DEFAULT CHARSET=latin1


CREATE TABLE `poi` (
   `poiID` int(11) NOT NULL AUTO_INCREMENT,
   `type` varchar(50) NOT NULL,
   `locationName` varchar(200) NOT NULL,
   `state` varchar(50) NOT NULL,
   `city` varchar(50) NOT NULL,
   `longitude` float(10,7) DEFAULT NULL,
   `latitude` float DEFAULT NULL,
   PRIMARY KEY (`poiID`),
   KEY `lat` (`longitude`,`latitude`)
 ) ENGINE=MyISAM AUTO_INCREMENT=683606 DEFAULT CHARSET=latin1 ROW_FORMAT=DYNAMIC

Answer 1

“专用堆栈”是指大量服务器。想想成本。

有几件事可以在不投入硬件的情况下完成。

请为每张桌子提供SHOW CREATE TABLE；同时，我会假设您没有（或无用的）索引。我将检查数据类型以查看可以缩小的内容 - 以节省磁盘空间和一些时间。

我不喜欢使用范围广泛的精度——DOUBLE 有 16 个有效数字； 69 只有 2 个。考虑 69.172。请参阅 RADIAN 函数代替 8 位 pi/180。

dist/abs(cos(radians(xLat))*69) 可以被评估一次（对于微小的加速）

ABS() 可能是不必要的。

没有索引，查询将扫描整个表。至少有INDEX(latitude) 和INDEX(longitude)。这会将工作量从 550K 测试更改为 2K。要将其缩小到大约 30 个，您需要进行大量重写，例如 http://mysql.rjweb.org/doc.php/latlng

“设备”可能有一半时间“位于”同一个“位置”。 （车辆尤其如此。）在这种情况下，开始查看设备自上次定位后是否未移动。

这带来了另一个问题——除非位置发生了显着移动，否则不要存储位置。这样可以节省一半的磁盘空间。

另一个想法——改变客户的期望。不要每分钟定位一次设备，而是每 10 分钟定位一次。仅此一项，就会将计算时间从 1 天更改为 2.4 小时。

对架构的评论：

• FLOAT 占用 4 个字节；它们可以变成一些更小的数据类型吗？ lat/lng 不一致。请参阅this 了解一些选择。
• 什么是geoFences 和resol？
• 不要将 (m,n) 与 FLOAT 一起使用（例如 float(10,7)）。

如果您要一次获取一台设备的所有数据，请更改

PRIMARY KEY (`tripID`),
KEY `deviceID` (`deviceID`),

到

PRIMARY KEY (`deviceID`, tripID),
KEY (`tripID`),

这将更好地利用“集群”。但您也必须更改为 InnoDB。

您需要在设备停止时消除“重复”条目。否则，您将遇到磁盘空间问题（和性能问题）。

不像 YouTube

YouTube 有不同的问题；大多数其他大人物也是如此。不要费心研究它们。

我建议你的第一个问题是数据量。

• 更少的列。
• 行数更少。
• 总结信息。

24 列——其中一些在几分钟内或一整天都不会改变。所以，不要一直存储它们。

拆分 24 列。主要查询是什么？需要多少 列来支持它？也就是说，从 0 列构建 up 表；与尝试减少 24 列相比，您将取得更大的进步。

每 15 秒一行。即使“设备”关闭？节省了大量资金。

重新计算设备所在城市的名称？但它通常和上次在同一个城市。检查那个first。这应该会节省大量的 CPU 时间。

使用 3 字节的 MEDIUMINT UNSIGNED 表示“城市”。这就是 poiID 应该是的，而不是 4 字节的 INT SIGNED。当您显示名称时，JOIN 将足够便宜。

老化。当然，客户需要昨天的详细信息。但也许上个月的数据可能会更粗一些？去年的更不详细——甚至可能被折腾了？

如果您要折腾“旧”数据，现在是时候使用PARTITION 表了。这样清除将是“即时的”。

等等。等等。