Ang mga modernong CPU adunay daghang mga cores. Sulod sa mga tuig, ang mga aplikasyon nagpadala mga pangutana sa mga database nga managsama. Kung kini usa ka pangutana sa taho sa daghang mga laray sa usa ka lamesa, kini molihok nga mas paspas kung mogamit daghang mga CPU, ug ang PostgreSQL nakahimo niini sukad sa bersyon 9.6.
Nagkinahanglan kini og 3 ka tuig aron mapatuman ang parallel query feature - kinahanglan namong isulat pag-usab ang code sa lain-laing mga ang-ang sa pagpatuman sa pangutana. Ang PostgreSQL 9.6 nagpaila sa imprastraktura aron mapauswag pa ang code. Sa sunod nga mga bersyon, ang ubang mga klase sa mga pangutana gipatuman nga managsama.
Mga pagbabag
- Ayaw i-enable ang parallel execution kung ang tanan nga mga core busy na, kung dili ang ubang mga hangyo mohinay.
- Labing hinungdanon, ang parehas nga pagproseso nga adunay taas nga mga kantidad sa WORK_MEM naggamit daghang memorya - ang matag pag-apil o pagsunud sa hash nagkuha sa memorya sa work_mem.
- Ang ubos nga latency nga OLTP nga mga pangutana dili mapadali pinaagi sa parallel execution. Ug kung ang pangutana mobalik sa usa ka laray, ang parallel nga pagproseso makapahinay ra niini.
- Ang mga developer ganahan nga mogamit sa TPC-H benchmark. Tingali adunay ka parehas nga mga pangutana alang sa hingpit nga parallel nga pagpatuman.
- PILI ra nga mga pangutana nga walay predicate locking ang gipatuman nga managsama.
- Usahay ang husto nga pag-indeks mas maayo kaysa sequential table scan sa parallel mode.
- Ang paghunong sa mga pangutana ug mga cursor wala gisuportahan.
- Ang mga function sa bintana ug ang gi-order nga set aggregate function dili parehas.
- Wala ka makakuha bisan unsa sa I/O workload.
- Walay parallel sorting algorithms. Apan ang mga pangutana nga adunay mga lahi mahimong ipatuman nga managsama sa pipila nga mga aspeto.
- Ilisan ang CTE (WITH ...) sa usa ka nested SELECT aron mahimo ang parallel nga pagproseso.
- Ang mga third-party nga mga wrapper sa datos wala pa mosuporta sa parallel nga pagproseso (apan mahimo nila!)
- Ang FULL OUTER JOIN wala gisuportahan.
- Gipugngan sa max_rows ang parallel nga pagproseso.
- Kung ang usa ka pangutana adunay usa ka function nga wala gimarkahan nga PARALLEL SAFE, kini usa ka thread.
- Ang SERIALIZABLE nga lebel sa pagkahimulag sa transaksyon nagpugong sa parallel nga pagproseso.
Pagsulay sa palibot
Ang mga nag-develop sa PostgreSQL misulay sa pagpakunhod sa oras sa pagtubag sa mga pangutana sa benchmark sa TPC-H. I-download ang benchmark ug . Kini usa ka dili opisyal nga paggamit sa TPC-H benchmark - dili alang sa database o pagtandi sa hardware.
- Pag-download sa TPC-H_Tools_v2.17.3.zip (o mas bag-ong bersyon) .
- Usba ang ngalan sa makefile.suite sa Makefile ug usba sama sa gihulagway dinhi: . I-compile ang code gamit ang make command.
- Paghimo data:
./dbgen -s 10nagmugna og 23 GB nga database. Kini igo na aron makita ang kalainan sa pasundayag sa parallel ug non-parallel nga mga pangutana. - Pag-convert sa mga file
tblвcsv с forиsed. - I-clone ang repositoryo
pg_tpchug kopyaha ang mga filecsvвpg_tpch/dss/data. - Paghimo mga pangutana nga adunay usa ka mando
qgen. - I-load ang datos sa database gamit ang command
./tpch.sh.
Parallel sequential scanning
Mahimong mas paspas kini dili tungod sa parallel nga pagbasa, apan tungod kay ang datos mikaylap sa daghang mga cores sa CPU. Sa modernong mga operating system, ang mga file sa datos sa PostgreSQL maayo nga naka-cache. Uban sa pagbasa sa unahan, posible nga makakuha usa ka mas dako nga bloke gikan sa pagtipig kaysa sa mga hangyo sa PG daemon. Busa, ang pasundayag sa pangutana dili limitado sa disk I/O. Gigamit niini ang mga siklo sa CPU aron:
- basaha ang mga laray sa tagsa-tagsa gikan sa mga pahina sa lamesa;
- itandi ang mga kantidad ug kondisyon sa string
WHERE.
Maghimo kita og usa ka yano nga pangutana select:
tpch=# explain analyze select l_quantity as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
Seq Scan on lineitem (cost=0.00..1964772.00 rows=58856235 width=5) (actual time=0.014..16951.669 rows=58839715 loops=1)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 1146337
Planning Time: 0.203 ms
Execution Time: 19035.100 msAng sunud-sunod nga pag-scan nagpatunghag daghang mga laray nga wala’y panagsama, mao nga ang pangutana gipatuman sa usa ka core sa CPU.
Kung modugang ka SUM(), imong makita nga ang duha ka mga workflow makatabang sa pagpadali sa pangutana:
explain analyze select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------
Finalize Aggregate (cost=1589702.14..1589702.15 rows=1 width=32) (actual time=8553.365..8553.365 rows=1 loops=1)
-> Gather (cost=1589701.91..1589702.12 rows=2 width=32) (actual time=8553.241..8555.067 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Partial Aggregate (cost=1588701.91..1588701.92 rows=1 width=32) (actual time=8547.546..8547.546 rows=1 loops=3)
-> Parallel Seq Scan on lineitem (cost=0.00..1527393.33 rows=24523431 width=5) (actual time=0.038..5998.417 rows=19613238 loops=3)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 382112
Planning Time: 0.241 ms
Execution Time: 8555.131 msParallel aggregation
Ang Parallel Seq Scan node nagpatunghag mga laray para sa partial aggregation. Ang "Partial Aggregate" node nagputol niini nga mga linya gamit SUM(). Sa katapusan, ang SUM counter gikan sa matag proseso sa trabahante gikolekta sa "Gather" node.
Ang katapusan nga resulta gikalkulo sa "Finalize Aggregate" node. Kung naa kay kaugalingon nga aggregation function, ayaw kalimti nga markahan kini nga "parallel safe".
Gidaghanon sa mga proseso sa trabahante
Ang gidaghanon sa mga proseso sa mamumuo mahimong madugangan nga dili i-restart ang server:
explain analyze select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------
Finalize Aggregate (cost=1589702.14..1589702.15 rows=1 width=32) (actual time=8553.365..8553.365 rows=1 loops=1)
-> Gather (cost=1589701.91..1589702.12 rows=2 width=32) (actual time=8553.241..8555.067 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Partial Aggregate (cost=1588701.91..1588701.92 rows=1 width=32) (actual time=8547.546..8547.546 rows=1 loops=3)
-> Parallel Seq Scan on lineitem (cost=0.00..1527393.33 rows=24523431 width=5) (actual time=0.038..5998.417 rows=19613238 loops=3)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 382112
Planning Time: 0.241 ms
Execution Time: 8555.131 msUnsa ang nahitabo dinhi? Adunay 2 ka beses nga mas daghang proseso sa trabaho, ug ang hangyo nahimong 1,6599 ka beses nga mas paspas. Ang mga kalkulasyon makapaikag. Kami adunay 2 ka proseso sa trabahante ug 1 ka lider. Pagkahuman sa pagbag-o nahimo kini nga 4 + 1.
Ang among pinakataas nga pagpadali gikan sa parallel nga pagproseso: 5/3 = 1,66(6) ka beses.
Unsang paagi kini sa trabaho?
Ang mga proseso
Ang pagpatuman sa hangyo kanunay magsugod sa nanguna nga proseso. Gibuhat sa lider ang tanan nga dili managsama ug pipila nga parehas nga pagproseso. Ang ubang mga proseso nga naghimo sa parehas nga mga hangyo gitawag nga mga proseso sa trabahante. Ang parallel nga pagproseso naggamit sa imprastraktura (gikan sa bersyon 9.4). Tungod kay ang ubang mga bahin sa PostgreSQL naggamit sa mga proseso kaysa mga hilo, ang usa ka pangutana nga adunay 3 nga mga proseso sa trabahante mahimong 4 ka beses nga mas paspas kaysa tradisyonal nga pagproseso.
Pag-interaksyon
Ang mga proseso sa trabahante nakigsulti sa lider pinaagi sa pila nga mensahe (base sa gipaambit nga memorya). Ang matag proseso adunay 2 ka pila: alang sa mga sayup ug alang sa mga tuple.
Pila ka mga workflow ang gikinahanglan?
Ang minimum nga limitasyon gitino sa parameter . Ang hangyo nga runner dayon mokuha sa mga proseso sa trabahante gikan sa pool nga limitado sa parameter . Ang katapusan nga limitasyon mao ang , nga mao, ang kinatibuk-ang gidaghanon sa mga proseso sa background.
Kung dili mahimo ang paggahin sa usa ka proseso sa mamumuo, ang pagproseso mahimong usa ka proseso.
Ang tigplano sa pangutana makapakunhod sa mga workflow depende sa gidak-on sa lamesa o indeks. Adunay mga parameter alang niini и .
set min_parallel_table_scan_size='8MB'
8MB table => 1 worker
24MB table => 2 workers
72MB table => 3 workers
x => log(x / min_parallel_table_scan_size) / log(3) + 1 workerMatag higayon nga ang lamesa 3 ka beses nga mas dako kaysa min_parallel_(index|table)_scan_size, Ang Postgres midugang ug proseso sa trabahante. Ang gidaghanon sa mga workflow wala gibase sa gasto. Ang circular dependency nagpalisud sa komplikado nga pagpatuman. Hinunoa, ang tigplano naggamit ug yanong mga lagda.
Sa praktis, kini nga mga lagda dili kanunay angay alang sa produksyon, aron imong mausab ang gidaghanon sa mga proseso sa trabahante alang sa usa ka piho nga lamesa: ALTER TABLE ... SET (parallel_workers = N).
Ngano nga wala gigamit ang parallel processing?
Gawas pa sa taas nga lista sa mga pagdili, adunay usab mga pagsusi sa gasto:
- aron malikayan ang managsama nga pagproseso sa mubo nga mga hangyo. Kini nga parameter nagbanabana sa oras sa pag-andam sa memorya, pagsugod sa proseso, ug inisyal nga pagbayloay sa datos.
: Ang komunikasyon tali sa lider ug mga trabahante mahimong malangan sumala sa gidaghanon sa mga tuple gikan sa mga proseso sa trabaho. Kini nga parameter nagkalkula sa gasto sa data exchange.
Nagdugtong nga Loop
PostgreSQL 9.6+ может выполнять вложенные циклы параллельно — это простая операция.
explain (costs off) select c_custkey, count(o_orderkey)
from customer left outer join orders on
c_custkey = o_custkey and o_comment not like '%special%deposits%'
group by c_custkey;
QUERY PLAN
--------------------------------------------------------------------------------------
Finalize GroupAggregate
Group Key: customer.c_custkey
-> Gather Merge
Workers Planned: 4
-> Partial GroupAggregate
Group Key: customer.c_custkey
-> Nested Loop Left Join
-> Parallel Index Only Scan using customer_pkey on customer
-> Index Scan using idx_orders_custkey on orders
Index Cond: (customer.c_custkey = o_custkey)
Filter: ((o_comment)::text !~~ '%special%deposits%'::text)Ang pagkolekta mahitabo sa katapusang yugto, mao nga ang Nested Loop Left Join usa ka parallel nga operasyon. Ang Parallel Index Only Scan gipaila-ila lamang sa bersyon 10. Naglihok kini susama sa parallel serial scanning. kahimtang c_custkey = o_custkey nagbasa og usa ka order matag string sa kliyente. Busa dili kini parallel.
Hash Apil
Ang matag proseso sa trabahante nagmugna sa kaugalingon nga hash table hangtod sa PostgreSQL 11. Ug kung adunay labaw pa sa upat niini nga mga proseso, ang pasundayag dili molambo. Sa bag-ong bersyon, ang hash table gipaambit. Ang matag proseso sa trabahante makagamit sa WORK_MEM aron makahimo og hash table.
select
l_shipmode,
sum(case
when o_orderpriority = '1-URGENT'
or o_orderpriority = '2-HIGH'
then 1
else 0
end) as high_line_count,
sum(case
when o_orderpriority <> '1-URGENT'
and o_orderpriority <> '2-HIGH'
then 1
else 0
end) as low_line_count
from
orders,
lineitem
where
o_orderkey = l_orderkey
and l_shipmode in ('MAIL', 'AIR')
and l_commitdate < l_receiptdate
and l_shipdate < l_commitdate
and l_receiptdate >= date '1996-01-01'
and l_receiptdate < date '1996-01-01' + interval '1' year
group by
l_shipmode
order by
l_shipmode
LIMIT 1;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=1964755.66..1964961.44 rows=1 width=27) (actual time=7579.592..7922.997 rows=1 loops=1)
-> Finalize GroupAggregate (cost=1964755.66..1966196.11 rows=7 width=27) (actual time=7579.590..7579.591 rows=1 loops=1)
Group Key: lineitem.l_shipmode
-> Gather Merge (cost=1964755.66..1966195.83 rows=28 width=27) (actual time=7559.593..7922.319 rows=6 loops=1)
Workers Planned: 4
Workers Launched: 4
-> Partial GroupAggregate (cost=1963755.61..1965192.44 rows=7 width=27) (actual time=7548.103..7564.592 rows=2 loops=5)
Group Key: lineitem.l_shipmode
-> Sort (cost=1963755.61..1963935.20 rows=71838 width=27) (actual time=7530.280..7539.688 rows=62519 loops=5)
Sort Key: lineitem.l_shipmode
Sort Method: external merge Disk: 2304kB
Worker 0: Sort Method: external merge Disk: 2064kB
Worker 1: Sort Method: external merge Disk: 2384kB
Worker 2: Sort Method: external merge Disk: 2264kB
Worker 3: Sort Method: external merge Disk: 2336kB
-> Parallel Hash Join (cost=382571.01..1957960.99 rows=71838 width=27) (actual time=7036.917..7499.692 rows=62519 loops=5)
Hash Cond: (lineitem.l_orderkey = orders.o_orderkey)
-> Parallel Seq Scan on lineitem (cost=0.00..1552386.40 rows=71838 width=19) (actual time=0.583..4901.063 rows=62519 loops=5)
Filter: ((l_shipmode = ANY ('{MAIL,AIR}'::bpchar[])) AND (l_commitdate < l_receiptdate) AND (l_shipdate < l_commitdate) AND (l_receiptdate >= '1996-01-01'::date) AND (l_receiptdate < '1997-01-01 00:00:00'::timestamp without time zone))
Rows Removed by Filter: 11934691
-> Parallel Hash (cost=313722.45..313722.45 rows=3750045 width=20) (actual time=2011.518..2011.518 rows=3000000 loops=5)
Buckets: 65536 Batches: 256 Memory Usage: 3840kB
-> Parallel Seq Scan on orders (cost=0.00..313722.45 rows=3750045 width=20) (actual time=0.029..995.948 rows=3000000 loops=5)
Planning Time: 0.977 ms
Execution Time: 7923.770 msAng pangutana 12 gikan sa TPC-H tin-aw nga nagpakita sa usa ka parallel hash connection. Ang matag proseso sa trabahante nakatampo sa paghimo sa usa ka komon nga hash table.
Paghiusa Apil
Ang usa ka merge join kay dili parallel sa kinaiyahan. Ayaw kabalaka kung kini ang katapusang lakang sa pangutana - mahimo gihapon kini nga magkaparehas.
-- Query 2 from TPC-H
explain (costs off) select s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment
from part, supplier, partsupp, nation, region
where
p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and p_size = 36
and p_type like '%BRASS'
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'AMERICA'
and ps_supplycost = (
select
min(ps_supplycost)
from partsupp, supplier, nation, region
where
p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'AMERICA'
)
order by s_acctbal desc, n_name, s_name, p_partkey
LIMIT 100;
QUERY PLAN
----------------------------------------------------------------------------------------------------------
Limit
-> Sort
Sort Key: supplier.s_acctbal DESC, nation.n_name, supplier.s_name, part.p_partkey
-> Merge Join
Merge Cond: (part.p_partkey = partsupp.ps_partkey)
Join Filter: (partsupp.ps_supplycost = (SubPlan 1))
-> Gather Merge
Workers Planned: 4
-> Parallel Index Scan using <strong>part_pkey</strong> on part
Filter: (((p_type)::text ~~ '%BRASS'::text) AND (p_size = 36))
-> Materialize
-> Sort
Sort Key: partsupp.ps_partkey
-> Nested Loop
-> Nested Loop
Join Filter: (nation.n_regionkey = region.r_regionkey)
-> Seq Scan on region
Filter: (r_name = 'AMERICA'::bpchar)
-> Hash Join
Hash Cond: (supplier.s_nationkey = nation.n_nationkey)
-> Seq Scan on supplier
-> Hash
-> Seq Scan on nation
-> Index Scan using idx_partsupp_suppkey on partsupp
Index Cond: (ps_suppkey = supplier.s_suppkey)
SubPlan 1
-> Aggregate
-> Nested Loop
Join Filter: (nation_1.n_regionkey = region_1.r_regionkey)
-> Seq Scan on region region_1
Filter: (r_name = 'AMERICA'::bpchar)
-> Nested Loop
-> Nested Loop
-> Index Scan using idx_partsupp_partkey on partsupp partsupp_1
Index Cond: (part.p_partkey = ps_partkey)
-> Index Scan using supplier_pkey on supplier supplier_1
Index Cond: (s_suppkey = partsupp_1.ps_suppkey)
-> Index Scan using nation_pkey on nation nation_1
Index Cond: (n_nationkey = supplier_1.s_nationkey)Ang "Merge Join" node nahimutang sa ibabaw sa "Gather Merge". Busa ang paghiusa wala maggamit ug parallel processing. Apan ang "Parallel Index Scan" node makatabang gihapon sa bahin part_pkey.
Koneksyon pinaagi sa mga seksyon
Sa PostgreSQL 11 disabled pinaagi sa default: kini adunay mahal kaayo nga pag-iskedyul. Ang mga lamesa nga adunay parehas nga partisyon mahimong idugtong sa partisyon pinaagi sa partisyon. Niining paagiha magamit sa mga Postgres ang gagmay nga mga lamesa sa hash. Ang matag koneksyon sa mga seksyon mahimong parallel.
tpch=# set enable_partitionwise_join=t;
tpch=# explain (costs off) select * from prt1 t1, prt2 t2
where t1.a = t2.b and t1.b = 0 and t2.b between 0 and 10000;
QUERY PLAN
---------------------------------------------------
Append
-> Hash Join
Hash Cond: (t2.b = t1.a)
-> Seq Scan on prt2_p1 t2
Filter: ((b >= 0) AND (b <= 10000))
-> Hash
-> Seq Scan on prt1_p1 t1
Filter: (b = 0)
-> Hash Join
Hash Cond: (t2_1.b = t1_1.a)
-> Seq Scan on prt2_p2 t2_1
Filter: ((b >= 0) AND (b <= 10000))
-> Hash
-> Seq Scan on prt1_p2 t1_1
Filter: (b = 0)
tpch=# set parallel_setup_cost = 1;
tpch=# set parallel_tuple_cost = 0.01;
tpch=# explain (costs off) select * from prt1 t1, prt2 t2
where t1.a = t2.b and t1.b = 0 and t2.b between 0 and 10000;
QUERY PLAN
-----------------------------------------------------------
Gather
Workers Planned: 4
-> Parallel Append
-> Parallel Hash Join
Hash Cond: (t2_1.b = t1_1.a)
-> Parallel Seq Scan on prt2_p2 t2_1
Filter: ((b >= 0) AND (b <= 10000))
-> Parallel Hash
-> Parallel Seq Scan on prt1_p2 t1_1
Filter: (b = 0)
-> Parallel Hash Join
Hash Cond: (t2.b = t1.a)
-> Parallel Seq Scan on prt2_p1 t2
Filter: ((b >= 0) AND (b <= 10000))
-> Parallel Hash
-> Parallel Seq Scan on prt1_p1 t1
Filter: (b = 0)Ang nag-unang butang mao nga ang koneksyon sa mga seksyon managsama lamang kung kini nga mga seksyon igo nga kadako.
Parallel Append
mahimong gamiton imbes sa lain-laing mga bloke sa lain-laing mga workflows. Kasagaran kini mahitabo sa mga pangutana sa UNION ALL. Ang disbentaha mao ang dili kaayo paralelismo, tungod kay ang matag proseso sa trabahante nagproseso lamang sa 1 nga hangyo.
Adunay 2 nga mga proseso sa trabahante nga nagdagan dinhi, bisan kung ang 4 gipalihok.
tpch=# explain (costs off) select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day union all select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '2000-12-01' - interval '105' day;
QUERY PLAN
------------------------------------------------------------------------------------------------
Gather
Workers Planned: 2
-> Parallel Append
-> Aggregate
-> Seq Scan on lineitem
Filter: (l_shipdate <= '2000-08-18 00:00:00'::timestamp without time zone)
-> Aggregate
-> Seq Scan on lineitem lineitem_1
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)Ang labing hinungdanon nga mga variable
- Ang WORK_MEM naglimite sa memorya kada proseso, dili lang mga pangutana: work_mem mga proseso koneksyon = daghang memorya.
- — pila ka mamumuo ang nagproseso nga gamiton sa nagpatuman nga programa alang sa parehas nga pagproseso gikan sa plano.
- — nag-adjust sa kinatibuk-ang gidaghanon sa mga proseso sa trabahante ngadto sa gidaghanon sa mga CPU core sa server.
- - parehas, apan alang sa managsama nga mga proseso sa trabaho.
Mga resulta
Sa bersyon 9.6, ang parallel nga pagproseso makapauswag pag-ayo sa paghimo sa komplikadong mga pangutana nga nag-scan sa daghang mga laray o mga indeks. Sa PostgreSQL 10, ang parallel nga pagproseso gipalihok pinaagi sa default. Hinumdumi nga i-disable kini sa mga server nga adunay daghang OLTP workload. Ang sunud-sunod nga mga pag-scan o mga pag-scan sa indeks nagkonsumo sa daghang mga kapanguhaan. Kung wala ka nagpadagan og report sa tibuok dataset, mahimo nimong pauswagon ang performance sa pangutana pinaagi lang sa pagdugang sa nawala nga mga indeks o paggamit sa hustong partitioning.
mga pakisayran
Source: www.habr.com