Die Übersetzung des Artikels wurde speziell für die Studierenden des Kurses erstellt .
ist eine Open-Source-Säulendatenbank. Es ist eine großartige Umgebung, in der Hunderte von Analysten schnell detaillierte Daten abfragen können, selbst wenn täglich Dutzende Milliarden neue Datensätze eingegeben werden. Die Infrastrukturkosten zur Unterstützung eines solchen Systems könnten bis zu 100 US-Dollar pro Jahr betragen, je nach Nutzung sogar die Hälfte davon. Zu einem Zeitpunkt enthielt die ClickHouse-Installation von Yandex Metrics 10 Billionen Datensätze. Neben Yandex war ClickHouse auch mit Bloomberg und Cloudflare erfolgreich.
Vor zwei Jahren habe ich verbracht Datenbanken mit einer Maschine, und es wurde kostenlose Datenbanksoftware, die ich je gesehen habe. Seitdem haben die Entwickler nicht aufgehört, Funktionen hinzuzufügen, darunter die Unterstützung für Kafka-, HDFS- und ZStandard-Komprimierung. Letztes Jahr haben sie Unterstützung für kaskadierende Komprimierungsmethoden hinzugefügt Codierung wurde möglich. Bei der Komprimierung von Zeitreihendaten können Gauge-Werte mithilfe der Delta-Kodierung gut komprimiert werden. Für Zähler wäre es jedoch besser, die Delta-für-Delta-Kodierung zu verwenden. Eine gute Komprimierung ist zum Schlüssel für die Leistung von ClickHouse geworden.
ClickHouse besteht aus 170 Zeilen C++-Code, ausgenommen Bibliotheken von Drittanbietern, und ist eine der kleinsten verteilten Datenbankcodebasen. Im Vergleich dazu unterstützt SQLite keine Verteilung und besteht aus 235 Zeilen C-Code. Zum jetzigen Zeitpunkt haben 207 Ingenieure zu ClickHouse beigetragen, und die Intensität der Commits hat in letzter Zeit zugenommen.
Im März 2017 begann ClickHouse mit der Durchführung als einfache Möglichkeit, den Überblick über die Entwicklung zu behalten. Außerdem wurde die monolithische Dokumentationsdatei in eine Markdown-basierte Dateihierarchie aufgeteilt. Probleme und Funktionen werden über GitHub verfolgt und im Allgemeinen ist die Software in den letzten Jahren viel zugänglicher geworden.
In diesem Artikel werde ich einen Blick auf die Leistung eines ClickHouse-Clusters auf AWS EC2 mit 36-Core-Prozessoren und NVMe-Speicher werfen.
UPDATE: Eine Woche nach der ursprünglichen Veröffentlichung dieses Beitrags habe ich den Test mit einer verbesserten Konfiguration erneut durchgeführt und viel bessere Ergebnisse erzielt. Dieser Beitrag wurde aktualisiert, um diese Änderungen widerzuspiegeln.
Starten eines AWS EC2-Clusters
Ich werde für diesen Beitrag drei c5d.9xlarge EC2-Instanzen verwenden. Jeder von ihnen enthält 36 virtuelle CPUs, 72 GB RAM, 900 GB NVMe-SSD-Speicher und unterstützt ein 10-Gigabit-Netzwerk. Bei Betrieb auf Abruf kosten sie in der Region EU-West-1,962 jeweils 1 US-Dollar pro Stunde. Als Betriebssystem verwende ich Ubuntu Server 16.04 LTS.
Die Firewall ist so konfiguriert, dass jede Maschine ohne Einschränkungen miteinander kommunizieren kann und nur meine IPv4-Adresse von SSH im Cluster auf die Whitelist gesetzt wird.
NVMe-Laufwerk im Betriebsbereitschaftszustand
Damit ClickHouse funktioniert, erstelle ich auf jedem der Server ein Dateisystem im EXT4-Format auf einem NVMe-Laufwerk.
$ sudo mkfs -t ext4 /dev/nvme1n1
$ sudo mkdir /ch
$ sudo mount /dev/nvme1n1 /chSobald alles konfiguriert ist, können Sie den Mount-Punkt und die 783 GB verfügbaren Speicherplatz auf jedem System sehen.
$ 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% /chDer Datensatz, den ich in diesem Test verwende, ist ein Datendump, den ich aus 1.1 Milliarden Taxifahrten in New York City über einen Zeitraum von sechs Jahren erstellt habe. Auf dem Blog Einzelheiten dazu, wie ich diesen Datensatz gesammelt habe. Sie werden in AWS S3 gespeichert, daher werde ich die AWS CLI mit meinen Zugriffs- und Geheimschlüsseln konfigurieren.
$ sudo apt update
$ sudo apt install awscli
$ aws configureIch stelle das Limit für gleichzeitige Anfragen des Clients auf 100 ein, damit Dateien schneller heruntergeladen werden als in den Standardeinstellungen.
$ aws configure set
default.s3.max_concurrent_requests
100Ich lade den Taxifahrtdatensatz von AWS S3 herunter und speichere ihn auf einem NVMe-Laufwerk auf dem ersten Server. Dieser Datensatz ist ca. 104 GB groß und liegt im GZIP-komprimierten CSV-Format vor.
$ sudo mkdir -p /ch/csv
$ sudo chown -R ubuntu /ch/csv
$ aws s3 sync s3://<bucket>/csv /ch/csvClickHouse-Installation
Ich werde die OpenJDK-Distribution für Java 8 installieren, da sie zum Ausführen von Apache ZooKeeper erforderlich ist, der für eine verteilte Installation von ClickHouse auf allen drei Computern erforderlich ist.
$ sudo apt update
$ sudo apt install
openjdk-8-jre
openjdk-8-jdk-headless
Dann setze ich die Umgebungsvariable JAVA_HOME.
$ sudo vi /etc/profile
export JAVA_HOME=/usr
$ source /etc/profileIch werde dann das Paketverwaltungssystem von Ubuntu verwenden, um ClickHouse 18.16.1, Glances und ZooKeeper auf allen drei Maschinen zu installieren.
$ 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
zookeeperdIch werde ein Verzeichnis für ClickHouse erstellen und auch einige Konfigurationsüberschreibungen auf allen drei Servern vornehmen.
$ 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.confDies sind die Konfigurationsüberschreibungen, die ich verwenden werde.
<?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>Ich werde dann ZooKeeper und den ClickHouse-Server auf allen drei Maschinen ausführen.
$ sudo /etc/init.d/zookeeper start
$ sudo service clickhouse-server startHochladen von Daten auf ClickHouse
Auf dem ersten Server werde ich eine Trip-Tabelle erstellen (trips), das mithilfe der Log-Engine einen Datensatz von Taxifahrten speichert.
$ 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;
Anschließend extrahiere und lade ich jede der CSV-Dateien in eine Trip-Tabelle (trips). Das Folgende wurde in 55 Minuten und 10 Sekunden abgeschlossen. Nach diesem Vorgang betrug die Größe des Datenverzeichnisses 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)Die Importgeschwindigkeit betrug 155 MB unkomprimierter CSV-Inhalt pro Sekunde. Ich vermute, dass dies an einem Engpass bei der GZIP-Dekomprimierung lag. Es wäre möglicherweise schneller gewesen, alle gzip-Dateien parallel mit xargs zu entpacken und dann die entpackten Daten zu laden. Nachfolgend finden Sie eine Beschreibung dessen, was während des CSV-Importvorgangs gemeldet wurde.
$ 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:1HIch werde Speicherplatz auf dem NVMe-Laufwerk freigeben, indem ich die ursprünglichen CSV-Dateien lösche, bevor ich fortfahre.
$ sudo rm -fr /ch/csvIn Spaltenform konvertieren
Die Log ClickHouse-Engine speichert Daten in einem zeilenorientierten Format. Um Daten schneller abzufragen, konvertiere ich sie mit der MergeTree-Engine in das Spaltenformat.
$ clickhouse-client --host=0.0.0.0Das Folgende wurde in 34 Minuten und 50 Sekunden abgeschlossen. Nach diesem Vorgang betrug die Größe des Datenverzeichnisses 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;So sah die Blickausgabe während der Operation aus:
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)Im letzten Test wurden mehrere Spalten umgerechnet und neu berechnet. Ich habe festgestellt, dass einige dieser Funktionen in diesem Datensatz nicht mehr wie erwartet funktionieren. Um dieses Problem zu lösen, habe ich die ungeeigneten Funktionen entfernt und die Daten geladen, ohne sie in detailliertere Typen zu konvertieren.
Verteilung der Daten im gesamten Cluster
Ich werde die Daten auf alle drei Clusterknoten verteilen. Zunächst erstelle ich im Folgenden eine Tabelle auf allen drei Maschinen.
$ 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);Dann stelle ich sicher, dass der erste Server alle drei Knoten im Cluster sehen kann.
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:
Dann definiere ich auf dem ersten Server eine neue Tabelle, die auf dem Schema basiert trips_mergetree_third und nutzt die Distributed Engine.
CREATE TABLE trips_mergetree_x3
AS trips_mergetree_third
ENGINE = Distributed(perftest_3shards,
default,
trips_mergetree_third,
rand());Anschließend kopiere ich die Daten aus der MergeTree-basierten Tabelle auf alle drei Server. Das Folgende wurde in 34 Minuten und 44 Sekunden abgeschlossen.
INSERT INTO trips_mergetree_x3
SELECT * FROM trips_mergetree;Nach dem oben genannten Vorgang habe ich ClickHouse 15 Minuten Zeit gegeben, um die maximale Speicherfüllstandsmarke zu verlassen. Die Datenverzeichnisse waren auf jedem der drei Server letztendlich 264 GB, 34 GB bzw. 33 GB groß.
Bewertung der ClickHouse-Clusterleistung
Was ich als Nächstes sah, war die schnellste Zeit, die ich je gesehen habe, als jede Abfrage für eine Tabelle mehrmals ausgeführt wurde trips_mergetree_x3.
$ clickhouse-client --host=0.0.0.0Der folgende Vorgang wurde in 2.449 Sekunden abgeschlossen.
SELECT cab_type, count(*)
FROM trips_mergetree_x3
GROUP BY cab_type;Der folgende Vorgang wurde in 0.691 Sekunden abgeschlossen.
SELECT passenger_count,
avg(total_amount)
FROM trips_mergetree_x3
GROUP BY passenger_count;Das Folgende wurde in 0 Sekunden abgeschlossen.
SELECT passenger_count,
toYear(pickup_date) AS year,
count(*)
FROM trips_mergetree_x3
GROUP BY passenger_count,
year;Der folgende Vorgang wurde in 0.983 Sekunden abgeschlossen.
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;Zum Vergleich habe ich dieselben Abfragen für eine MergeTree-basierte Tabelle ausgeführt, die sich ausschließlich auf dem ersten Server befindet.
Leistungsbewertung eines ClickHouse-Knotens
Was ich als Nächstes sah, war die schnellste Zeit, die ich je gesehen habe, als jede Abfrage für eine Tabelle mehrmals ausgeführt wurde trips_mergetree_x3.
Der folgende Vorgang wurde in 0.241 Sekunden abgeschlossen.
SELECT cab_type, count(*)
FROM trips_mergetree
GROUP BY cab_type;Der folgende Vorgang wurde in 0.826 Sekunden abgeschlossen.
SELECT passenger_count,
avg(total_amount)
FROM trips_mergetree
GROUP BY passenger_count;Der folgende Vorgang wurde in 1.209 Sekunden abgeschlossen.
SELECT passenger_count,
toYear(pickup_date) AS year,
count(*)
FROM trips_mergetree
GROUP BY passenger_count,
year;Der folgende Vorgang wurde in 1.781 Sekunden abgeschlossen.
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;Überlegungen zu den Ergebnissen
Dies ist das erste Mal, dass eine kostenlose CPU-basierte Datenbank in meinen Tests eine GPU-basierte Datenbank übertreffen konnte. Diese GPU-basierte Datenbank wurde seitdem zwei Revisionen unterzogen, aber die Leistung, die ClickHouse auf einem einzelnen Knoten lieferte, ist dennoch sehr beeindruckend.
Gleichzeitig sind die Gemeinkosten um eine Größenordnung höher, wenn Abfrage 1 auf einer verteilten Engine ausgeführt wird. Ich hoffe, dass ich bei meiner Recherche für diesen Beitrag etwas übersehen habe, denn es wäre schön zu sehen, wie sich die Abfragezeiten verkürzen, wenn ich dem Cluster weitere Knoten hinzufüge. Es ist jedoch großartig, dass sich die Leistung beim Ausführen anderer Abfragen um etwa das Zweifache erhöhte.
Es wäre schön, wenn sich ClickHouse dahingehend weiterentwickeln würde, Speicher und Rechenleistung zu trennen, sodass sie unabhängig voneinander skaliert werden können. Die im letzten Jahr hinzugefügte HDFS-Unterstützung könnte ein Schritt in diese Richtung sein. Wenn eine einzelne Abfrage durch das Hinzufügen weiterer Knoten zum Cluster beschleunigt werden kann, sind die Zukunftsaussichten dieser Software hinsichtlich der Datenverarbeitung sehr rosig.
Vielen Dank, dass Sie sich die Zeit genommen haben, diesen Beitrag zu lesen. Ich biete Beratungs-, Architektur- und Praxisentwicklungsdienstleistungen für Kunden in Nordamerika und Europa an. Wenn Sie besprechen möchten, wie meine Vorschläge Ihrem Unternehmen helfen können, kontaktieren Sie mich bitte über .
Source: habr.com