エキナセアタイミングデータベースファイル圧縮形式

エキナセアタイミングデータベーステーブル毎日、データは次のように、それらの特性は、データファイルは、通常、圧縮ファイルに分割され、データファイルに格納されています。

簡易ファイル:書き込みをサポートし、より多くのディスクスペースを取り、ページファイルには、各ページには、固定され、各データ・ページには、いくつかの時間のために1つのデバイスのみのデータを格納している、ユニットとして管理することが 64KB

アーカイブ:、二段圧縮を使用して書き込みデータをサポート少ないディスクスペースをとらない。データはデータブロックに格納され、記憶装置からの時間、各データ・ブロックのサイズの範囲の各データブロックを、それぞれデバイスデータを順次読み出す高性能で、連続的にディスク上に格納されました。

松果体配列データベースに、新たに書き込まれたデータは、(一定の条件が満たされた場合、通常のファイルとして格納されている 1つのデータ圧縮上のシステム。2. 以前の時間ウィンドウより書き込まれたデータファイル)システムは、通常のファイルが圧縮されて変換します。

このドキュメントインスタンス内のすべてのデータがある readings_20161115.cdat :ファイル、ファイル生成プロセス参照ブログhttps://my.oschina.net/u/4204276/blog/3105248

この文書では詳細に松果体タイミングデータベース記述する(PinusDBのV1.3)圧縮ファイル形式を。圧縮されたファイル構造は次のとおりです。

 

声明は、サンプル表のテーブルを作成します。

1  作成する テーブル読み取り
 2  3    DEVIDのBIGINT 4    TSTAMPの日時5    battery_levelのBIGINT 6    battery_status列、
 7    battery_temperature real3、
 8    cpu_avg_1min real3、
 9    cpu_avg_5min real3、
 10    cpu_avg_15min real3、
 11    MEM_FREE BIGINT 12    mem_used BIGINT 13    RSSI BIGINT 
14

1. ヘッダ

図ヘッダは注意、以下の:リトルエンディアンに保存されているすべての整数を。

場所

サイズバイト

説明

0

16

ヘッダ文字列、現在のバージョンストア文字列「PDB COMPRESS 1」

16

4

データ・ページ・サイズの未使用の圧縮ファイル

20

4

フィールドの数

24

4

保存された現在のデータファイルを使用してエンコードされたファイルの日、すなわち1970年1月1日までの日数を

28

4

ファイルの種類、共通ファイル1 、ファイル圧縮2

32

860 * 64

860の情報の列は、各列が含まれています。

列名:48 バイトのフィールドタイプ:4 バイト、パディング12 バイト、各列64のバイト

55072

10460

充填

65532

4

ヘッダ前65532 バイトのCRC

 

ファイルヘッダの例:

 

 

 

前記底部までのラベル部分のトップ:

0B 00 00 00:テーブルが有することを示すフィールド数、11個のフィールドを

E0 42 00 00:日はコーディング、0x42E0 すなわち17120である2016年11月15日までの距離1970年1月1日の数日

02万人が:ファイルのエンコーディングは、02は圧縮されたファイルを表し

次の部分は、フィールド名とタイプ、および最終的にはファイルヘッダである CRC

2 ブロック

圧縮されたデータファイルに格納されたデータ・ブロックの基本単位であり、いくつかの時間のための記憶装置のデータブロックは、使用してコンテンツデータ ZLIBは、各データ・ブロック・サイズを圧縮します。

次のようにデータブロック内の構造は次のようになります。

 

 コンテンツデータブロック構造

MAGC:4 バイト、データブロックを識別するためのマジックナンバー、(0x7CEF82D9)と充填ブロック(0xD9EF7C82)。

DATALEN:4 使用バイト、ZLIB 圧縮後のデータ長。

後にデータ構造の内容を抽出

pageCrc:4 バイト、全体のデータCRC

DATALEN:4 バイト、非圧縮のデータ長

DEVID:8 バイト、デバイスID

fieldCnt:2 バイト、フィールドの数

RECCNT:データ数

フィールドの値が格納構造

まず varintは、次のようにすべてのデータが格納されているすべてのデータ、および順次格納のメモリ長をコードします。

TSTAMP:以来TSTAMPの値がインクリメントされ、第一メモリから数1970年1月10日:0:0 ミリ秒で、その後はデータのミリ秒数の間の差に格納されたvarint コードストレージ。

BOOL 型:各値が占める「ビット0を表し、falseに1。示しtrueに

BIGINT タイプ:最初の数エンコーダメモリ、差分符号化方式の数にその後保存:最初のジグザグ符号化さvarint 符号化されます。

他のタイプのデータソースを参照してください。

実際の例:ここに readings_20161115.cdat 最初のデータ・ページが説明します。

 マーカー部分は、データブロックとデータブロックの現在の長さとして表され(0x4F5F すなわち、20319 バイト、次は20319 用いバイトZLIB 圧縮されたデータを。

次の図:

展開データの前方及び後方上部にはブロック 48 バイトの内容を、

下半分のデータソース devces_big_readings.csv demo000000 最初のいくつかのデータ・デバイス。

すなわち、符号化データの下半分は、上半分に、すなわちスクリーンショットのみを含む時間フィールド格納され TSTAMPを

次のようにデータブロック構造に対応し、マーク部の意味を見ることができます。

F0 AC 00 00:非圧縮データの長さ、即ち:44272がにzlib 半分以下に圧縮された元のデータを。

1,027,000,000,000,000 :デバイスID 、すなわち:現在のデータベース記憶装置イドとして万のデータ。

0B:00 各データの表現が有する11 列が。

A0 05:すなわち、データページに含まれるデータの数を示す:このブロックストア1440のデータの断片。

E3 21:表しTSTAMPのために、値、データ長をvarint コーディング、すなわち:次4323のストレージのバイトは、1440 記事TSTAMPの値。

80 DC EE 86 2B BE:最初TSTAMPのための値varint 符号化、復号化がある:14792.112億の距離を示す1970年1月10日:0:0 ミリ秒の数は、GMTに変換:2016年11月15日20:0:0 、に対応する最初のデータの下半分「2016-11-1507:00:00〜05」(注ゾーン

B0のEA 01:順序で値との差の電流値を示しvarintの符号化、復号化される:30,000 である30 秒。

 他のデータは、コードを解析するための参考として組み込まれてもよいです。

 二段圧縮圧縮ファイル:

第一段階:符号化された差分データが格納されている(異なる方法で異なるデータタイプに対応します)。

第二段階:圧縮されたデータブロック。

 充填ブロック

フィラーブロックヘッダと異なるデータベースの唯一のマジックナンバー、データ無意味なコンテンツ。メインインデックスブロックがに揃えられ 8KB

フィラーブロックは、ブロック終了センチネルとして読み取ることができます。

 3 インデックス・ブロックとファイルの終わり

各データブロックは、に対応 blkIdx 、各デバイスblkIdx 時系列順に一緒に格納されています。

各デバイスは、に対応 devIdx devIdxはデバイスポインティングblkIdx 全て、devIdx 装置によるID 格納された配列。

その最後のファイル、圧縮ファイルの末尾 32のデバイス情報の数を含むバイトの内容は、デバイスのインデックス位置、各部の構造を次のように

ため DEVID 、保存ファイルの情報の終わりに基づいてデバイス検索するためのデータを照会するために、ID 位置とバイナリ検索を使用して、アレイの数を開始し、インデックスの全てのデータブロックが、再使用時間に基づいて、指定されたデバイス、開始位置へアクセスし、デバイスの数を発見しましたバイナリ・サーチ、データ・ブロックの取得位置とサイズ。最終的なデータブロックにデータを読み込んで解析します。

 詳細については、ソースコードとデータファイルを生成するために組み合わせることができます。

おすすめ

転載: www.cnblogs.com/zhangqhn/p/11627091.html