軌跡系列10——記某真實項目中軌跡展現查詢效率優化方案三（彙總實驗）

文章版權由做者李曉暉和博客園共有，若轉載請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

1.    方案總體描述

1.1存儲

　　a.使用redis存儲當天全部人員的軌跡，在當天深夜進行redis中軌跡遷移。

　　b.軌跡存儲分爲軌跡日誌文件和歷史軌跡表兩部分。

　　c.日誌文件的存儲規則爲天天以日期命名新建一個文件夾，文件夾中分別創建以人員ID命名的存放該人員當天全部軌跡的文件。

　　d.手機端每一次數據批量上傳時，修改監督員狀態表中的實時軌跡數據。

1.2遷移

       a.redis中的數據每晚進行同步至日誌文件和軌跡表中的步驟，而後清空。

       b.軌跡日誌文件按期遷移（建議三個月）。

       c.歷史軌跡表按期備份遷移。

1.3採集

       手機端GPS採集上，經過對監督員運動場景分析調控GPS採集頻率，減小冗餘、無效GPS點，已在重慶多個項目中驗證能夠減小40%（或更多）的GPS數據量。  

1.4讀取

       a.讀取當天軌跡時，在redis中獲取。

       b.讀取歷史軌跡時，在軌跡日誌文件中獲取。

2.核心性能點測試

2.1Redis緩存一天軌跡點性能測試

       假設1000個監督員，每隔10S上報一個GPS點，一天工做8小時，那麼一天有2880個GPS點，這裏，咱們用整數2000個點來表示。那麼一天全部人員將產生200W個GPS數據。

       根據真實項目中的考察，杭州一天大概是150W個GPS點，寧波一天大概是100W個GPS點。因此，咱們測試的200W個GPS點是能夠涵蓋絕大部分項目場景的。

如今，咱們測試若是存儲一天的全部軌跡（200W個），軌跡信息只包含人員ID、X、Y、time，一共將佔用多少內存空間。

　　

       實驗測得，一共佔用了233M的內存空間。針對如今的服務器內存空間，是能夠接受的。

2.2Redis數據遷移至文本中的IO測試

       這裏，將Redis中的數據分別遷移至1000我的員對應的各類軌跡日誌中所需的時間進行了測試：

　　

　                              　

       單線程寫入1000個日誌文件只耗時37S。1000個日誌文件（200W個GPS點）所佔用的存儲空間是109M。

       針對這個測試，數據轉移至文件是沒有IO瓶頸的，軌跡日誌文件一個月大概佔用3G存儲空間，三個月是9G，能夠接受。

2.3實驗總結

       Redis存儲一天全部軌跡數據，軌跡數據寫入軌跡日誌，均沒有明顯的性能和存儲瓶頸，是能夠採用的。

       而且以上咱們採用的是200W個軌跡點作的測試，若是將GPS採集優化利用上，GPS數據量能夠減小至100W個，那麼以上全部測試效果會更好。 而目前軌跡量最大的杭州項目，利用GPS採集優化，150W的軌跡量也能夠減小至100W個如下。

 

　　　　　　　　　　　　　　　　　　　　　　　　-----歡迎轉載，但保留版權，請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

                                                                      　　　　  若是您以爲本文確實幫助了您，能夠微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^