Tłumaczenie artykułu zostało przygotowane specjalnie dla studentów kursu .
to kolumnowa baza danych typu open source. To wspaniałe środowisko, w którym setki analityków może szybko przeglądać szczegółowe dane, nawet jeśli dziennie wprowadzane są dziesiątki miliardów nowych rekordów. Koszty infrastruktury obsługującej taki system mogą sięgać nawet 100 10 dolarów rocznie, a potencjalnie o połowę mniej, w zależności od sposobu użytkowania. W pewnym momencie instalacja ClickHouse firmy Yandex Metrics zawierała XNUMX bilionów rekordów. Oprócz Yandex, ClickHouse odniósł również sukces w Bloomberg i Cloudflare.
Dwa lata temu spędziłem baz danych przy użyciu jednej maszyny i tak się stało darmowe oprogramowanie baz danych, jakie kiedykolwiek widziałem. Od tego czasu programiści nie przestają dodawać funkcji, w tym obsługi kompresji Kafka, HDFS i ZStandard. W zeszłym roku dodali obsługę metod kompresji kaskadowej i kodowanie stało się możliwe. Podczas kompresji danych szeregów czasowych wartości mierników można dobrze skompresować za pomocą kodowania delta, ale w przypadku liczników lepiej byłoby zastosować kodowanie delta po delta. Dobra kompresja stała się kluczem do wydajności ClickHouse.
ClickHouse składa się ze 170 tysięcy linii kodu C++, nie licząc bibliotek innych firm, i jest jedną z najmniejszych baz kodu rozproszonych baz danych. Dla porównania, SQLite nie obsługuje dystrybucji i składa się z 235 tysięcy linii kodu C. W chwili pisania tego tekstu w ClickHouse pracowało 207 inżynierów, a intensywność zatwierdzeń ostatnio wzrosła.
W marcu 2017 r. ClickHouse rozpoczął prowadzenie jako łatwy sposób śledzenia rozwoju. Podzielili także monolityczny plik dokumentacji na hierarchię plików opartą na Markdown. Problemy i funkcje są śledzone za pośrednictwem GitHuba, a ogólnie rzecz biorąc, w ciągu ostatnich kilku lat oprogramowanie stało się znacznie bardziej dostępne.
W tym artykule przyjrzę się wydajności klastra ClickHouse na AWS EC2 przy użyciu 36-rdzeniowych procesorów i pamięci NVMe.
AKTUALIZACJA: Tydzień po opublikowaniu tego posta ponownie przeprowadziłem test z ulepszoną konfiguracją i uzyskałem znacznie lepsze wyniki. Ten post został zaktualizowany, aby odzwierciedlić te zmiany.
Uruchomienie klastra AWS EC2
W tym poście użyję trzech instancji c5d.9xlarge EC2. Każdy z nich zawiera 36 wirtualnych procesorów, 72 GB pamięci RAM, 900 GB pamięci NVMe SSD i obsługuje sieć 10 Gigabit. Kosztują 1,962 USD za godzinę w regionie eu-west-1, jeśli działają na żądanie. Jako systemu operacyjnego będę używać Ubuntu Server 16.04 LTS.
Zapora sieciowa jest skonfigurowana tak, aby każda maszyna mogła komunikować się ze sobą bez ograniczeń, a tylko mój adres IPv4 jest umieszczany na białej liście przez SSH w klastrze.
Dysk NVMe w stanie gotowości operacyjnej
Aby ClickHouse działał, utworzę system plików w formacie EXT4 na dysku NVMe na każdym z serwerów.
$ sudo mkfs -t ext4 /dev/nvme1n1
$ sudo mkdir /ch
$ sudo mount /dev/nvme1n1 /chPo skonfigurowaniu wszystkiego możesz zobaczyć punkt podłączenia i 783 GB miejsca dostępnego w każdym systemie.
$ 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% /chZbiór danych, którego użyję w tym teście, to zrzut danych wygenerowany na podstawie 1.1 miliarda przejazdów taksówką w Nowym Jorku w ciągu sześciu lat. Na blogu szczegółowo opisuje, w jaki sposób zebrałem ten zestaw danych. Są przechowywane w AWS S3, więc skonfiguruję AWS CLI za pomocą moich kluczy dostępu i tajnych kluczy.
$ sudo apt update
$ sudo apt install awscli
$ aws configureUstawię limit jednoczesnych żądań klienta na 100, aby pliki pobierały się szybciej niż ustawienia domyślne.
$ aws configure set
default.s3.max_concurrent_requests
100Pobiorę zestaw danych o przejazdach taksówką z AWS S3 i zapiszę go na dysku NVMe na pierwszym serwerze. Ten zbiór danych ma około 104 GB w formacie CSV skompresowanym przy użyciu GZIP.
$ sudo mkdir -p /ch/csv
$ sudo chown -R ubuntu /ch/csv
$ aws s3 sync s3://<bucket>/csv /ch/csvInstalacja ClickHouse
Zainstaluję dystrybucję OpenJDK dla Java 8, ponieważ jest ona wymagana do uruchomienia Apache ZooKeeper, który jest wymagany do rozproszonej instalacji ClickHouse na wszystkich trzech komputerach.
$ sudo apt update
$ sudo apt install
openjdk-8-jre
openjdk-8-jdk-headless
Następnie ustawiam zmienną środowiskową JAVA_HOME.
$ sudo vi /etc/profile
export JAVA_HOME=/usr
$ source /etc/profileNastępnie użyję systemu zarządzania pakietami Ubuntu, aby zainstalować ClickHouse 18.16.1, spojrzenie i ZooKeeper na wszystkich trzech komputerach.
$ 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
zookeeperdUtworzę katalog dla ClickHouse, a także dokonam nadpisań konfiguracyjnych na wszystkich trzech serwerach.
$ 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.confTo są zastąpienia konfiguracji, których będę używać.
<?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>Następnie uruchomię ZooKeeper i serwer ClickHouse na wszystkich trzech komputerach.
$ sudo /etc/init.d/zookeeper start
$ sudo service clickhouse-server startPrzesyłanie danych do ClickHouse
Na pierwszym serwerze utworzę tabelę podróży (trips), który będzie przechowywać zbiór danych o przejazdach taksówkami przy użyciu silnika 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;
Następnie wyodrębniam i ładuję każdy z plików CSV do tabeli podróży (trips). Poniższy dystans został ukończony w 55 minut i 10 sekund. Po tej operacji rozmiar katalogu danych wyniósł 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)Szybkość importu wynosiła 155 MB nieskompresowanej zawartości CSV na sekundę. Podejrzewam, że było to spowodowane wąskim gardłem w dekompresji GZIP. Szybsze mogłoby być równoległe rozpakowanie wszystkich spakowanych plików gzip przy użyciu xargs, a następnie załadowanie rozpakowanych danych. Poniżej znajduje się opis informacji zgłoszonych podczas procesu importu pliku 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:1HPrzed kontynuowaniem zwolnię miejsce na dysku NVMe, usuwając oryginalne pliki CSV.
$ sudo rm -fr /ch/csvKonwertuj na formę kolumnową
Silnik Log ClickHouse będzie przechowywać dane w formacie zorientowanym na wiersze. Aby szybciej wysyłać zapytania do danych, konwertuję je do formatu kolumnowego za pomocą silnika MergeTree.
$ clickhouse-client --host=0.0.0.0Poniższy dystans został ukończony w 34 minuty i 50 sekund. Po tej operacji rozmiar katalogu danych wyniósł 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;Tak wyglądał wynik rzutu oka podczas operacji:
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)W ostatnim teście kilka kolumn zostało przekonwertowanych i przeliczonych. Odkryłem, że niektóre z tych funkcji nie działają już zgodnie z oczekiwaniami w tym zbiorze danych. Aby rozwiązać ten problem, usunąłem niewłaściwe funkcje i załadowałem dane bez konwersji na bardziej szczegółowe typy.
Dystrybucja danych w klastrze
Rozprowadzę dane pomiędzy wszystkimi trzema węzłami klastra. Na początek poniżej utworzę tabelę na wszystkich trzech maszynach.
$ 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);Następnie upewnię się, że pierwszy serwer widzi wszystkie trzy węzły w klastrze.
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:
Następnie zdefiniuję nową tabelę na pierwszym serwerze bazującą na schemacie trips_mergetree_third i wykorzystuje silnik rozproszony.
CREATE TABLE trips_mergetree_x3
AS trips_mergetree_third
ENGINE = Distributed(perftest_3shards,
default,
trips_mergetree_third,
rand());Następnie skopiuję dane z tabeli opartej na MergeTree na wszystkie trzy serwery. Poniższy dystans został ukończony w 34 minuty i 44 sekundy.
INSERT INTO trips_mergetree_x3
SELECT * FROM trips_mergetree;Po powyższej operacji dałem ClickHouse 15 minut na odejście od znaku maksymalnego poziomu przechowywania. Katalogi danych ostatecznie wynosiły odpowiednio 264 GB, 34 GB i 33 GB na każdym z trzech serwerów.
Ocena wydajności klastra ClickHouse
Następnie zobaczyłem najszybszy czas wielokrotnego uruchamiania każdego zapytania w tabeli trips_mergetree_x3.
$ clickhouse-client --host=0.0.0.0Poniższy wynik ukończono w 2.449 sekundy.
SELECT cab_type, count(*)
FROM trips_mergetree_x3
GROUP BY cab_type;Poniższy wynik ukończono w 0.691 sekundy.
SELECT passenger_count,
avg(total_amount)
FROM trips_mergetree_x3
GROUP BY passenger_count;Poniższe ukończono w 0 sekundy.
SELECT passenger_count,
toYear(pickup_date) AS year,
count(*)
FROM trips_mergetree_x3
GROUP BY passenger_count,
year;Poniższy wynik ukończono w 0.983 sekundy.
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;Dla porównania uruchomiłem te same zapytania w tabeli opartej na MergeTree, która znajduje się wyłącznie na pierwszym serwerze.
Ocena wydajności jednego węzła ClickHouse
Następnie zobaczyłem najszybszy czas wielokrotnego uruchamiania każdego zapytania w tabeli trips_mergetree_x3.
Poniższy wynik ukończono w 0.241 sekundy.
SELECT cab_type, count(*)
FROM trips_mergetree
GROUP BY cab_type;Poniższy wynik ukończono w 0.826 sekundy.
SELECT passenger_count,
avg(total_amount)
FROM trips_mergetree
GROUP BY passenger_count;Poniższy wynik ukończono w 1.209 sekundy.
SELECT passenger_count,
toYear(pickup_date) AS year,
count(*)
FROM trips_mergetree
GROUP BY passenger_count,
year;Poniższy wynik ukończono w 1.781 sekundy.
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;Refleksje na temat wyników
Po raz pierwszy w moich testach bezpłatna baza danych oparta na procesorze była w stanie przewyższyć bazę danych opartą na GPU. Od tego czasu baza danych oparta na procesorach graficznych przeszła dwie wersje, ale wydajność, jaką ClickHouse zapewnił na jednym węźle, jest mimo to imponująca.
Jednocześnie podczas wykonywania Zapytania 1 w silniku rozproszonym koszty ogólne są o rząd wielkości wyższe. Mam nadzieję, że coś przeoczyłem w swoich badaniach do tego posta, ponieważ byłoby miło zobaczyć, jak czas zapytań spada w miarę dodawania kolejnych węzłów do klastra. Jednak super, że przy wykonywaniu innych zapytań wydajność wzrosła około 2 razy.
Byłoby miło zobaczyć, jak ClickHouse ewoluuje w kierunku możliwości oddzielenia pamięci masowej od obliczeń, aby mogły być skalowane niezależnie. Dodana w zeszłym roku obsługa HDFS może być krokiem w tym kierunku. Jeśli chodzi o obliczenia, jeśli pojedyncze zapytanie można przyspieszyć poprzez dodanie większej liczby węzłów do klastra, przyszłość tego oprogramowania rysuje się w bardzo jasnych barwach.
Dziękujemy za poświęcenie czasu na przeczytanie tego posta. Oferuję usługi konsultingowe, architektoniczne i programistyczne klientom w Ameryce Północnej i Europie. Jeśli chcesz omówić, w jaki sposób moje sugestie mogą pomóc Twojej firmie, skontaktuj się ze mną za pośrednictwem .
Źródło: www.habr.com