clickhouse性能テスト

注意:本テストは公式サイトのデータセットを使用して、公式サイトの集約操作が多すぎるため、いくつかのフィルタリングされていない集約操作を書いて、本テストは限界テストに属して、実際の業務の中の集約操作はきっと多くのフィルタリング操作があります

一.テーブルの作成とデータのインポート

テーブルの作成:ddlが同期していない各ノードにテーブルを作成する必要があります

create database test ;
use test ;
CREATE TABLE ontime
( Year UInt16,
    Quarter UInt8,
    Month UInt8,
    DayofMonth UInt8,
    DayOfWeek UInt8,
    FlightDate Date,
    UniqueCarrier FixedString(7),
    AirlineID Int32,
    Carrier FixedString(2),
    TailNum String,
    FlightNum String,
    OriginAirportID Int32,
    OriginAirportSeqID Int32,
    OriginCityMarketID Int32,
    Origin FixedString(5),
    OriginCityName String,
    OriginState FixedString(2),
    OriginStateFips String,
    OriginStateName String,
    OriginWac Int32,
    DestAirportID Int32,
    DestAirportSeqID Int32,
    DestCityMarketID Int32,
    Dest FixedString(5),
    DestCityName String,
    DestState FixedString(2),
    DestStateFips String,
    DestStateName String,
    DestWac Int32,
    CRSDepTime Int32,
    DepTime Int32,
    DepDelay Int32,
    DepDelayMinutes Int32,
    DepDel15 Int32,
    DepartureDelayGroups String,
    DepTimeBlk String,
    TaxiOut Int32,
    WheelsOff Int32,
    WheelsOn Int32,
    TaxiIn Int32,
    CRSArrTime Int32,
    ArrTime Int32,
    ArrDelay Int32,
    ArrDelayMinutes Int32,
    ArrDel15 Int32,
    ArrivalDelayGroups Int32,
    ArrTimeBlk String,
    Cancelled UInt8,
    CancellationCode FixedString(1),
    Diverted UInt8,
    CRSElapsedTime Int32,
    ActualElapsedTime Int32,
    AirTime Int32,
    Flights Int32,
    Distance Int32,
    DistanceGroup UInt8,
    CarrierDelay Int32,
    WeatherDelay Int32,
    NASDelay Int32,
    SecurityDelay Int32,
    LateAircraftDelay Int32,
    FirstDepTime String,
    TotalAddGTime String,
    LongestAddGTime String,
    DivAirportLandings String,
    DivReachedDest String,
    DivActualElapsedTime String,
    DivArrDelay String,
    DivDistance String,
    Div1Airport String,
    Div1AirportID Int32,
    Div1AirportSeqID Int32,
    Div1WheelsOn String,
    Div1TotalGTime String,
    Div1LongestGTime String,
    Div1WheelsOff String,
    Div1TailNum String,
    Div2Airport String,
    Div2AirportID Int32,
    Div2AirportSeqID Int32,
    Div2WheelsOn String,
    Div2TotalGTime String,
    Div2LongestGTime String,
    Div2WheelsOff String,
    Div2TailNum String,
    Div3Airport String,
    Div3AirportID Int32,
    Div3AirportSeqID Int32,
    Div3WheelsOn String,
    Div3TotalGTime String,
    Div3LongestGTime String,
    Div3WheelsOff String,
    Div3TailNum String,
    Div4Airport String,
    Div4AirportID Int32,
    Div4AirportSeqID Int32,
    Div4WheelsOn String,
    Div4TotalGTime String,
    Div4LongestGTime String,
    Div4WheelsOff String,
    Div4TailNum String,
    Div5Airport String,
    Div5AirportID Int32,
    Div5AirportSeqID Int32,
    Div5WheelsOn String,
    Div5TotalGTime String,
    Div5LongestGTime String,
    Div5WheelsOff String,
    Div5TailNum String
) ENGINE = MergeTree(FlightDate, (Year, FlightDate), 8192);

CREATE TABLE ontimetest AS ontime ENGINE = Distributed(perftest_3shards_1replicas, test, ontime, rand());

データのダウンロード

for s in `seq 1987 2017`
do
for m in `seq 1 12`
do
wget http://transtats.bts.gov/PREZIP/On_Time_On_Time_Performance_${s}_${m}.zip
done
done

データのインポート

for i in *.zip; do echo $i; unzip -cq $i '*.csv' | sed 's/\.00//g' | clickhouse-client --host 192.168.121.41 --query="INSERT INTO test.ontimetest FORMAT CSVWithNames"; done

二.パフォーマンステスト

構成の説明
配置:3台の機械、各機械32メモリ、200 Gディスクデータ量:10 G、3.4億本、各109個のフィールド
count性能テスト

select count(1) from
(select ArrTime,CRSArrTime,FlightDate from ontimetest limit 200000000) t1 ;

1000万:0.543 15.81 MB

1億:0.863 187.58 MB

2億:0.913 261.31 MB

3億:1.181 485.01 MB

 
groupby性能テスト

SELECT
    OriginCityName,
    DestCityName,
    count(*) AS flights
FROM (select OriginCityName,DestCityName from ontimetest limit 100000000) t1   GROUP BY OriginCityName, DestCityName ORDER BY flights DESC LIMIT 20 ;

100万0.258 42.72 MB

1000万1.336 s 438.28 MB

1億11.186 s 4.47 GB

2億21.983 s 8.89 GB

3億30.538 sec 13.32 GB

join性能テスト

select * from
(select ArrTime,CRSArrTime,FlightDate from ontimetest limit 100000000) t1
ALL INNER JOIN (select ArrTime,CRSArrTime,FlightDate from ontimetest  limit 10000000) t2 on t1.ArrTime=t2.CRSArrTime limit 100 ;

1千万join 10万0.606 s 8.29 MB

億join 10万0.684 s 8.55 MB

2億join 10万0.962 s 7.99 MB

3億join 10万1.088 s 8.08 MB

1千万join 100万11.756 s 13.03 MB

億join 100万11.795 s 13.27 MB

2億join 100万11.972 s 13.50 MB

3億join 100万12.825 s 14.47 MB

1千万join 1000万150.931 s 42.33 MB

億join 1000万164.897 s 43.50 MB

2億join 1000万168.973 s 46.99 MB

3億join 1000万169.6949.63 MB

 
パフォーマンステストの概要:

countでは、速度が速く、消費メモリが大きい

groupbyでは、速度が速く、消費メモリが大きい

joinでは速度が速く(sparkに比べてリアルタイムクエリーシステムとしては遅い)、消費メモリは小さいが、消費CPUは

大きい.
その他の点:

コンカレントは小さく、公式サイトのクエリーは100 Queries/secondを提案しているので、ビジネス型の高コンカレントクエリー

には向いていません.

列式ストレージ:データフォーマットが似ているため、圧縮しやすく、IOの消費を減らす(hadoopは行ストレージであり、データのロードに時間がかかる).カラム式のクエリーでは高速ですが、クエリーフィールドが多い場合は

より遅いです.
位置:

のリアルタイム処理では、処理されたデータ量はmysqlよりはるかに大きいが、countとgroupbyはメモリを消費することが多く、同時に高い場合、業務サーバは耐えられない.groupby、joinクエリー時の性能はやはり素晴らしいレベルの応答の要求に達することができません;コンカレントは小さく、100 Queries/second;したがって、ビジネス型高同時リアルタイムクエリー

には適していません.

バッチ処理では、そのカラムストレージの設計により、IOの消費を低減するなどの原因で計算性能がspark,hiveをはるかに超えている.100 Queries/secondはsparkの数十個の同時タスクの数よりはるかに高い.したがってhadoopクラスタの代わりにバッチオフラインフレームワーク

として使用することができる.