clickhouseテーブルエンジン

26979 ワード
clickhouse予研

clickhouseテーブルエンジン

  • clickhouseテーブルエンジン
  • TinyLog
  • Memory
  • Merge
  • MergeTree
  • ReplacingMergeTree
  • SummingMergeTree
  • Distributed

    • clickhouseテーブルエンジン


    テーブルエンジン(テーブルのタイプ)が決定しました.
  • データの格納方式と位置は、どこまで書くか、どこからデータを読み出すか
    • である.
  • でサポートされているクエリーと
    • をサポートする方法
  • 同時データアクセス
  • インデックスの使用(存在する場合)
  • マルチスレッド要求
    • を実行できるかどうか
  • データ複製パラメータ
    • clickhouseのテーブルエンジンはたくさんありますが、以下にその中のいくつかを紹介し、他のエンジンに興味がある人は公式ドキュメントを調べることができます.

    TinyLog


    最も簡単なテーブルエンジンは、データをディスクに格納するためのものである.各列は個別の圧縮ファイルに格納、書き込み時にファイルの末尾にデータが付加される.
    このエンジンは同時制御されていません:
  • 同時にテーブルからデータを読み出して書き込むと、読み出し操作は異常を放出する.
  • 複数のクエリのテーブルを同時に書き込むと、データが破壊される.

    • このようなテーブルエンジンの典型的な使い方はwrite-onceである:まず1回だけデータを書き込む、それから必要に応じて複数回読み出す.このエンジンは比較的小さいテーブル(最大100万行)に適用する.小さなテーブルがたくさんある場合は、開くファイルよりも少ないので、このテーブルエンジンを使用するのが適切です.多数の小さなテーブルを持つと、パフォーマンスが低下する可能性がある.インデックスはサポートされていません.
    例:TinyLogエンジンのテーブルを作成し、データを挿入します.
    create table t(a UInt16,b String) ENGINE=TinyLog;
insert into t (a,b) values(1,'abc');

    データを保存するディレクトリ/var/lib/clickhouse/data/default/tには、次のディレクトリ構造が表示されます.
    [root@hadoop102 t]# ls
a.bin  b.bin  sizes.json

    a.binとb.binは圧縮された対応する列のデータであるsizes.jsonには各*が記録されている.binファイルのサイズ:
    [root@hadoop102 t]# cat sizes.json
{"yandex":{"a%2Ebin":{"size":"28"},"b%2Ebin":{"size":"30"}}}

    Memory


    メモリエンジンは、データが圧縮されていない元の形式で直接メモリに保存され、サーバの再起動データが消える.読み書き操作は互いにブロックする、インデックスはサポートされない.簡単な検索で非常に高い性能表現(10 G/sを超える)がある.
    一般的に使用する場所は多くなく、テストに使用する以外に、非常に高い性能が必要であり、同時にデータ量があまり大きくない(上限は約1億行)シーンである.

    Merge


    Mergeエンジン(MergeTreeエンジンと混同しない)自体はデータを記憶するが、任意の複数の他のテーブルから同時にデータを読み出すために用いることができる.読み取りは自動パラレルであり、書き込みはサポートされていない.読み取り時には、本当にデータを読み取るテーブルのインデックス(あれば)が使用される.
    Mergeエンジンのパラメータ:データベース名とテーブル名を一致させるための正規表現.
    例:t 1,t 2,t 3の3つのテーブルを作成する、次にMergeエンジンのtテーブルで接続する.
    create table t1(id UInt16,name String) ENGINE=TinyLog;
create table t2(id UInt16,name String) ENGINE=TinyLog;
create table t3(id UInt16,name String) ENGINE=TinyLog;

insert into t1(id,name) values(1,'first');
insert into t2(id,name) values(2,'second');
insert into t3(id,name) values(3,'three');

create table t (id UInt16,name String) ENGINE=Merge(currentDatabase(),'^t');

select * from t;
┌─ id ─┬─name────┐
│  1   │   first │
└──────┴─────────┴
┌─ id ─┬─name────┐
│  3   │   three │
└──────┴─────────┴
┌─ id ─┬─name────┐
│  2   │  second │
└──────┴─────────┴

    MergeTree


    clickhouseの中で最も強力なテーブルエンジンはMergeTree(連結ツリー)エンジンとこのシリーズの他のエンジンである.
    MergeTreeエンジンシリーズの基本的なコンセプトは、テーブルに大量のデータを挿入する場合、データクリップを笑わせて書き込み、バックグラウンドで一定のルールに従って統合することです.このようなポリシーは、挿入時にデータを変更(書き換え)して記憶するよりも効率的である.
    書式:
    ENGINE [=] MergeTree(data-column [,sampling_expression],(primary,key),index_granularity)

    パラメータの説明:
    data-column:タイプがdateのカラム名.clickhouseは自動的にこの列に基づいて毎月パーティションを作成します.パーティション名のフォーマットは「YYYYYMM」である.
    sampling_expression:サンプリング式.
    (primary,key):プライマリ・キー.タイプはTuple()
    index_granularity:インデックス粒度.すなわち、インデックスにおける隣接する「タグ」間のデータ行数である.8192は、シーンの大部分を適用可能とする.
    例:
    create table mt_table(date Date,id UInt8,name String) ENGINE=MergeTree(date,(id,name),8192);

insert into mt_table values('2019-05-01',1,'zhangsan');
insert into mt_table values('2019-06-01',2,'lisi');
insert into mt_table values('2019-05-03',3,'wangwu');

    /var/lib/clickhouse/data/default/mt_treeの下には、次のように表示されます.
    [root@hadoop102 mt_table]# ls
20190501_20190501_2_2_0		20190503_20190503_6_6_0		20190601_20190601_4_4_0		detached

 :
[root@hadoop102 20190601_20190601_4_4_0]# ls
checksums.txt		columns.txt		date.bin		date.mrk		id.bin		id.mark		name.bin		name.mrk		primary.idx
  • *.binは、カラムごとにデータを保存するファイル
    • である
  • *.mrk保存ブロックオフセット
  • primary.idxはプライマリ・キー・インデックス
    • を保存する

    ReplacingMergeTree


    このエンジンは、MergeTreeに基づいて、同じプライマリ・キーを持つ重複を削除する「重複データの処理」機能を追加するものである.データの重み付けはマージ中にのみ発生します.合併は未知の時間にバックグラウンドで行われるので、事前に計画することはできません.一部のデータはまだ処理されていない可能性がある.したがって、ReplacingMergeTreeは、バックグラウンドで重複するデータを消去してスペースを節約するのに適しているが、重複するデータが発生しないことを保証するものではない.
    書式:
    ENGINE [=] ReplacingMergeTree(date_column [,sampling_expression],(primary,key),index_granularity,[ver])

    MergeTreeよりもverパラメータが1つ多いことがわかります.このverはバージョン列を指します.
    例:
    create table rmt_table(date Date,id UInt8,name String,point UInt8) ENGINE=ReplacingMergeTree(date,(id,name),8192,point);

 :
insert into rmt_table values('2019-07-10',1,'a',20);
insert into rmt_table values('2019-07-10',1,'a',30);
insert into rmt_table values('2019-07-11',1,'a',20);
insert into rmt_table values('2019-07-11',1,'a',30);
insert into rmt_table values('2019-07-11',1,'a',10);

 optimize table rmt_table  merge, 
select * from rmt_table;
┌───────date─┬───id───┬───name──┬─point─┐
│ 2019-07-11 │      1 │  a       │   30 │
└────────────┴────────┴───────────┴─────┘

    SummingMergeTree


    このエンジンはMergeTreeから継承する.違いは、SummingMergeTreeテーブルのデータクリップをマージする場合、clickhouseは、マージされた行の数値データ型を持つ列の要約値を含む同じプライマリ・キーを持つすべての行を1行にマージすることである.プライマリ・キーの組み合わせにより、単一のキー値が多数のローに対応する場合、記憶領域を大幅に低減し、データ・クエリーの速度を速めることができ、加算できないカラムに対して、最初に現れる指をとることができる.
    構文:
    ENGINE [=] SummingMergeTree(date-column [,sampling_expreesion],(primary,key),index_granularity,[columns])

    columns–要約する列の列名を含むメタグループ
    例:
    create table smt_table(date Date,name String,a UInt16,b UInt16) ENGINE=SummingMergeTree(date,(date,name),8192,(a))

 :
insert into smt_table(date,name,a,b) values('2019-07-10','a',1,2);
insert into smt_table(date,name,a,b) values('2019-07-10','b',2,1);
insert into smt_table(date,name,a,b) values('2019-07-11','b',3,8);
insert into smt_table(date,name,a,b) values('2019-07-11','b',3,8);
insert into smt_table(date,name,a,b) values('2019-07-11','a',3,1);
insert into smt_table(date,name,a,b) values('2019-07-12','c',1,3);

 optimize table smt_table  merge, 
select * from smt_table;
┌───────date─┬──name──┬───a──┬────b───┐
│ 2019-07-10 │      a │  1     │   2 │
│ 2019-07-10 │      b │  2     │   1 │
│ 2019-07-11 │      a │  3     │   1 │
│ 2019-07-11 │      b │  6     │   8 │
│ 2019-07-12 │      c │  1     │   3 │
└────────────┴────────┴─────────┴─────┘

    2019-07-11,bのa列が併合加算、b列が8(b列が8のデータが最初に挿入されたためである.

    Distributed


    分散エンジンは、それ自体はデータを記憶するが、複数のサーバ上で分散クエリーを行うことができる.読み取りは自動的に並列する.読み込み時にリモートサーバテーブルのインデックス(あれば)が使用する.
    Distributed(cluster_name,database,table [,sharding_key])
    パラメータ解析:
    cluster_name-サーバプロファイルのクラスタ名、/etc/metrika.xmlで構成された
    database-データベース名
    table-テーブル名
    sharding_key-データスライスキー
    ケーススタディ:
  • hadoop 102,hadoop 103,hadoop 104にそれぞれ1つのテーブルt 
    create table t(id UInt16,name String) ENGINE=TinyLog;
    • が作成される.
  • 3 3台のマシンのtテーブルにいくつかのデータ
    insert into t(id,name) values(1,'zhangsan');
insert into t(id,name) values(2,'lisi');
    • を挿入する.
  • hadoop 102上に分散テーブル
    create table dis_table(id UInt16,name String) ENGINE=Distributed(perftest_3shards_1replicas,default,t,id);
    • を作成する.
  • disへtableに挿入するデータ
    insert into dis_table select * from t;
  • データ量
    select count(*) from dis_table;

┌─ count(*) ─┬
│  8   │ 
└───────────┴

select count(*) from t
┌─ count(*) ─┬
│  3  │ 
└───────────┴
    を見ると、各ノードの約1/3のデータを見ることができる.
    • 同時:CountDownLatchの使用
    Semantic WebとSemantic Tag