En ĉi tiu studo, mi volis vidi, kiajn rendimentajn plibonigojn oni povus atingi uzante datumfonton de ClickHouse anstataŭ PostgreSQL. Mi scias la produktivecajn avantaĝojn, kiujn mi ricevas de uzado de ClickHouse. Ĉu ĉi tiuj avantaĝoj daŭros se mi aliros ClickHouse de PostgreSQL uzante Foreign Data Wrapper (FDW)?
La datumbazaj medioj studitaj estas PostgreSQL v11, clickhousedb_fdw kaj ClickHouse datumbazo. Finfine, de PostgreSQL v11 ni funkcios diversajn SQL-demandojn direktitajn per nia clickhousedb_fdw al la datumbazo de ClickHouse. Ni tiam vidos kiel la agado de FDW komparas al la samaj demandoj kurantaj en denaska PostgreSQL kaj denaska ClickHouse.
Clickhouse Datumbazo
ClickHouse estas malfermfonta kolona datumbaza administradsistemo, kiu povas atingi rendimenton 100-1000 fojojn pli rapide ol tradiciaj datumbazaj aliroj, kapabla prilabori pli ol miliardo da vicoj en malpli ol sekundo.
Clickhousedb_fdw
clickhousedb_fdw - La ekstera datumbazo por la datumbazo ClickHouse, aŭ FDW, estas malfermfonta projekto de Percona. .
.
Kiel vi vidos, ĉi tio provizas FDW por ClickHouse, kiu ebligas SELECT el, kaj INSERT INTO, la ClickHouse-datumbazon de la PostgreSQL v11-servilo.
FDW subtenas altnivelajn funkciojn kiel agregado kaj kuniĝo. Ĉi tio signife plibonigas agadon uzante la rimedojn de la fora servilo por ĉi tiuj rimedintensaj operacioj.
Referenca medio
- Supermicro-servilo:
- CPU Intel® Xeon® E5-2683 v3 @ 2.00GHz
- 2 ingoj / 28 kernoj / 56 fadenoj
- Memoro: 256GB de RAM
- Stokado: Samsung SM863 1.9TB Enterprise SSD
- Dosiersistemo: ext4/xfs
- OS: Linukso smblade01 4.15.0-42-genera #45~16.04.1-Ubuntu
- PostgreSQL: versio 11
Benchmark-testoj
Prefere ol uzi iun maŝin-generitan datuman aron por ĉi tiu testo, ni uzis la datumojn de "Produktiveco laŭ Tempo Raportita Operaciista Tempo" de 1987 ĝis 2018. Vi povas aliri la datumojn .
La datumbaza grandeco estas 85 GB, provizante unu tabelon de 109 kolumnoj.
Benchmark Demandoj
Jen la demandoj, kiujn mi uzis por kompari ClickHouse, clickhousedb_fdw kaj PostgreSQL.
Q#
Demando Enhavas Agregaĵojn kaj Group By
Q1
ELEKTU TagonDeSemajno, kalkulu(*) AS c FROM ontime WHERE Jaro >= 2000 KAJ Jaro <= 2008 GRUPO BY TagoDeSemajno ORDU BY c DESC;
Q2
ELEKTU TagonDeSemajno, kalkulu(*) AS c FROM ontime WHERE DepDelay>10 KAJ Jaro>= 2000 KAJ Jaro <= 2008 GRUPO BY DayOfWeek ORDER BY c DESC;
Q3
ELEKTU Originon, kalkulu(*) AS c FROM ontime WHERE DepDelay>10 KAJ Jaro >= 2000 KAJ Jaro <= 2008 GRUPO BY Origino ORDO BY c DESC LIMITO 10;
Q4
Elektu portanton, kalkulu() FROM ontime WHERE DepDelay>10 AND Year = 2007 GROUP BY Kondukisto ORDER BY count() DESC;
Q5
SELECT a.Portanto, c, c2, c1000/c2 kiel c3 DE ( ELEKTU Kondukanton, kalkulu () AS c FROM ontime WHERE DepDelay>10 AND Year=2007 GROUP BY Carrier ) a INNER JOIN ( SELECT Carrier,count(*) AS c2 FROM ontime WHERE Jaro=2007 GROUP BY Carrier)b sur a.Carrier=b.Carrier ORDER BY c3 DESC;
Q6
SELECT a.Portanto, c, c2, c1000/c2 kiel c3 DE ( ELEKTU Kondukanton, kalkulu () AS c FROM ontime WHERE DepDelay>10 AND Year >= 2000 AND Year <= 2008 GROUP BY Transportisto) a INNER JOIN ( SELECT Carrier, count(*) AS c2 FROM ontime WHERE Jaro >= 2000 AND Year <= 2008 GROUP BY Transportisto ) b sur a.Portanto=b.Portanto MENDU BY c3 DESC;
Q7
ELEKTU Konduktanton, avg(DepDelay) * 1000 AS c3 FROM ontime WHERE Jaro >= 2000 KAJ Jaro <= 2008 GRUPO BY Konduktanto;
Q8
ELEKTU Jaron, avg(DepDelay) FROM ĝustatempe GRUPO BY Jaro;
Q9
elektu Jaron, kalkulu (*) kiel c1 el ĝustatempa grupo laŭ Jaro;
Q10
SELECT avg(cnt) FROM (SELECT Jaro,Monato,kalkulo(*) AS cnt FROM ontime WHERE DepDel15=1 GRUPO BY Jaro,Monato) a;
Q11
elektu avg(c1) el (elektu Jaron,Monato,kalkulu(*) kiel c1 el ontime grupo per Jaro,Monato) a;
Q12
ELEKTU OriginCityName, DestCityName, count(*) AS c FROM ontime GROUP BY OriginCityName, DestCityName ORDER BY c DESC LIMIT 10;
Q13
ELEKTU OriginCityName, kalkulu(*) AS c FROM ontime GRUPO BY OriginCityName ORDER BY c DESC LIMIT 10;
Demando Enhavas Kuniĝojn
Q14
SELECT a.Year, c1/c2 FROM (elektu Jaron, kalkulu()1000 kiel c1 de ontime WHERE DepDelay>10 GROUP BY Year) a INNER JOIN (elektu Jaron, kalkulu(*) kiel c2 de ontime GROUP BY Jaro ) b on a.Year=b.Year ORDER BY a.Year;
Q15
ELEKTU a."Jaron", c1/c2 FROM (elektu "Jaron", kalkulu()1000 as c1 FROM fonttime WHERE “DepDelay”>10 GROUP BY “Year”) a INNER JOIN (elektu “Jaro”, kalkulu(*) kiel c2 FROM fonttime GROUP BY “Year” ) b sur a.”Year”=b. "Jaro";
Tablo-1: Demandoj uzataj en benchmark
Demandu ekzekutojn
Jen la rezultoj de ĉiu el la konsultoj kiam ruliĝas en malsamaj datumbazaj agordoj: PostgreSQL kun kaj sen indeksoj, denaska ClickHouse kaj clickhousedb_fdw. La tempo estas montrata en milisekundoj.
Q#
PostgreSQL
PostgreSQL (Indeksita)
KlakuDomo
clickhousedb_fdw
Q1
27920
19634
23
57
Q2
35124
17301
50
80
Q3
34046
15618
67
115
Q4
31632
7667
25
37
Q5
47220
8976
27
60
Q6
58233
24368
55
153
Q7
30566
13256
52
91
Q8
38309
60511
112
179
Q9
20674
37979
31
81
Q10
34990
20102
56
148
Q11
30489
51658
37
155
Q12
39357
33742
186
1333
Q13
29912
30709
101
384
Q14
54126
39913
124
1364212
Q15
97258
30211
245
259
Tablo-1: Tempo necesa por ekzekuti la demandojn uzatajn en benchmark
Vidu rezultojn
La grafeo montras la demandan ekzekuttempon en milisekundoj, la X-akso montras la demandnombron el la supraj tabeloj, kaj la Y-akso montras la ekzekuttempon en milisekundoj. ClickHouse rezultoj kaj datumoj prenitaj de postgres uzante clickhousedb_fdw estas montritaj. De la tabelo vi povas vidi, ke estas grandega diferenco inter PostgreSQL kaj ClickHouse, sed minimuma diferenco inter ClickHouse kaj clickhousedb_fdw.
Ĉi tiu grafikaĵo montras la diferencon inter ClickhouseDB kaj clickhousedb_fdw. En plej multaj demandoj, la superkosto de FDW ne estas tiom alta kaj apenaŭ gravas krom Q12. Ĉi tiu demando inkluzivas kuniĝojn kaj klaŭzon ORDER BY. Pro la klaŭzo ORDER BY GROUP/BY, ORDER BY ne falas malsupren al ClickHouse.
En Tabelo 2 ni vidas la temposalton en demandoj Q12 kaj Q13. Denove, ĉi tio estas kaŭzita de la klaŭzo ORDER BY. Por konfirmi tion, mi kuris demandojn Q-14 kaj Q-15 kun kaj sen la klaŭzo ORDER BY. Sen la klaŭzo ORDER BY la fintempo estas 259ms kaj kun la klaŭzo ORDER BY ĝi estas 1364212. Por sencimigi ĉi tiun demandon mi klarigas ambaŭ la demandojn kaj jen la rezultoj de la klarigo.
Q15: Sen ORDER BY Klaŭzo
bm=# EXPLAIN VERBOSE SELECT a."Year", c1/c2
FROM (SELECT "Year", count(*)*1000 AS c1 FROM fontime WHERE "DepDelay" > 10 GROUP BY "Year") a
INNER JOIN(SELECT "Year", count(*) AS c2 FROM fontime GROUP BY "Year") b ON a."Year"=b."Year";Q15: Demando Sen ORDER BY Klaŭzo
QUERY PLAN
Hash Join (cost=2250.00..128516.06 rows=50000000 width=12)
Output: fontime."Year", (((count(*) * 1000)) / b.c2)
Inner Unique: true Hash Cond: (fontime."Year" = b."Year")
-> Foreign Scan (cost=1.00..-1.00 rows=100000 width=12)
Output: fontime."Year", ((count(*) * 1000))
Relations: Aggregate on (fontime)
Remote SQL: SELECT "Year", (count(*) * 1000) FROM "default".ontime WHERE (("DepDelay" > 10)) GROUP BY "Year"
-> Hash (cost=999.00..999.00 rows=100000 width=12)
Output: b.c2, b."Year"
-> Subquery Scan on b (cost=1.00..999.00 rows=100000 width=12)
Output: b.c2, b."Year"
-> Foreign Scan (cost=1.00..-1.00 rows=100000 width=12)
Output: fontime_1."Year", (count(*))
Relations: Aggregate on (fontime)
Remote SQL: SELECT "Year", count(*) FROM "default".ontime GROUP BY "Year"(16 rows)Q14: Demando Kun ORDER BY Klaŭzo
bm=# EXPLAIN VERBOSE SELECT a."Year", c1/c2 FROM(SELECT "Year", count(*)*1000 AS c1 FROM fontime WHERE "DepDelay" > 10 GROUP BY "Year") a
INNER JOIN(SELECT "Year", count(*) as c2 FROM fontime GROUP BY "Year") b ON a."Year"= b."Year"
ORDER BY a."Year";Q14: Demanda Plano kun ORDER BY Klaŭzo
QUERY PLAN
Merge Join (cost=2.00..628498.02 rows=50000000 width=12)
Output: fontime."Year", (((count(*) * 1000)) / (count(*)))
Inner Unique: true Merge Cond: (fontime."Year" = fontime_1."Year")
-> GroupAggregate (cost=1.00..499.01 rows=1 width=12)
Output: fontime."Year", (count(*) * 1000)
Group Key: fontime."Year"
-> Foreign Scan on public.fontime (cost=1.00..-1.00 rows=100000 width=4)
Remote SQL: SELECT "Year" FROM "default".ontime WHERE (("DepDelay" > 10))
ORDER BY "Year" ASC
-> GroupAggregate (cost=1.00..499.01 rows=1 width=12)
Output: fontime_1."Year", count(*) Group Key: fontime_1."Year"
-> Foreign Scan on public.fontime fontime_1 (cost=1.00..-1.00 rows=100000 width=4)
Remote SQL: SELECT "Year" FROM "default".ontime ORDER BY "Year" ASC(16 rows)konkludo
La rezultoj de ĉi tiuj eksperimentoj montras, ke ClickHouse ofertas vere bonan rendimenton, kaj clickhousedb_fdw ofertas la rendimentajn avantaĝojn de ClickHouse de PostgreSQL. Kvankam estas iom da ŝarĝo dum uzado de clickhousedb_fdw, ĝi estas nekonsiderinda kaj komparebla al la agado atingita per funkciado denaske en la datumbazo de ClickHouse. Ĉi tio ankaŭ konfirmas, ke fdw en PostgreSQL provizas bonegajn rezultojn.
Telegram-babilejo per Clickhouse
Telegram-babilado per PostgreSQL
fonto: www.habr.com