La traduzione dell'articolo è stata preparata appositamente per gli studenti del corso .
è un database colonnare open source. Si tratta di un ambiente eccezionale in cui centinaia di analisti possono eseguire rapidamente query su dati dettagliati, anche se ogni giorno vengono immesse decine di miliardi di nuovi record. I costi infrastrutturali per supportare un sistema del genere potrebbero raggiungere i 100 dollari all’anno e potenzialmente la metà a seconda dell’utilizzo. Ad un certo punto, l'installazione ClickHouse di Yandex Metrics conteneva 10 trilioni di record. Oltre a Yandex, ClickHouse ha riscontrato successo anche con Bloomberg e Cloudflare.
Due anni fa ho trascorso database utilizzando una macchina, ed è diventato software di database gratuito che abbia mai visto. Da allora, gli sviluppatori non hanno smesso di aggiungere funzionalità, incluso il supporto per la compressione Kafka, HDFS e ZStandard. L'anno scorso hanno aggiunto il supporto per i metodi di compressione a cascata e divenne possibile la codifica. Quando si comprimono i dati delle serie temporali, i valori del misuratore possono essere compressi bene utilizzando la codifica delta, ma per i contatori sarebbe meglio utilizzare la codifica delta per delta. Una buona compressione è diventata la chiave delle prestazioni di ClickHouse.
ClickHouse è costituito da 170mila righe di codice C++, escluse le librerie di terze parti, ed è uno dei più piccoli database distribuiti. In confronto, SQLite non supporta la distribuzione ed è composto da 235mila righe di codice C. Al momento della stesura di questo articolo, 207 ingegneri hanno contribuito a ClickHouse e l'intensità degli impegni è aumentata di recente.
Nel marzo 2017, ClickHouse ha iniziato a condurre come un modo semplice per tenere traccia dello sviluppo. Hanno anche suddiviso il file di documentazione monolitico in una gerarchia di file basata su Markdown. Problemi e funzionalità vengono monitorati tramite GitHub e in generale il software è diventato molto più accessibile negli ultimi anni.
In questo articolo darò un'occhiata alle prestazioni di un cluster ClickHouse su AWS EC2 utilizzando processori a 36 core e storage NVMe.
AGGIORNAMENTO: una settimana dopo aver pubblicato originariamente questo post, ho eseguito nuovamente il test con una configurazione migliorata e ho ottenuto risultati molto migliori. Questo post è stato aggiornato per riflettere questi cambiamenti.
Avvio di un cluster AWS EC2
Utilizzerò tre istanze EC5 c9d.2xlarge per questo post. Ognuno di essi contiene 36 CPU virtuali, 72 GB di RAM, 900 GB di spazio di archiviazione SSD NVMe e supporta la rete da 10 Gigabit. Costano 1,962 dollari l'ora ciascuno nella regione eu-west-1 quando funzionano su richiesta. Utilizzerò Ubuntu Server 16.04 LTS come sistema operativo.
Il firewall è configurato in modo che ogni macchina possa comunicare tra loro senza restrizioni e solo il mio indirizzo IPv4 è inserito nella whitelist di SSH nel cluster.
Unità NVMe in stato di disponibilità operativa
Affinché ClickHouse funzioni, creerò un file system nel formato EXT4 su un'unità NVMe su ciascuno dei server.
$ sudo mkfs -t ext4 /dev/nvme1n1
$ sudo mkdir /ch
$ sudo mount /dev/nvme1n1 /chUna volta configurato tutto, potrai vedere il punto di montaggio e i 783 GB di spazio disponibili su ciascun sistema.
$ 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% /chIl set di dati che utilizzerò in questo test è un dump di dati che ho generato da 1.1 miliardi di corse in taxi effettuate a New York in sei anni. Sul blog dettaglia come ho raccolto questo set di dati. Sono archiviati in AWS S3, quindi configurerò l'AWS CLI con le mie chiavi di accesso e segrete.
$ sudo apt update
$ sudo apt install awscli
$ aws configureImposterò il limite di richieste simultanee del client su 100 in modo che i file vengano scaricati più velocemente rispetto alle impostazioni predefinite.
$ aws configure set
default.s3.max_concurrent_requests
100Scaricherò il set di dati delle corse in taxi da AWS S3 e lo memorizzerò su un'unità NVMe sul primo server. Questo set di dati è di circa 104 GB in formato CSV compresso GZIP.
$ sudo mkdir -p /ch/csv
$ sudo chown -R ubuntu /ch/csv
$ aws s3 sync s3://<bucket>/csv /ch/csvInstallazione di ClickHouse
Installerò la distribuzione OpenJDK per Java 8 poiché è necessaria per eseguire Apache ZooKeeper, necessario per un'installazione distribuita di ClickHouse su tutte e tre le macchine.
$ sudo apt update
$ sudo apt install
openjdk-8-jre
openjdk-8-jdk-headless
Quindi ho impostato la variabile d'ambiente JAVA_HOME.
$ sudo vi /etc/profile
export JAVA_HOME=/usr
$ source /etc/profileUtilizzerò quindi il sistema di gestione dei pacchetti di Ubuntu per installare ClickHouse 18.16.1, looks e ZooKeeper su tutte e tre le macchine.
$ 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
zookeeperdCreerò una directory per ClickHouse ed eseguirò anche alcune modifiche alla configurazione su tutti e tre i server.
$ 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.confQueste sono le sostituzioni di configurazione che utilizzerò.
<?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>Eseguirò quindi ZooKeeper e il server ClickHouse su tutte e tre le macchine.
$ sudo /etc/init.d/zookeeper start
$ sudo service clickhouse-server startCaricamento dei dati su ClickHouse
Sul primo server creerò una tabella di viaggio (trips), che memorizzerà un set di dati di viaggi in taxi utilizzando il motore 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;
Quindi estraggo e carico ciascuno dei file CSV in una tabella di viaggio (trips). Quanto segue è stato completato in 55 minuti e 10 secondi. Dopo questa operazione, la dimensione della directory dei dati era di 134 GB.
$ 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)La velocità di importazione era di 155 MB di contenuto CSV non compresso al secondo. Sospetto che ciò sia dovuto a un collo di bottiglia nella decompressione GZIP. Potrebbe essere stato più veloce decomprimere tutti i file gzippati in parallelo utilizzando xargs e quindi caricare i dati decompressi. Di seguito la descrizione di quanto riportato durante il processo di importazione del 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:1HLibererò spazio sull'unità NVMe eliminando i file CSV originali prima di continuare.
$ sudo rm -fr /ch/csvConverti in formato colonna
Il motore Log ClickHouse memorizzerà i dati in un formato orientato alle righe. Per interrogare i dati più velocemente, li converto in formato colonnare utilizzando il motore MergeTree.
$ clickhouse-client --host=0.0.0.0Quanto segue è stato completato in 34 minuti e 50 secondi. Dopo questa operazione, la dimensione della directory dei dati era di 237 GB.
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;Questo è l'aspetto dell'output del colpo d'occhio durante l'operazione:
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)Nell'ultimo test sono state convertite e ricalcolate diverse colonne. Ho scoperto che alcune di queste funzioni non funzionano più come previsto su questo set di dati. Per risolvere questo problema, ho rimosso le funzioni inappropriate e ho caricato i dati senza convertirli in tipi più granulari.
Distribuzione dei dati nel cluster
Distribuirò i dati su tutti e tre i nodi del cluster. Per iniziare, di seguito creerò una tabella su tutte e tre le macchine.
$ 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);Quindi mi assicurerò che il primo server possa vedere tutti e tre i nodi nel cluster.
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:
Quindi definirò una nuova tabella sul primo server basata sullo schema trips_mergetree_third e utilizza il motore distribuito.
CREATE TABLE trips_mergetree_x3
AS trips_mergetree_third
ENGINE = Distributed(perftest_3shards,
default,
trips_mergetree_third,
rand());Copierò quindi i dati dalla tabella basata su MergeTree su tutti e tre i server. Quanto segue è stato completato in 34 minuti e 44 secondi.
INSERT INTO trips_mergetree_x3
SELECT * FROM trips_mergetree;Dopo l'operazione di cui sopra, ho concesso a ClickHouse 15 minuti per allontanarsi dal livello massimo di archiviazione. Le directory dei dati erano rispettivamente di 264 GB, 34 GB e 33 GB su ciascuno dei tre server.
Valutazione delle prestazioni del cluster ClickHouse
Quello che ho visto dopo è stato il tempo più veloce che ho visto eseguendo ciascuna query su una tabella più volte trips_mergetree_x3.
$ clickhouse-client --host=0.0.0.0Il seguente è stato completato in 2.449 secondi.
SELECT cab_type, count(*)
FROM trips_mergetree_x3
GROUP BY cab_type;Il seguente è stato completato in 0.691 secondi.
SELECT passenger_count,
avg(total_amount)
FROM trips_mergetree_x3
GROUP BY passenger_count;Quanto segue è stato completato in 0 secondi.
SELECT passenger_count,
toYear(pickup_date) AS year,
count(*)
FROM trips_mergetree_x3
GROUP BY passenger_count,
year;Il seguente è stato completato in 0.983 secondi.
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;Per fare un confronto, ho eseguito le stesse query su una tabella basata su MergeTree che risiede esclusivamente sul primo server.
Valutazione delle prestazioni di un nodo ClickHouse
Quello che ho visto dopo è stato il tempo più veloce che ho visto eseguendo ciascuna query su una tabella più volte trips_mergetree_x3.
Il seguente è stato completato in 0.241 secondi.
SELECT cab_type, count(*)
FROM trips_mergetree
GROUP BY cab_type;Il seguente è stato completato in 0.826 secondi.
SELECT passenger_count,
avg(total_amount)
FROM trips_mergetree
GROUP BY passenger_count;Il seguente è stato completato in 1.209 secondi.
SELECT passenger_count,
toYear(pickup_date) AS year,
count(*)
FROM trips_mergetree
GROUP BY passenger_count,
year;Il seguente è stato completato in 1.781 secondi.
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;Riflessioni sui risultati
Questa è la prima volta che un database gratuito basato su CPU è riuscito a superare un database basato su GPU nei miei test. Da allora il database basato su GPU ha subito due revisioni, ma le prestazioni fornite da ClickHouse su un singolo nodo sono comunque davvero impressionanti.
Allo stesso tempo, quando si esegue la query 1 su un motore distribuito, i costi generali sono molto più alti. Spero di aver tralasciato qualcosa nella mia ricerca per questo post perché sarebbe bello vedere i tempi di query diminuire man mano che aggiungo più nodi al cluster. Tuttavia, è fantastico che durante l'esecuzione di altre query, le prestazioni siano aumentate di circa 2 volte.
Sarebbe bello vedere ClickHouse evolversi verso la possibilità di separare archiviazione ed elaborazione in modo che possano scalare in modo indipendente. Il supporto HDFS, aggiunto lo scorso anno, potrebbe essere un passo in questa direzione. In termini di elaborazione, se una singola query può essere accelerata aggiungendo più nodi al cluster, il futuro di questo software è molto luminoso.
Grazie per aver dedicato del tempo a leggere questo post. Offro servizi di consulenza, architettura e sviluppo di pratiche a clienti in Nord America ed Europa. Se desideri discutere di come i miei suggerimenti possono aiutare la tua attività, contattami tramite .
Fonte: habr.com