毕设开发日志2017-11-30

Posted 2020-10-16 张晓晨的技术博客

【前言】

　　28号完成了预测模型的雏形之后由于性能问题几经修改，在上次的日志里也说到了，今天还是这个主题：性能的优化。

【问题描述】

　　在28号之后，由于预测模型的工作速度仍不满意，于是考虑是频繁的文件读写造成了计算速度慢，于是在数据库里新建了一个表，专门存放各个城市的预测模型数据。同时也编写了该表对应的Dao层，能够支持对模型数据的插入和更新，以及多种方式的查询。然后基于该数据表我对预测过程做了对应的修改。忙乎了一天之后在昨天晚上做测试，下面是输出每个省省会城市的预测值的计算运行过程：

2017-11-29 19:31:52----北京,38
2017-11-29 19:31:52----上海,68
2017-11-29 19:31:52----天津,129
2017-11-29 19:31:53----重庆,76
2017-11-29 19:31:54----黑龙江,155
2017-11-29 19:31:55----吉林,309
2017-11-29 19:31:56----辽宁,92
2017-11-29 19:31:59----内蒙古,79
2017-11-29 19:32:01----河北,112
2017-11-29 19:32:05----山西,112
2017-11-29 19:32:12----陕西,88
2017-11-29 19:32:18----山东,83
2017-11-29 19:32:27----新疆,147
2017-11-29 19:32:36----西藏,135
2017-11-29 19:32:43----青海,149
2017-11-29 19:32:51----甘肃,131
2017-11-29 19:32:59----宁夏,126
2017-11-29 19:33:08----河南,72
2017-11-29 19:33:18----江苏,18
2017-11-29 19:33:31----湖北,46
2017-11-29 19:33:47----浙江,80
2017-11-29 19:34:01----安徽,33
2017-11-29 19:34:17----福建,40
2017-11-29 19:34:38----江西,31
2017-11-29 19:34:58----湖南,32
2017-11-29 19:35:25----贵州,33
2017-11-29 19:35:52----四川,81
2017-11-29 19:36:22----广东,31
2017-11-29 19:36:53----云南,52
2017-11-29 19:37:27----广西,38
2017-11-29 19:38:05----海南,40

这里我发现了两点，第一，一开始的几个城市挺快，最后越来越慢，到最后到海南的时候需要38秒。第二，整个过程与文件读写方式来查预测模型的耗时几乎一样，也就是说耗时并不在于文件读写过程。于是我单独计算海口和北京两个城市的预测值，发现前者在1秒内出结果，而后者确实需要30多秒。然后仔细调试运行过程发现耗时瓶颈在于数据库查询。数据库该表的主键是"城市id_监测站_日期"，所以hbase以字典序排序所有数据，这样的话北京的信息在前面，所以就能很快查到，同时造成了各个城市查询时间不一致的情况。

　　考虑到这个问题，那么项目中其他功能势必会同样的影响，所以这个问题必须抓紧时间解决。

【解决过程】

 　　查了很多资料之后决定再做一个索引表，索引表中保存各个城市在数据库中的起始位置和终点位置，然后查询天气数据的时候就对过滤器加一个区间，使得过滤器在指定区间内查询，这样查询速度应该会快很多。