Пераклад артыкула падрыхтаваны спецыяльна для студэнтаў курса .
- гэта калоначная база дадзеных з адкрытым зыходным кодам. Гэта цудоўнае асяроддзе, дзе сотні аналітыкаў могуць хутка запытваць разгорнутыя дадзеныя, нават калі ўводзяцца дзясяткі мільярдаў новых запісаў у дзень. Выдаткі на інфраструктуру для падтрымкі такой сістэмы могуць дасягаць 100 тыс. долараў ЗША ў год, і патэнцыйна ўдвая менш, у залежнасці ад выкарыстання. У нейкі момант усталёўка ClickHouse ад Яндэкс Метрыкі ўтрымоўвала 10 трыльёнаў запісаў. Акрамя Яндэкса, ClickHouse таксама набыла поспех у Bloomberg і Cloudflare.
Два гады таму я правёў баз дадзеных з выкарыстаннем адной машыны, і яна стала бясплатным праграмным забеспячэннем для баз даных, якое я калі-небудзь бачыў. З тых часоў распрацоўнікі не пераставалі дадаваць фічы, у тым ліку падтрымку Kafka, HDFS і ZStandard сціску. У мінулым годзе яны дадалі падтрымку каскадавання метадаў сціску, і кадаваньне стала магчымым. Пры сціску дадзеных часавых шэрагаў gauge-значэнні могуць добра сціскацца з дапамогай дэльта-кадавання, але для лічыльнікаў (counter) будзе лепш выкарыстоўваць дэльта-ад-дэльты-кадаваньне. Добры сціск стала ключом да прадукцыйнасці ClickHouse.
ClickHouse складаецца з 170 тысяч радкоў C++ кода, за выключэннем іншых бібліятэк, і з'яўляецца адной з найменшых кодавых баз для размеркаваных баз дадзеных. Для параўнання, SQLite не падтрымлівае размеркаванне і складаецца з 235 радкоў кода на мове С. На момант напісання гэтага артыкула свой уклад у ClickHouse ўнеслі 207 інжынераў, і інтэнсіўнасць комітаў у апошні час павялічваецца.
У сакавіку 2017 года ClickHouse пачаў весці у якасці простага спосабу адсочваць распрацоўку. Яны таксама разбілі маналітны файл дакументацыі на іерархію файлаў на аснове Markdown. Праблемы і фічы адсочваюцца праз GitHub, і ў цэлым гэтае праграмнае забеспячэнне стала нашмат больш даступным у апошнія некалькі гадоў.
У гэтым артыкуле я збіраюся зірнуць на прадукцыйнасць кластара ClickHouse на AWS EC2 з выкарыстаннем 36-ядзерных працэсараў і NVMe-назапашвальніка.
АПДЭЙТ: Праз тыдзень пасля першапачатковай публікацыі гэтай пасады я паўторна запусціў тэст з палепшанай канфігурацыяй і дасягнуў значна лепшых вынікаў. Гэты пост быў абноўлены, каб адлюстраваць гэтыя змены.
Запуск кластара AWS EC2
Я буду выкарыстоўваць тры асобнікі c5d.9xlarge EC2 для гэтай пасады. Кожны з іх утрымоўвае 36 віртуальных ЦП, 72 ГБ АЗП, 900 ГБ назапашвальніка NVMe SSD і падтрымлівае 10-гігабітную сетку. Яны каштуюць $1,962/гадзіна кожны ў рэгіёне eu-west-1 пры запуску па патрабаванні. Я буду выкарыстоўваць Ubuntu Server 16.04/XNUMX LTS ў якасці аперацыйнай сістэмы.
Фаервол наладжаны так, што кожная машына можа звязвацца сябар з сябрам без абмежаванняў, і толькі мой IPv4-адрас занесены ў белы спіс SSH у кластары.
NVMe-назапашвальнік у стане працоўнай гатовасці
Для працы ClickHouse я ствару ў NVMe-назапашвальніку файлавую сістэму ў фармаце EXT4 на кожным з сервераў.
$ sudo mkfs -t ext4 /dev/nvme1n1
$ sudo mkdir /ch
$ sudo mount /dev/nvme1n1 /chПасля таго як усё наладжана, вы можаце ўбачыць кропку мантавання і 783 ГБ прасторы, даступнага ў кожнай з сістэм.
$ lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 87.9M 1 loop /snap/core/5742
loop1 7:1 0 16.5M 1 loop /snap/amazon-ssm-agent/784
nvme0n1 259:1 0 8G 0 disk
└─nvme0n1p1 259:2 0 8G 0 part /
nvme1n1 259:0 0 838.2G 0 disk /ch$ df -hFilesystem Size Used Avail Use% Mounted on
udev 35G 0 35G 0% /dev
tmpfs 6.9G 8.8M 6.9G 1% /run
/dev/nvme0n1p1 7.7G 967M 6.8G 13% /
tmpfs 35G 0 35G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 35G 0 35G 0% /sys/fs/cgroup
/dev/loop0 88M 88M 0 100% /snap/core/5742
/dev/loop1 17M 17M 0 100% /snap/amazon-ssm-agent/784
tmpfs 6.9G 0 6.9G 0% /run/user/1000
/dev/nvme1n1 825G 73M 783G 1% /chНабор дадзеных, які я буду выкарыстоўваць у гэтым тэсце, уяўляе сабой дамп дадзеных, які я сфармаваў з 1.1 мільярда паездак на таксі, вырабленых у Нью-Ёрку за шэсць гадоў. У блогу падрабязна распавядаецца аб тым, як я сабраў гэты набор даных. Яны захоўваюцца ў AWS S3, таму я налажу інтэрфейс каманднага радка AWS з дапамогай майго доступу і сакрэтных ключоў.
$ sudo apt update
$ sudo apt install awscli
$ aws configureЯ ўсталюю абмежаванне колькасці адначасовых запытаў кліента на 100, каб файлы загружаліся хутчэй, чым пры стандартных наладах.
$ aws configure set
default.s3.max_concurrent_requests
100Я спампоўваю набор дадзеных паездак на таксі з AWS S3 і захаваю яго на дыску NVMe на першым серверы. Гэты набор дадзеных складае ~ 104 ГБ у GZIP-сціснутым CSV-фармаце.
$ sudo mkdir -p /ch/csv
$ sudo chown -R ubuntu /ch/csv
$ aws s3 sync s3://<bucket>/csv /ch/csvЎстаноўка ClickHouse
Я ўсталюю дыстрыбутыў OpenJDK для Java 8, бо ён неабходзен для запуску Apache ZooKeeper, неабходнага для размеркаванай усталёўкі ClickHouse на ўсіх трох машынах.
$ sudo apt update
$ sudo apt install
openjdk-8-jre
openjdk-8-jdk-headless
Затым я ўсталёўваю зменную асяроддзі JAVA_HOME.
$ sudo vi /etc/profile
export JAVA_HOME=/usr
$ source /etc/profileЗатым я буду выкарыстоўваць сістэму кіравання пакетамі ў Ubuntu для ўстаноўкі ClickHouse 18.16.1, glances і ZooKeeper на ўсе тры машыны.
$ sudo apt-key adv
--keyserver hkp://keyserver.ubuntu.com:80
--recv E0C56BD4
$ echo "deb http://repo.yandex.ru/clickhouse/deb/stable/ main/" |
sudo tee /etc/apt/sources.list.d/clickhouse.list
$ sudo apt-get update$ sudo apt install
clickhouse-client
clickhouse-server
glances
zookeeperdЯ ствару каталог для ClickHouse, а таксама здзейсню некаторыя пераазначэнні канфігурацыі на ўсіх трох серверах.
$ sudo mkdir /ch/clickhouse
$ sudo chown -R clickhouse /ch/clickhouse
$ sudo mkdir -p /etc/clickhouse-server/conf.d
$ sudo vi /etc/clickhouse-server/conf.d/taxis.confГэта пераазначэнні канфігурацыі, якія я буду выкарыстоўваць.
<?xml version="1.0"?>
<yandex>
<listen_host>0.0.0.0</listen_host>
<path>/ch/clickhouse/</path>
<remote_servers>
<perftest_3shards>
<shard>
<replica>
<host>172.30.2.192</host>
<port>9000</port>
</replica>
</shard>
<shard>
<replica>
<host>172.30.2.162</host>
<port>9000</port>
</replica>
</shard>
<shard>
<replica>
<host>172.30.2.36</host>
<port>9000</port>
</replica>
</shard>
</perftest_3shards>
</remote_servers> <zookeeper-servers>
<node>
<host>172.30.2.192</host>
<port>2181</port>
</node>
<node>
<host>172.30.2.162</host>
<port>2181</port>
</node>
<node>
<host>172.30.2.36</host>
<port>2181</port>
</node>
</zookeeper-servers> <macros>
<shard>03</shard>
<replica>01</replica>
</macros>
</yandex>Затым я запушчу ZooKeeper і сервер ClickHouse на ўсіх трох машынах.
$ sudo /etc/init.d/zookeeper start
$ sudo service clickhouse-server startЗагрузка дадзеных у ClickHouse
На першым серверы я ствару табліцу паездак (trips), у якой будзе захоўвацца набор дадзеных паездак у таксі з выкарыстаннем рухавічка Log.
$ clickhouse-client --host=0.0.0.0
CREATE TABLE trips (
trip_id UInt32,
vendor_id String,
pickup_datetime DateTime,
dropoff_datetime Nullable(DateTime),
store_and_fwd_flag Nullable(FixedString(1)),
rate_code_id Nullable(UInt8),
pickup_longitude Nullable(Float64),
pickup_latitude Nullable(Float64),
dropoff_longitude Nullable(Float64),
dropoff_latitude Nullable(Float64),
passenger_count Nullable(UInt8),
trip_distance Nullable(Float64),
fare_amount Nullable(Float32),
extra Nullable(Float32),
mta_tax Nullable(Float32),
tip_amount Nullable(Float32),
tolls_amount Nullable(Float32),
ehail_fee Nullable(Float32),
improvement_surcharge Nullable(Float32),
total_amount Nullable(Float32),
payment_type Nullable(String),
trip_type Nullable(UInt8),
pickup Nullable(String),
dropoff Nullable(String),
cab_type Nullable(String),
precipitation Nullable(Int8),
snow_depth Nullable(Int8),
snowfall Nullable(Int8),
max_temperature Nullable(Int8),
min_temperature Nullable(Int8),
average_wind_speed Nullable(Int8),
pickup_nyct2010_gid Nullable(Int8),
pickup_ctlabel Nullable(String),
pickup_borocode Nullable(Int8),
pickup_boroname Nullable(String),
pickup_ct2010 Nullable(String),
pickup_boroct2010 Nullable(String),
pickup_cdeligibil Nullable(FixedString(1)),
pickup_ntacode Nullable(String),
pickup_ntaname Nullable(String),
pickup_puma Nullable(String),
dropoff_nyct2010_gid Nullable(UInt8),
dropoff_ctlabel Nullable(String),
dropoff_borocode Nullable(UInt8),
dropoff_boroname Nullable(String),
dropoff_ct2010 Nullable(String),
dropoff_boroct2010 Nullable(String),
dropoff_cdeligibil Nullable(String),
dropoff_ntacode Nullable(String),
dropoff_ntaname Nullable(String),
dropoff_puma Nullable(String)
) ENGINE = Log;
Затым я распакоўваю і загружаю кожны з CSV-файлаў у табліцу паездак (trips). Наступнае выканана за 55 хвілін і 10 секунд. Пасля гэтай аперацыі памер каталога дадзеных склаў 134 ГБ.
$ time (for FILENAME in /ch/csv/trips_x*.csv.gz; do
echo $FILENAME
gunzip -c $FILENAME |
clickhouse-client
--host=0.0.0.0
--query="INSERT INTO trips FORMAT CSV"
done)Хуткасць імпарту складала 155 МБ несціснутага CSV-кантэнту ў секунду. Я падазраю, што гэта было звязана з вузкім месцам у GZIP-дэкампрэсіі. Магчыма, хутчэй было распакаваць усе файлы gzip раўналежна, выкарыстаючы xargs, а затым загрузіць распакаваныя дадзеныя. Ніжэй прыведзена апісанне таго, што паведамлялася падчас імпарту CSV.
$ sudo glancesip-172-30-2-200 (Ubuntu 16.04 64bit / Linux 4.4.0-1072-aws) Uptime: 0:11:42
CPU 8.2% nice: 0.0% LOAD 36-core MEM 9.8% active: 5.20G SWAP 0.0%
user: 6.0% irq: 0.0% 1 min: 2.24 total: 68.7G inactive: 61.0G total: 0
system: 0.9% iowait: 1.3% 5 min: 1.83 used: 6.71G buffers: 66.4M used: 0
idle: 91.8% steal: 0.0% 15 min: 1.01 free: 62.0G cached: 61.6G free: 0
NETWORK Rx/s Tx/s TASKS 370 (507 thr), 2 run, 368 slp, 0 oth sorted automatically by cpu_percent, flat view
ens5 136b 2Kb
lo 343Mb 343Mb CPU% MEM% VIRT RES PID USER NI S TIME+ IOR/s IOW/s Command
100.4 1.5 1.65G 1.06G 9909 ubuntu 0 S 1:01.33 0 0 clickhouse-client --host=0.0.0.0 --query=INSERT INTO trips FORMAT CSV
DISK I/O R/s W/s 85.1 0.0 4.65M 708K 9908 ubuntu 0 R 0:50.60 32M 0 gzip -d -c /ch/csv/trips_xac.csv.gz
loop0 0 0 54.9 5.1 8.14G 3.49G 8091 clickhous 0 S 1:44.23 0 45M /usr/bin/clickhouse-server --config=/etc/clickhouse-server/config.xml
loop1 0 0 4.5 0.0 0 0 319 root 0 S 0:07.50 1K 0 kworker/u72:2
nvme0n1 0 3K 2.3 0.0 91.1M 28.9M 9912 root 0 R 0:01.56 0 0 /usr/bin/python3 /usr/bin/glances
nvme0n1p1 0 3K 0.3 0.0 0 0 960 root -20 S 0:00.10 0 0 kworker/28:1H
nvme1n1 32.1M 495M 0.3 0.0 0 0 1058 root -20 S 0:00.90 0 0 kworker/23:1HЯ вызвалю месца на NVMe-прывадзе, выдаліўшы зыходныя CSV-файлы, перш чым працягнуць.
$ sudo rm -fr /ch/csvПераўтварэнне ў калоначную форму
Рухавічок Log ClickHouse будзе захоўваць дадзеныя ў радкова-арыентаваным фармаце. Каб хутчэй запытваць дадзеныя, я канвертую іх у калоначны фармат з дапамогай рухавічка MergeTree.
$ clickhouse-client --host=0.0.0.0Наступнае выканана за 34 хвіліны і 50 секунд. Пасля гэтай аперацыі памер каталога дадзеных склаў 237 ГБ.
CREATE TABLE trips_mergetree
ENGINE = MergeTree(pickup_date, pickup_datetime, 8192)
AS SELECT
trip_id,
CAST(vendor_id AS Enum8('1' = 1,
'2' = 2,
'CMT' = 3,
'VTS' = 4,
'DDS' = 5,
'B02512' = 10,
'B02598' = 11,
'B02617' = 12,
'B02682' = 13,
'B02764' = 14)) AS vendor_id,
toDate(pickup_datetime) AS pickup_date,
ifNull(pickup_datetime, toDateTime(0)) AS pickup_datetime,
toDate(dropoff_datetime) AS dropoff_date,
ifNull(dropoff_datetime, toDateTime(0)) AS dropoff_datetime,
assumeNotNull(store_and_fwd_flag) AS store_and_fwd_flag,
assumeNotNull(rate_code_id) AS rate_code_id,
assumeNotNull(pickup_longitude) AS pickup_longitude,
assumeNotNull(pickup_latitude) AS pickup_latitude,
assumeNotNull(dropoff_longitude) AS dropoff_longitude,
assumeNotNull(dropoff_latitude) AS dropoff_latitude,
assumeNotNull(passenger_count) AS passenger_count,
assumeNotNull(trip_distance) AS trip_distance,
assumeNotNull(fare_amount) AS fare_amount,
assumeNotNull(extra) AS extra,
assumeNotNull(mta_tax) AS mta_tax,
assumeNotNull(tip_amount) AS tip_amount,
assumeNotNull(tolls_amount) AS tolls_amount,
assumeNotNull(ehail_fee) AS ehail_fee,
assumeNotNull(improvement_surcharge) AS improvement_surcharge,
assumeNotNull(total_amount) AS total_amount,
assumeNotNull(payment_type) AS payment_type_,
assumeNotNull(trip_type) AS trip_type,
pickup AS pickup,
pickup AS dropoff,
CAST(assumeNotNull(cab_type)
AS Enum8('yellow' = 1, 'green' = 2))
AS cab_type,
precipitation AS precipitation,
snow_depth AS snow_depth,
snowfall AS snowfall,
max_temperature AS max_temperature,
min_temperature AS min_temperature,
average_wind_speed AS average_wind_speed,
pickup_nyct2010_gid AS pickup_nyct2010_gid,
pickup_ctlabel AS pickup_ctlabel,
pickup_borocode AS pickup_borocode,
pickup_boroname AS pickup_boroname,
pickup_ct2010 AS pickup_ct2010,
pickup_boroct2010 AS pickup_boroct2010,
pickup_cdeligibil AS pickup_cdeligibil,
pickup_ntacode AS pickup_ntacode,
pickup_ntaname AS pickup_ntaname,
pickup_puma AS pickup_puma,
dropoff_nyct2010_gid AS dropoff_nyct2010_gid,
dropoff_ctlabel AS dropoff_ctlabel,
dropoff_borocode AS dropoff_borocode,
dropoff_boroname AS dropoff_boroname,
dropoff_ct2010 AS dropoff_ct2010,
dropoff_boroct2010 AS dropoff_boroct2010,
dropoff_cdeligibil AS dropoff_cdeligibil,
dropoff_ntacode AS dropoff_ntacode,
dropoff_ntaname AS dropoff_ntaname,
dropoff_puma AS dropoff_puma
FROM trips;Вось як выглядаў glance-вывад падчас аперацыі:
ip-172-30-2-200 (Ubuntu 16.04 64bit / Linux 4.4.0-1072-aws) Uptime: 1:06:09
CPU 10.3% nice: 0.0% LOAD 36-core MEM 16.1% active: 13.3G SWAP 0.0%
user: 7.9% irq: 0.0% 1 min: 1.87 total: 68.7G inactive: 52.8G total: 0
system: 1.6% iowait: 0.8% 5 min: 1.76 used: 11.1G buffers: 71.8M used: 0
idle: 89.7% steal: 0.0% 15 min: 1.95 free: 57.6G cached: 57.2G free: 0
NETWORK Rx/s Tx/s TASKS 367 (523 thr), 1 run, 366 slp, 0 oth sorted automatically by cpu_percent, flat view
ens5 1Kb 8Kb
lo 2Kb 2Kb CPU% MEM% VIRT RES PID USER NI S TIME+ IOR/s IOW/s Command
241.9 12.8 20.7G 8.78G 8091 clickhous 0 S 30:36.73 34M 125M /usr/bin/clickhouse-server --config=/etc/clickhouse-server/config.xml
DISK I/O R/s W/s 2.6 0.0 90.4M 28.3M 9948 root 0 R 1:18.53 0 0 /usr/bin/python3 /usr/bin/glances
loop0 0 0 1.3 0.0 0 0 203 root 0 S 0:09.82 0 0 kswapd0
loop1 0 0 0.3 0.1 315M 61.3M 15701 ubuntu 0 S 0:00.40 0 0 clickhouse-client --host=0.0.0.0
nvme0n1 0 3K 0.3 0.0 0 0 7 root 0 S 0:00.83 0 0 rcu_sched
nvme0n1p1 0 3K 0.0 0.0 0 0 142 root 0 S 0:00.22 0 0 migration/27
nvme1n1 25.8M 330M 0.0 0.0 59.7M 1.79M 2764 ubuntu 0 S 0:00.00 0 0 (sd-pam)У апошнім тэсце некалькі слупкоў былі пераўтвораны і пералічаны. Я выявіў, што некаторыя з гэтых функцый больш не працуюць належным чынам у гэтым наборы дадзеных. Для вырашэння гэтай праблемы я выдаліў непрыдатныя функцыі і загрузіў дадзеныя без пераўтварэння ў больш дэталізаваныя тыпы.
Размеркаванне дадзеных па кластары
Я буду размяркоўваць дадзеныя па ўсіх трох вузлах кластара. Для пачатку ніжэй я ствару табліцу на ўсіх трох машынах.
$ clickhouse-client --host=0.0.0.0CREATE TABLE trips_mergetree_third (
trip_id UInt32,
vendor_id String,
pickup_date Date,
pickup_datetime DateTime,
dropoff_date Date,
dropoff_datetime Nullable(DateTime),
store_and_fwd_flag Nullable(FixedString(1)),
rate_code_id Nullable(UInt8),
pickup_longitude Nullable(Float64),
pickup_latitude Nullable(Float64),
dropoff_longitude Nullable(Float64),
dropoff_latitude Nullable(Float64),
passenger_count Nullable(UInt8),
trip_distance Nullable(Float64),
fare_amount Nullable(Float32),
extra Nullable(Float32),
mta_tax Nullable(Float32),
tip_amount Nullable(Float32),
tolls_amount Nullable(Float32),
ehail_fee Nullable(Float32),
improvement_surcharge Nullable(Float32),
total_amount Nullable(Float32),
payment_type Nullable(String),
trip_type Nullable(UInt8),
pickup Nullable(String),
dropoff Nullable(String),
cab_type Nullable(String),
precipitation Nullable(Int8),
snow_depth Nullable(Int8),
snowfall Nullable(Int8),
max_temperature Nullable(Int8),
min_temperature Nullable(Int8),
average_wind_speed Nullable(Int8),
pickup_nyct2010_gid Nullable(Int8),
pickup_ctlabel Nullable(String),
pickup_borocode Nullable(Int8),
pickup_boroname Nullable(String),
pickup_ct2010 Nullable(String),
pickup_boroct2010 Nullable(String),
pickup_cdeligibil Nullable(FixedString(1)),
pickup_ntacode Nullable(String),
pickup_ntaname Nullable(String),
pickup_puma Nullable(String),
dropoff_nyct2010_gid Nullable(UInt8),
dropoff_ctlabel Nullable(String),
dropoff_borocode Nullable(UInt8),
dropoff_boroname Nullable(String),
dropoff_ct2010 Nullable(String),
dropoff_boroct2010 Nullable(String),
dropoff_cdeligibil Nullable(String),
dropoff_ntacode Nullable(String),
dropoff_ntaname Nullable(String),
dropoff_puma Nullable(String)
) ENGINE = MergeTree(pickup_date, pickup_datetime, 8192);Затым я паклапачуся аб тым, каб першы сервер мог бачыць усе тры вузла ў кластары.
SELECT *
FROM system.clusters
WHERE cluster = 'perftest_3shards'
FORMAT Vertical;Row 1:
──────
cluster: perftest_3shards
shard_num: 1
shard_weight: 1
replica_num: 1
host_name: 172.30.2.192
host_address: 172.30.2.192
port: 9000
is_local: 1
user: default
default_database:Row 2:
──────
cluster: perftest_3shards
shard_num: 2
shard_weight: 1
replica_num: 1
host_name: 172.30.2.162
host_address: 172.30.2.162
port: 9000
is_local: 0
user: default
default_database:Row 3:
──────
cluster: perftest_3shards
shard_num: 3
shard_weight: 1
replica_num: 1
host_name: 172.30.2.36
host_address: 172.30.2.36
port: 9000
is_local: 0
user: default
default_database:
Затым я вызначу новую табліцу на першым серверы, якая заснавана на схеме trips_mergetree_third і выкарыстоўвае рухавік Distributed.
CREATE TABLE trips_mergetree_x3
AS trips_mergetree_third
ENGINE = Distributed(perftest_3shards,
default,
trips_mergetree_third,
rand());Затым я скапірую дадзеныя з табліцы на аснове MergeTree на ўсе тры серверы. Наступнае выканана за 34 хвіліны і 44 секунды.
INSERT INTO trips_mergetree_x3
SELECT * FROM trips_mergetree;Пасля прыведзенай вышэй аперацыі я даў ClickHouse 15 хвілін, каб адысці ад адзнакі максімальнага ўзроўню сховішчы. Каталогі дадзеных у канчатковым выніку складалі 264 ГБ, 34 ГБ і 33 ГБ адпаведна на кожным з трох сервераў.
Ацэнка прадукцыйнасці кластара ClickHouse
Тое, што я ўбачыў далей, было самым хуткім часам, які я бачыў пры шматразовым выкананні кожнага запыту ў табліцы trips_mergetree_x3.
$ clickhouse-client --host=0.0.0.0Наступнае выканана за 2.449 секунды.
SELECT cab_type, count(*)
FROM trips_mergetree_x3
GROUP BY cab_type;Наступнае выканана за 0.691 секунды.
SELECT passenger_count,
avg(total_amount)
FROM trips_mergetree_x3
GROUP BY passenger_count;Наступнае выканана за 0.,582 секунды.
SELECT passenger_count,
toYear(pickup_date) AS year,
count(*)
FROM trips_mergetree_x3
GROUP BY passenger_count,
year;Наступнае выканана за 0.983 секунды.
SELECT passenger_count,
toYear(pickup_date) AS year,
round(trip_distance) AS distance,
count(*)
FROM trips_mergetree_x3
GROUP BY passenger_count,
year,
distance
ORDER BY year,
count(*) DESC;Для параўнання, я выканаў тыя ж запыты ў табліцы на аснове MergeTree, якая знаходзіцца выключна на першым серверы.
Ацэнка прадукцыйнасці аднаго вузла ClickHouse
Тое, што я ўбачыў далей, было самым хуткім часам, які я бачыў пры шматразовым выкананні кожнага запыту ў табліцы trips_mergetree_x3.
Наступнае выканана за 0.241 секунды.
SELECT cab_type, count(*)
FROM trips_mergetree
GROUP BY cab_type;Наступнае выканана за 0.826 секунды.
SELECT passenger_count,
avg(total_amount)
FROM trips_mergetree
GROUP BY passenger_count;Наступнае выканана за 1.209 секунды.
SELECT passenger_count,
toYear(pickup_date) AS year,
count(*)
FROM trips_mergetree
GROUP BY passenger_count,
year;Наступнае выканана за 1.781 секунды.
SELECT passenger_count,
toYear(pickup_date) AS year,
round(trip_distance) AS distance,
count(*)
FROM trips_mergetree
GROUP BY passenger_count,
year,
distance
ORDER BY year,
count(*) DESC;Разважанні аб выніках
Гэта першы раз, калі бясплатная база дадзеных на базе працэсара змагла перасягнуць базу дадзеных на аснове GPU у маіх тэстах. Тая база дадзеных на аснове GPU з тых часоў падвергнулася двум рэвізіям, але, тым не менш, прадукцыйнасць, якую ClickHouse паказаў на адным вузле, вельмі ўражвае.
Пры гэтым пры выкананні Query 1 на размеркаваным рухавічку накладныя выдаткі аказваюцца на парадак вышэй. Я спадзяюся, што нешта прапусціў у сваім даследаванні для гэтай пасады, таму што было б добра ўбачыць, як час запытаў зніжаецца, калі я дадаю больш вузлоў у кластар. Аднак гэта цудоўна, што пры выкананні іншых запытаў прадукцыйнасць вырасла прыкладна ў 2 разы.
Было б нядрэнна, калі б ClickHouse развіваўся ў напрамку таго, каб можна было аддзяліць сховішча і вылічэнні, каб яны маглі маштабавацца незалежна. Падтрымка HDFS, якая была дададзеная ў мінулым годзе, можа стаць крокам да гэтага. Што тычыцца вылічэнняў, калі адзін запыт можа быць паскораны пры даданні большай колькасці вузлоў у кластар, то будучыня гэтага праграмнага забеспячэння будзе вельмі бясхмарным.
Дзякуй, што знайшлі час, каб прачытаць гэтую пасаду. Я прапаную кансалтынг, архітэктуру і паслугі па практычнаму развіццю для кліентаў у Паўночнай Амерыцы і Еўропе. Калі вы хочаце абмеркаваць, як мае прапановы могуць дапамагчы вашаму бізнесу, звяжыцеся са мной праз .
Крыніца: habr.com