上一章聊到在車聯網或物聯網中對數據庫的需求,以及 IoTDB 的總體架構,詳情請見:git
時序數據庫 Apache-IoTDB 源碼解析之系統架構(二)github
打一波廣告,歡迎你們訪問IoTDB 倉庫,求一波 Star 。歡迎關注頭條號:列炮緩開局,歡迎關注 OSCHINA博客sql
這一章主要想聊一聊:數據庫
假如咱們的邏輯上的數據表格式及數據爲:apache
時間戳 | 人名 | 體溫 |
---|---|---|
1580950800 | 張三 | 36.5 |
1580950800 | 李四 | 36.9 |
1580950800 | 王五 | 36.7 |
那麼他出如今硬盤格式就是:架構
在我理解上,行式數據是把邏輯相關的數據在硬盤上放到一塊兒,好比上面的例子,咱們能夠稱之爲體溫表,因此在邏輯上:時間、人、體溫,就成爲了邏輯上緊密相關的數據。編碼
因此把相關的數據的硬盤上的組織方式也變成連續的,假如我須要取 張三
的數據,那麼當你讀出 R1 文件塊的時候,就是讀出了全部 張三
相關的數據。.net
列式數據在我理解是將物理相關的數據放到一塊兒,好比時間是一類(long
類型)、名字是一類(string
類型)、體溫是一類(float
類型)。固然這種硬盤的組織方式,相比起行式數據庫,在取拼回體溫表的結構的時候,速度就慢了不少,由於你要分別取 C一、C二、C3 文件塊,而後還要寫個容器往裏 Set()
。那麼列式數據存儲方式相比於行式存儲優點在哪裏呢?設計
有一種叫法是只讀投影列,避免查詢無關列的讀取。列式存儲的優點在於查詢的列數遠小於總屬性數量,就能少讀不少數據。可能讀起來很是繞口,舉個例子:好比我須要查體溫大於 36 度的體溫值,sql : select 體溫 FROM table WHERE 體溫 > 36
。這時候若是是列式存儲只須要讀出 C3 數據塊就能夠一次性查到全部數據。而行式數據庫中,則須要讀出 R一、 R二、 R3。在第二章中介紹到物聯網中的時序數據的特色:存量數據很是大,若是遍歷幾百億數據,時間差距明顯就拉開了。3d
由於物理相關的數據他們類型相同,可使用多種多樣的編碼方式,好比 IoTDB 中就提供了 8 種編碼方式,這個不具體聊,等後面章節再說。
咱們繼續拿時間列舉例子,咱們能夠把時間列改造爲差值存儲: 好比 C1 文件塊中先存儲基礎值 1580950800 那麼他後面的數據值只須要存儲 0 就能夠,存儲的數字小了,那麼佔用的存儲空間確定也就小了,當數字特別大且差值比較小的時候,這用編碼方式就很是有意義。固然還有不少好玩兒的編碼方式,歡迎持續關注。
爲何叫 TsFile ?我聽意思應該是做爲 TimeSeriresFile 的縮寫,也就是時序數據文件的意思。
這是一個數據被刷入磁盤後的縮減版 TsFile 格式,咱們還拿上面的數據舉例,用來直觀的解釋 TsFile 中出現的一些名詞,假如個人數據爲:
時間戳 | 人名 | 體溫 | 心率 |
---|---|---|---|
1580950800 | 張三 | 36.5 | 70 |
1580950800 | 李四 | 36.9 | 80 |
1580950800 | 王五 | 36.7 | 100 |
1580950911 | 王五 | 36.6 | 90 |
上面的數據刷新到磁盤上後會對應關係以下:
看到這裏應該能理解每一個英文名詞的意思:
ChunkGroup 中包含多個 Chunk,Chunk 中包含多個 Page ,Page 中 包含多個 時間點和數據項
回想上面提到的 SQL : select 體溫 FROM 王五 WHERE 體溫 > 36
, 在 TsFile 中,只要在文件中找到 王五
的 ChunkGroup ,並在 ChunkGroup 中找到 體溫
的 Chunk,而後從第一個 Page 開始遍歷就完成了。
介紹完了 Chunk 和 ChunkGroup 的概念,那麼若是 Chunk 和 ChunkGroup 很是多的時候,TsFile 怎麼來設計才能快速的定位並找到合適的 ChunkGroup 的呢?TsFile 怎樣才能作到損壞時的檢測或者保證傳遞過程的完整性呢?歡迎持續關注。。。
有興趣的朋友能夠查看:官方 Github 中的 TsFile 文檔,瞭解更多詳細信息。