La traducció de l'article s'ha elaborat expressament per als alumnes del curs .
és una base de dades columnar de codi obert. És un entorn fantàstic on centenars d'analistes poden consultar ràpidament dades detallades, fins i tot quan s'introdueixen desenes de milers de milions de registres nous al dia. Els costos d'infraestructura per donar suport a aquest sistema podrien arribar als 100 dòlars anuals i, potencialment, la meitat segons l'ús. En un moment donat, la instal·lació de ClickHouse de Yandex Metrics contenia 10 bilions de registres. A més de Yandex, ClickHouse també ha tingut èxit amb Bloomberg i Cloudflare.
Fa dos anys vaig passar bases de dades utilitzant una màquina, i es va convertir programari de bases de dades gratuït que he vist mai. Des de llavors, els desenvolupadors han continuat afegint funcions, inclosa la compatibilitat amb la compressió Kafka, HDFS i ZStandard. L'any passat van afegir suport per a mètodes de compressió en cascada i la codificació es va fer possible. Quan es comprimeixen dades de sèries temporals, els valors dels indicadors es poden comprimir bé mitjançant la codificació delta, però per als comptadors seria millor utilitzar la codificació delta per delta. Una bona compressió s'ha convertit en la clau del rendiment de ClickHouse.
ClickHouse consta de 170 mil línies de codi C++, excloent les biblioteques de tercers, i és una de les bases de codi de bases de dades distribuïdes més petites. En comparació, SQLite no admet la distribució i consta de 235 mil línies de codi C. En el moment d'escriure aquest article, 207 enginyers han contribuït a ClickHouse i la intensitat de les confirmacions ha augmentat recentment.
El març de 2017, ClickHouse va començar a conduir com una manera fàcil de fer un seguiment del desenvolupament. També van dividir el fitxer de documentació monolític en una jerarquia de fitxers basada en Markdown. Els problemes i les funcions es fan un seguiment a través de GitHub i, en general, el programari s'ha tornat molt més accessible en els últims anys.
En aquest article, donaré una ullada al rendiment d'un clúster ClickHouse a AWS EC2 amb processadors de 36 nuclis i emmagatzematge NVMe.
ACTUALITZACIÓ: una setmana després de publicar originalment aquesta publicació, vaig tornar a fer la prova amb una configuració millorada i vaig aconseguir resultats molt millors. Aquesta publicació s'ha actualitzat per reflectir aquests canvis.
Llançament d'un clúster AWS EC2
Faré servir tres instàncies EC5 c9d.2xlarge per a aquesta publicació. Cadascun d'ells conté 36 CPU virtuals, 72 GB de RAM, 900 GB d'emmagatzematge SSD NVMe i suporta una xarxa de 10 Gigabit. Costen 1,962 dòlars l'hora cadascun a la regió eu-west-1 quan funcionen sota demanda. Faré servir Ubuntu Server 16.04 LTS com a sistema operatiu.
El tallafoc està configurat perquè cada màquina es pugui comunicar entre elles sense restriccions, i només la meva adreça IPv4 està a la llista blanca per SSH al clúster.
Unitat NVMe en estat de preparació operativa
Perquè ClickHouse funcioni, crearé un sistema de fitxers en format EXT4 en una unitat NVMe de cadascun dels servidors.
$ sudo mkfs -t ext4 /dev/nvme1n1
$ sudo mkdir /ch
$ sudo mount /dev/nvme1n1 /chUn cop tot estigui configurat, podreu veure el punt de muntatge i els 783 GB d'espai disponibles a cada 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% /chEl conjunt de dades que utilitzaré en aquesta prova és un abocament de dades que vaig generar a partir de 1.1 milions de viatges en taxi realitzats a la ciutat de Nova York durant sis anys. Al blog detalla com vaig recopilar aquest conjunt de dades. S'emmagatzemen a AWS S3, així que configuraré l'AWS CLI amb les meves claus d'accés i secretes.
$ sudo apt update
$ sudo apt install awscli
$ aws configureEstabliré el límit de sol·licituds concurrents del client en 100 perquè els fitxers es baixin més ràpidament que la configuració predeterminada.
$ aws configure set
default.s3.max_concurrent_requests
100Baixaré el conjunt de dades de viatges en taxi d'AWS S3 i l'emmagatzemaré en una unitat NVMe del primer servidor. Aquest conjunt de dades és d'aproximadament 104 GB en format CSV comprimit amb GZIP.
$ sudo mkdir -p /ch/csv
$ sudo chown -R ubuntu /ch/csv
$ aws s3 sync s3://<bucket>/csv /ch/csvInstal·lació de ClickHouse
Instal·laré la distribució OpenJDK per a Java 8, ja que és necessària per executar Apache ZooKeeper, que és necessària per a una instal·lació distribuïda de ClickHouse a les tres màquines.
$ sudo apt update
$ sudo apt install
openjdk-8-jre
openjdk-8-jdk-headless
A continuació, vaig establir la variable d'entorn JAVA_HOME.
$ sudo vi /etc/profile
export JAVA_HOME=/usr
$ source /etc/profileA continuació, utilitzaré el sistema de gestió de paquets d'Ubuntu per instal·lar ClickHouse 18.16.1, Glances i ZooKeeper a les tres màquines.
$ 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
zookeeperdCrearé un directori per a ClickHouse i també faré algunes modificacions de configuració als tres servidors.
$ 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.confAquestes són les substitucions de configuració que faré servir.
<?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>A continuació, executaré ZooKeeper i el servidor ClickHouse a les tres màquines.
$ sudo /etc/init.d/zookeeper start
$ sudo service clickhouse-server startS'estan penjant dades a ClickHouse
Al primer servidor crearé una taula de viatges (trips), que emmagatzemarà un conjunt de dades de viatges en taxi mitjançant el motor de registre.
$ 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;
Aleshores extreu i carrego cadascun dels fitxers CSV a una taula de viatges (trips). El següent es va completar en 55 minuts i 10 segons. Després d'aquesta operació, la mida del directori de dades era de 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 velocitat d'importació era de 155 MB de contingut CSV sense comprimir per segon. Sospito que això es va deure a un coll d'ampolla en la descompressió GZIP. Potser hauria estat més ràpid descomprimir tots els fitxers comprimits en paral·lel mitjançant xargs i després carregar les dades descomprimides. A continuació es mostra una descripció del que es va informar durant el procés d'importació de 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:1HAlliberaré espai a la unitat NVMe suprimint els fitxers CSV originals abans de continuar.
$ sudo rm -fr /ch/csvConverteix al formulari de columna
El motor Log ClickHouse emmagatzemarà les dades en un format orientat a files. Per consultar dades més ràpidament, les converto en format columnar mitjançant el motor MergeTree.
$ clickhouse-client --host=0.0.0.0El següent es va completar en 34 minuts i 50 segons. Després d'aquesta operació, la mida del directori de dades era de 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;Aquest és el que semblava la sortida d'ull durant l'operació:
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)En l'última prova, es van convertir i recalcular diverses columnes. Vaig trobar que algunes d'aquestes funcions ja no funcionen com s'esperava en aquest conjunt de dades. Per resoldre aquest problema, vaig eliminar les funcions inadequades i vaig carregar les dades sense convertir-les a tipus més granulars.
Distribució de dades al clúster
Distribuiré les dades als tres nodes del clúster. Per començar, a continuació crearé una taula a les tres màquines.
$ 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);Aleshores m'asseguraré que el primer servidor pugui veure els tres nodes del clúster.
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:
A continuació, definiré una taula nova al primer servidor que es basa en l'esquema trips_mergetree_third i utilitza el motor distribuït.
CREATE TABLE trips_mergetree_x3
AS trips_mergetree_third
ENGINE = Distributed(perftest_3shards,
default,
trips_mergetree_third,
rand());A continuació, copiaré les dades de la taula basada en MergeTree als tres servidors. El següent es va completar en 34 minuts i 44 segons.
INSERT INTO trips_mergetree_x3
SELECT * FROM trips_mergetree;Després de l'operació anterior, vaig donar a ClickHouse 15 minuts per allunyar-se de la marca de nivell d'emmagatzematge màxim. Els directoris de dades van acabar sent 264 GB, 34 GB i 33 GB respectivament en cadascun dels tres servidors.
Avaluació del rendiment del clúster ClickHouse
El que vaig veure a continuació va ser el temps més ràpid que he vist executant cada consulta en una taula diverses vegades trips_mergetree_x3.
$ clickhouse-client --host=0.0.0.0El següent es va completar en 2.449 segons.
SELECT cab_type, count(*)
FROM trips_mergetree_x3
GROUP BY cab_type;El següent es va completar en 0.691 segons.
SELECT passenger_count,
avg(total_amount)
FROM trips_mergetree_x3
GROUP BY passenger_count;El següent es va completar en 0 segons.
SELECT passenger_count,
toYear(pickup_date) AS year,
count(*)
FROM trips_mergetree_x3
GROUP BY passenger_count,
year;El següent es va completar en 0.983 segons.
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 comparar, vaig executar les mateixes consultes en una taula basada en MergeTree que resideix únicament al primer servidor.
Avaluació del rendiment d'un node ClickHouse
El que vaig veure a continuació va ser el temps més ràpid que he vist executant cada consulta en una taula diverses vegades trips_mergetree_x3.
El següent es va completar en 0.241 segons.
SELECT cab_type, count(*)
FROM trips_mergetree
GROUP BY cab_type;El següent es va completar en 0.826 segons.
SELECT passenger_count,
avg(total_amount)
FROM trips_mergetree
GROUP BY passenger_count;El següent es va completar en 1.209 segons.
SELECT passenger_count,
toYear(pickup_date) AS year,
count(*)
FROM trips_mergetree
GROUP BY passenger_count,
year;El següent es va completar en 1.781 segons.
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;Reflexions sobre els resultats
Aquesta és la primera vegada que una base de dades basada en CPU gratuïta pot superar una base de dades basada en GPU en les meves proves. Aquesta base de dades basada en GPU ha passat per dues revisions des de llavors, però el rendiment que ClickHouse va oferir en un sol node és, tanmateix, molt impressionant.
Al mateix temps, quan s'executa la consulta 1 en un motor distribuït, els costos generals són un ordre de magnitud superiors. Espero haver perdut alguna cosa en la meva investigació per a aquesta publicació perquè seria bo veure que els temps de consulta baixaven a mesura que afegeixo més nodes al clúster. No obstant això, és fantàstic que quan s'executen altres consultes, el rendiment s'ha incrementat aproximadament 2 vegades.
Seria bo veure que ClickHouse evoluciona per poder separar l'emmagatzematge i el càlcul perquè puguin escalar de manera independent. El suport HDFS, que es va afegir l'any passat, podria ser un pas cap a això. Pel que fa a la informàtica, si es pot accelerar una sola consulta afegint més nodes al clúster, el futur d'aquest programari és molt brillant.
Gràcies per prendre el temps de llegir aquest post. Ofereixo serveis de consultoria, arquitectura i desenvolupament de pràctiques a clients d'Amèrica del Nord i Europa. Si voleu parlar de com els meus suggeriments poden ajudar a la vostra empresa, poseu-vos en contacte amb mi a través de .
Font: www.habr.com