在開發工業系統的數據采集功能相關的系統時，由於數據都是定時上傳的，如每20秒上傳一次的時間序列數據，這些數據在經過處理和計算后，變成了與時間軸有關的歷史數據（與股票數據相似，如下圖的車輛行駛過程中的油量曲線、歷史軌跡數據等）。當采集點多的時候，如上萬個采集終端，再加上時間的累積，數據表會變得越來越大。數據庫會越來越難以維護。
對歷史數據操作的功能有歷史數據的查詢、統計圖表曲線顯示等等。而這些基於組合條件的歷史查詢功能和圖表顯示功能對數據庫的壓力可不小，如果聽之任之，則海量的數據查詢、統計計算會非常慢，用戶體驗很差。所以對於這種類型的表結構設計的時候，要制定好策略，避免以后再進行變動就麻煩了。
常規的策略就是分表。減少單一數據表的容量，通過增加合並查詢和計算的邏輯的復雜度來換取減輕查詢對數據庫的壓力。
1 表設計
1.1 設計思想
- 減少冗余數據的存儲
- 數據寫入時進行預運算
- 通過降低記錄量提高系統的響應能力
- 降低磁盤的讀操作
1.2 模型結構
GPS軌跡日志數據表保存原始的定位信息數據，索引表為日志數據表的索引信息內容，預處理模塊完成新數據的預處理運算功能，保持索引表的信息與日志數據表的信息一致。
預處理模塊建議為數據庫內部的存儲過程，保證對數據表操作的效率性能，通訊服務器以訪問存儲過程的方式，完成數據保存的事務處理。
1.3 模型原理
1.3.1 數據量
日志數據表最多保存四個月的定位信息數據，最高的記錄為246億條數據，數據量為2.3T（2012年9月-12月）。
索引表為日志數據表的索引信息，保留三個月零一天的車輛定位信息，每車每天為一條記錄，最高數據量為432萬，每個車輛每天的摘要信息保存在二進制的字段里。
摘要的數據內容包含定位時間、速度、里程、經度、緯度、角度狀態信息，摘要在索引表里按規定的報文方式保存在索引表的二進制字段里，每個車輛一天產生的定位數據量為4320條，速度為0的定位信息所占比例為40%-60%左右，因此摘要里只記錄有速度的定位數據，每車每天的實際摘要的數據量為2000左右。每個摘要信息量為30Bytes，因此每車每天產生的摘要為58K Bytes左右。
注：從統計角度考慮，摘要信息里也許會包括速度為0的定位信息。
1.3.2 讀取性能
索引表根據業務操作的需要分為“最新定位索引表”、“三個月定位索引表”及“相關的統計索引表”。由於索引表里的記錄量在百萬級別內，可以實現毫秒級別的響應能力，所有的定位摘要數據保存在一個BLOB的二進制字段里，一次性快速讀取出58K Bytes左右的數據，即可獲得全天的車輛定位數據，避免數據庫在磁盤上隨機檢索定位數據讀而引起I/O性能瓶頸。
1.3.3 索引數據的寫操作
每車每天的索引信息的更新，通過預處理模塊完成，如果索引表里已經存在該車該天的記錄，則進行二進制字段的更新，否則自動添加新的記錄。新的車輛定位摘要信息通過規定好的報文協議直接追加到二進制字段后面。
每天通過后台作業的方式，定時刪除索引表里最早一天的數據。一次刪除的最大記錄量為4.9萬條（2012年12月31日）。
1.3.4 索引數據的讀
讀取車輛在某時間段內的定位數據，會從索引表里獲得到相應天數的記錄數，通過對BLOB字段進行數據協議的處理，獲得定位摘要的記錄集。
協議的解析工作可以由預處理模塊解析，然后反轉為表形式返回給web應用，也可以數據庫直接交付給web應用服務器二進制數據，由web應用服務器完成數據的解析操作。
1.3.5 報表統計
索引表里二進制數據摘要的狀態可以支持8種不同的狀態，每個定位數據可以同時具有8種不同的狀態，比如超速、偏移路線等，可以直接通過索引表進行統計，快速實時的獲取最新的報表數據。
技術支持 By 省厓 QQ:2252224326 2252224326@qq.com 版權所有 http://blog.sina.com.cn/u/6029512413