文章版權由作者李曉暉和博客園共有，若轉載請於明顯處標明出處：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/
如果您覺得本文確實幫助了您，可以微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^
