前一章節「Mars 數據庫的由來」中介紹了，Mars數據庫文件的設計思路，這裏詳細描述下，歷史文件的結構。數據庫
數據量計算操作系統
咱們考慮一下，一個點須要記錄哪些內容：時間，值，質量（表示值得好壞）。對於一個Double型的值，一共須要：8+8+1 =17 byte.咱們設計的數據庫要支持值按秒進行變化，故一個點一天的數據量有： 17*60*60*24/1024/1024=1.4 Mb 一臺機器若是支持100萬點，則一天的數據量有： 1.4 * 1000000 /1024/1024 = 1.336 Tb 若是是一年的數據量有： 1.336 * 365 = 487.6 Tb設計
數據庫文件結構設計code
根據上一節內容能夠看出，這個數據量是分紅龐大的，若是咱們把全部數據都存成一個文件，顯然是不合適的。32位Window操做系統中，單個文件最大隻能是2GB。因此咱們須要將這個文件進行拆分，具體怎麼拆分，拆分的依據是什麼，將是咱們下面討論的。工作流
因爲咱們要記錄的點的值的時間特性，因此咱們能夠將時間做爲咱們拆分文件的一個因素。根據上面的計算，一個100萬點的數據量和一個點數據量明顯也是不同，因此變量的個數也是咱們差分文件的一個因素。最後我肯定的格則以下：io
一個文件保存10萬點4個小時歷史數據，文件的名稱格式：數據庫名稱+TagBlockIndex+日期(yyyyMMdd)+ TimeBlockCount + TimeBlockIndexclass
在進行數據檢索查詢時，能夠快速肯定某個點在某個時間上的歷史值所在的文件。基礎
單文件內數據存儲結構變量
單個文件裏記錄的內容包括，點的信息+點的值信息。在一個文件內點的信息，可能會有屢次變更。因此我將整個文件拆分紅多個數據區（DataRegion）,一個數據區包括點的基礎信息+值。一個數據區內，一個點的值又被查分紅一個小的塊，這個塊叫作數據塊（DataBlock），每一個數據塊是獨立的個體，能夠對數據塊進行總體的壓縮。im
數據檢索
經過上面描述的結構，咱們在執行數據查詢時，具體工做流程以下：
- 獲取點的ID編號以及要查詢的時間，根據這些肯定所在的文件
- 在文件內部，再次根據時間肯定所在的數據區
- 根據時間以及ID讀取相應的數據塊
- 讀取整個數據庫，對數據塊進行解壓
- 對解壓後的數據進行查詢，肯定某個時間點上的值