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

1. 方案目標

該方案需要滿足以下幾點：

支持人員當天軌跡快速獲取（查詢）。

支持軌跡高並發讀、寫（實際項目中軌跡高並發讀情況很少）。

保證所有（歷史）軌跡數據的完整性、不丟失。

2.方案探討詳細描述

2.1支持軌跡快速查詢——軌跡日誌文件方案

海量數據高效存儲、查詢，這個場景本身是比較適合NoSQL數據庫運用的，但是考慮到該方案實施的難度（對工程實施、維護、研發成本），僅僅為了解決軌跡而采用該方案不是一個最好的選擇。

這裏，我們引用日誌的概念。設想將每天產生的軌跡以日誌文本形式來存儲，定義好日誌的存儲規則，那麽我們的軌跡查詢將變化成軌跡日誌文件的檢索和解析，磁盤檢索的效率將大大提高。

該方案涉及到的核心問題便是，軌跡日誌的存儲規則。

2.2支持軌跡高並發讀、寫——軌跡日誌存儲規則定義

針對每天生成的軌跡建立一個以日期命名的文件夾，應該是可以肯定的。

但是，在日期文件夾中，是針對每個時段建立一個軌跡文件，還是針對每個人建立一個日誌文件則是需要我們進一步討論的。

2.2.1分時段記錄優缺點討論

優點：

a.文件數量少，最多24個，如果保持住每個時段的日誌文件連接，寫入操作高並發支持會很好。

b.針對以時間段查詢、並且不分人員獲取所有軌跡的場景，十分合適，適合GPS廠家的需求。

缺點：

a.我們的運用場景更多的是查詢單個人員當天的所有軌跡，如果按照這個規則，那麽軌跡查詢得遍歷24個文件，還得解析各文件獲取對應人員的軌跡。

2.2.2分人記錄優缺點討論

優點：

a.很符合我們的業務場景，每次單人單天軌跡查詢時，只需要按照軌跡存儲規則就可以獲取到該人員的對應軌跡文件。

b.針對前端軌跡展示業務，可以將軌跡文件視做靜態資源而進行靜態伺服，前端直接訪問解析。

c.針對後臺進行軌跡分析，由於該文件大小很小，加載進入後臺進行分析也沒有IO瓶頸。

缺點：

a.由於人員一般會比較多，如果分人存儲，假設有1000個人，那麽等於有1000個日誌文件。高頻率對1000個文件分別進行寫入操作，可能出現IO瓶頸。

2.2.3規則總結

經過認真分析，依然選擇分天分人規則，原因有以下幾點：

a.符合我們的業務場景運用。

b.針對高並發讀有很大優勢。

c.雖然理論上其有日誌文件多、高並發寫的劣勢。但是這兩點都可以進行避免。

日誌文件多的問題：由於日誌本身只是做記錄使用，可以再制定一個定時清理的任務，比如一個月清理一次，那麽即使1000個人，一個月3W個日誌分布在30個日誌文件夾，不是不能接受的。

高並發寫的問題：即使我們規定手機上報時間是5S，手機也並不是一個實時寫入的過程，而是還有一個批量上傳的參數。所以其更可能是兩分鐘或者更久批量上傳一次數據，那麽我們後臺讀取文件、寫入批量內容、關閉該文件，對IO的沖擊會大大減小。並且，由於是不同文件的操作，排隊等待一個文件操作的問題也會大大減小。

2.3歷史軌跡數據安全性、完整性——歷史軌跡表用作備份

針對我們之前的歷史軌跡表，應該繼續保留。日誌文件本身的安全性是不夠的，如果出現誤刪除等問題，軌跡數據將很容易丟失。

所以歷史軌跡表依然保存，定期做數據備份遷移。

3.針對實時軌跡存儲的說明

目前的實時軌跡存儲邏輯為，手機端批量上傳GPS時，將該人員離上傳時間最近的GPS點保存（saveorupdate）至tc_patrol_state表中。

該業務邏輯在多個已有項目中沒有發現性能瓶頸，可以保留。

4.項目中原有邏輯涉及調整的部分

a.手機端上報軌跡，增加對軌跡日誌文件的操作。

b.GIS端的前段軌跡展示、後臺軌跡信息挖掘，做相應修改。

c.MIS端如果有跟軌跡表相關聯的業務，需要做對應修改。

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

　　　　 如果您覺得本文確實幫助了您，可以微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^

軌跡系列——記某真實項目中軌跡存儲改造方案