PostgreSQL, ClickHouse ਅਤੇ clickhousedb_fdw (PostgreSQL) ਵਿੱਚ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਸਵਾਲਾਂ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰਨਾ

ਇਸ ਅਧਿਐਨ ਵਿੱਚ, ਮੈਂ ਇਹ ਦੇਖਣਾ ਚਾਹੁੰਦਾ ਸੀ ਕਿ PostgreSQL ਦੀ ਬਜਾਏ ਇੱਕ ClickHouse ਡੇਟਾ ਸਰੋਤ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਕਿਹੜੇ ਸੁਧਾਰ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਮੈਨੂੰ ਕਲਿਕਹਾਊਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਪ੍ਰਾਪਤ ਉਤਪਾਦਕਤਾ ਲਾਭਾਂ ਬਾਰੇ ਪਤਾ ਹੈ। ਕੀ ਇਹ ਲਾਭ ਜਾਰੀ ਰਹਿਣਗੇ ਜੇਕਰ ਮੈਂ ਇੱਕ ਵਿਦੇਸ਼ੀ ਡੇਟਾ ਰੈਪਰ (FDW) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ PostgreSQL ਤੋਂ ਕਲਿਕਹਾਊਸ ਤੱਕ ਪਹੁੰਚ ਕਰਦਾ ਹਾਂ?

ਅਧਿਐਨ ਕੀਤੇ ਗਏ ਡੇਟਾਬੇਸ ਵਾਤਾਵਰਣ ਹਨ PostgreSQL v11, clickhousedb_fdw ਅਤੇ ClickHouse ਡੇਟਾਬੇਸ। ਆਖਰਕਾਰ, PostgreSQL v11 ਤੋਂ ਅਸੀਂ ਆਪਣੇ clickhousedb_fdw ਦੁਆਰਾ ਕਲਿਕਹਾਊਸ ਡੇਟਾਬੇਸ ਤੱਕ ਰੂਟ ਕੀਤੀਆਂ ਵੱਖ-ਵੱਖ SQL ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਚਲਾਵਾਂਗੇ। ਅਸੀਂ ਫਿਰ ਦੇਖਾਂਗੇ ਕਿ FDW ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਮੂਲ PostgreSQL ਅਤੇ ਮੂਲ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਚੱਲ ਰਹੀਆਂ ਇੱਕੋ ਸਵਾਲਾਂ ਨਾਲ ਕਿਵੇਂ ਤੁਲਨਾ ਕਰਦੀ ਹੈ।

ਕਲਿਕਹਾਊਸ ਡੇਟਾਬੇਸ

ਕਲਿਕਹਾਊਸ ਇੱਕ ਓਪਨ ਸੋਰਸ ਕਾਲਮਨਰ ਡੇਟਾਬੇਸ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ ਹੈ ਜੋ ਰਵਾਇਤੀ ਡੇਟਾਬੇਸ ਪਹੁੰਚਾਂ ਨਾਲੋਂ 100-1000 ਗੁਣਾ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ, ਇੱਕ ਸਕਿੰਟ ਤੋਂ ਵੀ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਅਰਬ ਤੋਂ ਵੱਧ ਕਤਾਰਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦੇ ਸਮਰੱਥ ਹੈ।

Clickhousedb_fdw

clickhousedb_fdw - ਕਲਿਕਹਾਊਸ ਡੇਟਾਬੇਸ, ਜਾਂ FDW ਲਈ ਬਾਹਰੀ ਡਾਟਾ ਰੈਪਰ, ਪਰਕੋਨਾ ਦਾ ਇੱਕ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਹੈ। ਇੱਥੇ ਪ੍ਰੋਜੈਕਟ ਦੇ GitHub ਰਿਪੋਜ਼ਟਰੀ ਲਈ ਇੱਕ ਲਿੰਕ ਹੈ.

ਮਾਰਚ ਵਿੱਚ ਮੈਂ ਇੱਕ ਬਲੌਗ ਲਿਖਿਆ ਜੋ ਤੁਹਾਨੂੰ ਸਾਡੇ FDW ਬਾਰੇ ਹੋਰ ਦੱਸਦਾ ਹੈ.

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖੋਗੇ, ਇਹ ClickHouse ਲਈ ਇੱਕ FDW ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ PostgreSQL v11 ਸਰਵਰ ਤੋਂ ClickHouse ਡੇਟਾਬੇਸ ਤੋਂ SELECT, ਅਤੇ INSERT INTO ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

FDW ਉੱਨਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਐਗਰੀਗੇਟ ਅਤੇ ਜੁਆਇਨ। ਇਹ ਰਿਮੋਟ ਸਰਵਰ ਦੇ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਹਨਾਂ ਸੰਸਾਧਨਾਂ-ਗਠਨ ਕਾਰਜਾਂ ਲਈ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਸੁਧਾਰ ਕਰਦਾ ਹੈ।

ਬੈਂਚਮਾਰਕ ਵਾਤਾਵਰਣ

• ਸੁਪਰਮਾਈਕ੍ਰੋ ਸਰਵਰ:
  • Intel® Xeon® CPU E5-2683 v3 @ 2.00GHz
  • 2 ਸਾਕਟ / 28 ਕੋਰ / 56 ਥਰਿੱਡ
  • ਮੈਮੋਰੀ: 256 ਜੀਬੀ ਰੈਮ
  • ਸਟੋਰੇਜ: Samsung SM863 1.9TB Enterprise SSD
  • ਫਾਈਲ ਸਿਸਟਮ: ext4/xfs
• OS: Linux smblade01 4.15.0-42-ਆਮ #45~16.04.1-Ubuntu
• PostgreSQL: ਸੰਸਕਰਣ 11

ਬੈਂਚਮਾਰਕ ਟੈਸਟ

ਇਸ ਟੈਸਟ ਲਈ ਕੁਝ ਮਸ਼ੀਨ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਡੇਟਾ ਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਬਜਾਏ, ਅਸੀਂ 1987 ਤੋਂ 2018 ਤੱਕ "ਸਮੇਂ ਦੀ ਰਿਪੋਰਟ ਕੀਤੇ ਆਪਰੇਟਰ ਟਾਈਮ ਦੁਆਰਾ ਉਤਪਾਦਕਤਾ" ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਤੁਸੀਂ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦੇ ਹੋ ਇੱਥੇ ਉਪਲਬਧ ਸਾਡੀ ਸਕ੍ਰਿਪਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ.

ਡੇਟਾਬੇਸ ਦਾ ਆਕਾਰ 85 GB ਹੈ, 109 ਕਾਲਮਾਂ ਦੀ ਇੱਕ ਸਾਰਣੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਬੈਂਚਮਾਰਕ ਸਵਾਲ

ਇੱਥੇ ਉਹ ਸਵਾਲ ਹਨ ਜੋ ਮੈਂ ClickHouse, clickhousedb_fdw ਅਤੇ PostgreSQL ਦੀ ਤੁਲਨਾ ਕਰਨ ਲਈ ਵਰਤੀਆਂ ਸਨ।

Q#
ਪੁੱਛਗਿੱਛ ਵਿੱਚ ਏਗਰੀਗੇਟਸ ਅਤੇ ਇਸ ਅਨੁਸਾਰ ਸਮੂਹ ਸ਼ਾਮਲ ਹਨ

Q1
ਹਫਤੇ ਦਾ ਦਿਨ ਚੁਣੋ, ਓਨਟਾਈਮ ਤੋਂ ਗਿਣੋ (*) ਕਿੱਥੇ ਸਾਲ >= 2000 ਅਤੇ ਸਾਲ <= 2008 ਦਿਨ-ਆਫ ਹਫਤੇ ਦੇ ਕ੍ਰਮ ਦੁਆਰਾ c DESC ਦੁਆਰਾ ਸਮੂਹ;

Q2
ਹਫਤੇ ਦਾ ਦਿਨ ਚੁਣੋ, ਓਨਟਾਈਮ ਤੋਂ ਗਿਣੋ (*) ਕਿੱਥੇ DepDelay>10 ਅਤੇ ਸਾਲ >= 2000 ਅਤੇ ਸਾਲ <= 2008 ਗਰੁੱਪ BY DayOfweek ORDER by c DESC;

Q3
ਮੂਲ ਚੁਣੋ, ਗਣਨਾ(*) ਓਨਟਾਈਮ ਤੋਂ c ਦੇ ਤੌਰ 'ਤੇ ਕਰੋ ਜਿੱਥੇ DepDelay>10 ਅਤੇ ਸਾਲ >= 2000 ਅਤੇ ਸਾਲ <= 2008 ਮੂਲ ਆਰਡਰ ਦੁਆਰਾ c DESC ਸੀਮਾ 10 ਦੁਆਰਾ ਸਮੂਹ;

Q4
ਕੈਰੀਅਰ ਚੁਣੋ, ਗਿਣਤੀ() ਓਨਟਾਈਮ ਤੋਂ ਕਿੱਥੇ DepDelay>10 ਅਤੇ ਸਾਲ = 2007 ਕੈਰੀਅਰ ਦੁਆਰਾ ਗਿਣਨ ਦੁਆਰਾ ਸਮੂਹ () DESC;

Q5
ਚੁਣੋ a. ਕੈਰੀਅਰ, c, c2, c1000/c2 ਤੋਂ c3 ਵਜੋਂ (ਚੁਣੋ ਕੈਰੀਅਰ, ਗਿਣਤੀ() ਓਨਟਾਈਮ ਤੋਂ ਕਿੱਥੇ DepDelay>10 ਅਤੇ ਸਾਲ = 2007 ਕੈਰੀਅਰ ਦੁਆਰਾ ਗਰੁੱਪ ) ਇੱਕ ਅੰਦਰੂਨੀ ਜੁੜੋ ( ਕੈਰੀਅਰ ਨੂੰ ਚੁਣੋ, ਗਿਣਤੀ (*) ਓਨਟਾਈਮ ਤੋਂ c2 ਦੇ ਰੂਪ ਵਿੱਚ ਜਿੱਥੇ ਸਾਲ = ਕੈਰੀਅਰ ਦੁਆਰਾ 2007 ਗਰੁੱਪ) b a.Carrier=b.ORDERCarrier 'ਤੇ C3 DESC ਦੁਆਰਾ;

Q6
ਚੁਣੋ a. ਕੈਰੀਅਰ, c, c2, c1000/c2 ਤੋਂ c3 ਵਜੋਂ (ਚੁਣੋ ਕੈਰੀਅਰ, ਗਿਣਤੀ() ਓਨਟਾਈਮ ਤੋਂ ਕਿੱਥੇ DepDelay>10 ਅਤੇ ਸਾਲ >= 2000 ਅਤੇ ਸਾਲ <= ਕੈਰੀਅਰ ਦੁਆਰਾ 2008 ਗਰੁੱਪ) ਇੱਕ ਅੰਦਰੂਨੀ ਜੁੜੋ (ਕੈਰੀਅਰ ਨੂੰ ਚੁਣੋ, ਗਿਣਤੀ (*) ਓਨਟਾਈਮ ਤੋਂ c2 ਵਜੋਂ ਜਿੱਥੇ ਸਾਲ >= 2000 ਅਤੇ ਸਾਲ <= 2008 ਕੈਰੀਅਰ ) b 'ਤੇ a.Carrier=b.C3 DESC ਦੁਆਰਾ ਕੈਰੀਅਰ ਆਰਡਰ;

Q7
ਕੈਰੀਅਰ ਚੁਣੋ, ਔਸਤ(DepDelay) * 1000 AS c3 ਓਨਟਾਈਮ ਤੋਂ ਕਿੱਥੇ ਸਾਲ >= 2000 ਅਤੇ ਸਾਲ <= ਕੈਰੀਅਰ ਦੁਆਰਾ 2008 ਗਰੁੱਪ;

Q8
ਸਾਲ ਚੁਣੋ, ਔਨਟਾਈਮ ਤੋਂ ਔਸਤ(DepDelay) ਸਾਲ ਅਨੁਸਾਰ ਗਰੁੱਪ;

Q9
ਸਾਲ ਚੁਣੋ, ਸਾਲ ਦੇ ਹਿਸਾਬ ਨਾਲ ਔਨਟਾਈਮ ਗਰੁੱਪ ਤੋਂ c1 ਵਜੋਂ ਗਿਣੋ;

Q10
ਔਨਟਾਈਮ ਤੋਂ ਔਸਤ (cnt) ਚੁਣੋ (ਸਾਲ, ਮਹੀਨਾ, ਗਿਣਤੀ (*) ਔਨਟਾਈਮ ਤੋਂ cnt ਦੇ ਤੌਰ 'ਤੇ ਚੁਣੋ ਜਿੱਥੇ DepDel15=1 ਸਾਲ, ਮਹੀਨੇ ਦੁਆਰਾ ਗਰੁੱਪ) a;

Q11
(ਸਾਲ,ਮਹੀਨਾ,ਗਿਣਤੀ(*) ਤੋਂ ਔਨਟਾਈਮ ਗਰੁੱਪ ਤੋਂ c1 ਵਜੋਂ ਸਾਲ,ਮਹੀਨੇ ਦੀ ਚੋਣ ਕਰੋ) a;

Q12
OriginCityName, DestCityName, ਗਣਨਾ(*) ਨੂੰ ਓਨਟਾਈਮ ਤੋਂ ਚੁਣੋ, ਜਿਵੇਂ ਕਿ ਮੂਲ ਸ਼ਹਿਰ ਦੇ ਨਾਮ ਦੁਆਰਾ ਗਰੁੱਪ, C DESC ਸੀਮਾ 10 ਦੁਆਰਾ DestCityName ਆਰਡਰ;

Q13
OriginCityName ਨੂੰ ਚੁਣੋ, C DESC LIMIT 10 ਦੁਆਰਾ OriginCityName ਦੇ ਆਰਡਰ ਦੁਆਰਾ ਓਨਟਾਈਮ ਗਰੁੱਪ ਦੇ ਰੂਪ ਵਿੱਚ ਗਿਣਤੀ(*);

ਪੁੱਛਗਿੱਛ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ

Q14
ਚੁਣੋ a.Year, c1/c2 FROM ( ਸਾਲ ਚੁਣੋ, ਗਿਣਤੀ()1000 ਓਨਟਾਈਮ ਤੋਂ c1 ਦੇ ਤੌਰ 'ਤੇ ਜਿੱਥੇ DepDelay>ਸਾਲ ਦੇ ਹਿਸਾਬ ਨਾਲ 10 ਗਰੁੱਪ) ਇੱਕ ਅੰਦਰੂਨੀ ਜੁੜੋ (ਸਾਲ ਚੁਣੋ, ਗਿਣਤੀ (*) c2 ਦੇ ਤੌਰ 'ਤੇ ਆਨਟਾਈਮ ਗਰੁੱਪ ਤੋਂ ਸਾਲ ਦੇ ਹਿਸਾਬ ਨਾਲ) b ਨੂੰ a.Year=b.year ORDER BY a.Year;

Q15
ਚੁਣੋ a."ਸਾਲ", c1/c2 FROM ("ਸਾਲ" ਚੁਣੋ, ਗਿਣਤੀ()1000 ਫੌਂਟਾਈਮ ਤੋਂ c1 ਦੇ ਤੌਰ 'ਤੇ ਜਿੱਥੇ “DepDelay”>10 GROUP BY “Year”) ਇੱਕ ਅੰਦਰੂਨੀ ਜੁੜੋ (“ਸਾਲ” ਨੂੰ ਚੁਣੋ, “ਸਾਲ” ਦੁਆਰਾ ਫੌਂਟਾਈਮ ਗਰੁੱਪ ਤੋਂ c2 ਵਜੋਂ ਗਿਣੋ (*) ) a.”Year”=b ਉੱਤੇ। "ਸਾਲ";

ਸਾਰਣੀ-1: ਬੈਂਚਮਾਰਕ ਵਿੱਚ ਵਰਤੇ ਗਏ ਸਵਾਲ

ਪੁੱਛਗਿੱਛ ਅਮਲਾਂ

ਵੱਖ-ਵੱਖ ਡਾਟਾਬੇਸ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਚੱਲਣ ਵੇਲੇ ਹਰੇਕ ਸਵਾਲ ਦੇ ਨਤੀਜੇ ਇੱਥੇ ਦਿੱਤੇ ਗਏ ਹਨ: PostgreSQL ਸਮੇਤ ਅਤੇ ਬਿਨਾਂ ਸੂਚਕਾਂਕ, ਮੂਲ ਕਲਿਕਹਾਊਸ ਅਤੇ clickhousedb_fdw। ਸਮਾਂ ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ।

Q#
PostgreSQL
PostgreSQL (ਇੰਡੈਕਸਡ)
ਕਲਿਕਹਾouseਸ
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

ਸਾਰਣੀ-1: ਬੈਂਚਮਾਰਕ ਵਿੱਚ ਵਰਤੇ ਗਏ ਸਵਾਲਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਲੱਗਿਆ ਸਮਾਂ

ਨਤੀਜੇ ਵੇਖੋ

ਗ੍ਰਾਫ਼ ਕਿਊਰੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ ਨੂੰ ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਦਿਖਾਉਂਦਾ ਹੈ, X ਧੁਰਾ ਉਪਰੋਕਤ ਟੇਬਲ ਤੋਂ ਪੁੱਛਗਿੱਛ ਨੰਬਰ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ Y ਧੁਰਾ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਾਂ ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਦਿਖਾਉਂਦਾ ਹੈ। Clickhousedb_fdw ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪੋਸਟਗ੍ਰੇਸ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੇ ਕਲਿਕਹਾਊਸ ਨਤੀਜੇ ਅਤੇ ਡੇਟਾ ਦਿਖਾਇਆ ਗਿਆ ਹੈ। ਸਾਰਣੀ ਤੋਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ PostgreSQL ਅਤੇ ClickHouse ਵਿਚਕਾਰ ਬਹੁਤ ਵੱਡਾ ਅੰਤਰ ਹੈ, ਪਰ Clickhouse ਅਤੇ clickhousedb_fdw ਵਿਚਕਾਰ ਬਹੁਤ ਘੱਟ ਅੰਤਰ ਹੈ।

ਇਹ ਗ੍ਰਾਫ ClickhouseDB ਅਤੇ clickhousedb_fdw ਵਿਚਕਾਰ ਅੰਤਰ ਦਿਖਾਉਂਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਸਵਾਲਾਂ ਵਿੱਚ, FDW ਓਵਰਹੈੱਡ ਇੰਨਾ ਉੱਚਾ ਨਹੀਂ ਹੈ ਅਤੇ Q12 ਨੂੰ ਛੱਡ ਕੇ ਸ਼ਾਇਦ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਸ ਪੁੱਛਗਿੱਛ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਅਤੇ ਇੱਕ ORDER BY ਧਾਰਾ ਸ਼ਾਮਲ ਹੈ। ORDER BY GROUP/BY ਕਲਾਜ਼ ਦੇ ਕਾਰਨ, ORDER BY ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਹੇਠਾਂ ਨਹੀਂ ਆਉਂਦਾ।

ਸਾਰਣੀ 2 ਵਿੱਚ ਅਸੀਂ ਪ੍ਰਸ਼ਨ Q12 ਅਤੇ Q13 ਵਿੱਚ ਸਮੇਂ ਦੀ ਛਾਲ ਦੇਖਦੇ ਹਾਂ। ਦੁਬਾਰਾ, ਇਹ ORDER BY ਧਾਰਾ ਦੇ ਕਾਰਨ ਹੁੰਦਾ ਹੈ। ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ, ਮੈਂ ORDER BY ਧਾਰਾ ਦੇ ਨਾਲ ਅਤੇ ਬਿਨਾਂ ਸਵਾਲ Q-14 ਅਤੇ Q-15 ਚਲਾਏ। ORDER BY ਧਾਰਾ ਦੇ ਬਿਨਾਂ ਪੂਰਾ ਹੋਣ ਦਾ ਸਮਾਂ 259ms ਹੈ ਅਤੇ ORDER BY ਧਾਰਾ ਦੇ ਨਾਲ ਇਹ 1364212 ਹੈ। ਇਸ ਪੁੱਛਗਿੱਛ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਲਈ ਮੈਂ ਦੋਵੇਂ ਸਵਾਲਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰ ਰਿਹਾ ਹਾਂ ਅਤੇ ਇੱਥੇ ਵਿਆਖਿਆ ਦੇ ਨਤੀਜੇ ਹਨ।

Q15: ਧਾਰਾ ਦੁਆਰਾ ਆਰਡਰ ਤੋਂ ਬਿਨਾਂ

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: ਕਲਾਜ਼ ਦੁਆਰਾ ਆਰਡਰ ਤੋਂ ਬਿਨਾਂ ਪੁੱਛਗਿੱਛ

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: ਕਲਾਜ਼ ਦੁਆਰਾ ਆਰਡਰ ਨਾਲ ਪੁੱਛਗਿੱਛ

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: ਕਲਾਜ਼ ਦੁਆਰਾ ਆਰਡਰ ਦੇ ਨਾਲ ਪੁੱਛਗਿੱਛ ਯੋਜਨਾ

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)

ਸਿੱਟਾ

ਇਹਨਾਂ ਪ੍ਰਯੋਗਾਂ ਦੇ ਨਤੀਜੇ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਕਲਿਕਹਾਊਸ ਅਸਲ ਵਿੱਚ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ, ਅਤੇ clickhousedb_fdw PostgreSQL ਤੋਂ Clickhouse ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਲਾਭਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਕਿ clickhousedb_fdw ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਕੁਝ ਓਵਰਹੈੱਡ ਹੁੰਦਾ ਹੈ, ਇਹ ਕਲਿਕਹਾਊਸ ਡੇਟਾਬੇਸ 'ਤੇ ਨੇਟਿਵ ਤੌਰ 'ਤੇ ਚਲਾਉਣ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੇ ਮੁਕਾਬਲੇ ਬਹੁਤ ਘੱਟ ਅਤੇ ਤੁਲਨਾਤਮਕ ਹੈ। ਇਹ ਇਹ ਵੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ PostgreSQL ਵਿੱਚ fdw ਸ਼ਾਨਦਾਰ ਨਤੀਜੇ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਕਲਿਕਹਾਊਸ ਰਾਹੀਂ ਟੈਲੀਗ੍ਰਾਮ ਚੈਟ https://t.me/clickhouse_ru
PostgreSQL ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਟੈਲੀਗ੍ਰਾਮ ਚੈਟ https://t.me/pgsql

ਸਰੋਤ: www.habr.com