【前言】

　　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以字典序排序所有數據，這樣的話北京的信息在前面，所以就能很快查到，同時造成了各個城市查詢時間不一致的情況。

　　考慮到這個問題，那麽項目中其他功能勢必會同樣的影響，所以這個問題必須抓緊時間解決。

【解決過程】

　　查了很多資料之後決定再做一個索引表，索引表中保存各個城市在數據庫中的起始位置和終點位置，然後查詢天氣數據的時候就對過濾器加一個區間，使得過濾器在指定區間內查詢，這樣查詢速度應該會快很多。

畢設開發日誌2017-11-30