CPU-yên nûjen xwedî gelek core ne. Bi salan e, serîlêdan bi paralel pirsan ji databasan re dişînin. Ger ew pirsnameyek raporê ye li ser gelek rêzên tabloyek, dema ku pir CPU bikar tîne zûtir dimeşe, û PostgreSQL ji guhertoya 9.6-ê vir ve karîbû vê yekê bike.
Ji bo bicihanîna taybetmendiya lêpirsîna paralel 3 sal girt - neçar ma ku em kodê di qonaxên cihêreng ên pêkanîna pirsê de ji nû ve binivîsînin. PostgreSQL 9.6 binesaziyê destnîşan kir ku kodê bêtir çêtir bike. Di guhertoyên paşîn de, cûreyên din ên lêpirsînan bi paralel têne darve kirin.
Sînor
- Ger hemî navok jixwe mijûl in, darvekirina paralel çalak nekin, wekî din dê daxwazên din hêdî bibin.
- Ya herî girîng, pêvajoyek paralel bi nirxên WORK_MEM-ê yên bilind re gelek bîranîn bikar tîne - her hevgirtin an cûrbecûr bîranîna work_mem digire.
- Pirsên OLTP yên derengiya kêm bi darvekirina paralel nayên bilez kirin. Û heke pirs yek rêzek vegerîne, pêvajoyek paralel tenê wê hêdî bike.
- Pêşdebir hez dikin ku pîvana TPC-H bikar bînin. Dibe ku ji bo darvekirina paralel a bêkêmasî pirsên we yên bi vî rengî hebin.
- Tenê pirsên SELECT bêyî girtina pêşdaraz bi paralel têne darve kirin.
- Carinan indekskirina rast ji şopandina tabloya rêzdar a di moda paralel de çêtir e.
- Rawestandina pirs û cursoran nayê piştgirî kirin.
- Fonksiyonên pencereyê û fonksiyonên berhevokê yên rêzkirî ne paralel in.
- Hûn di bargiraniya xebata I/O de tiştek bi dest naxin.
- Algorîtmayên cudakirina paralel tune. Lê pirsên bi cûrbecûr dikarin di hin aliyan de paralel bêne darve kirin.
- CTE (BI ...) bi SELECT hêlînê veguherînin da ku pêvajoyek paralel çalak bike.
- Parçeyên daneya partiya sêyemîn hîna pêvajoyek paralel piştgirî nakin (lê ew dikarin!)
- TEVLÊBÛNA DERVE TIJ nayê piştgirî kirin.
- max_rows pêvajoyek paralel asteng dike.
- Ger pirsek fonksiyonek ku PARALLEL SAFE nayê nîşankirin hebe, ew ê yek xêzkirî be.
- Asta veqetandina danûstendinê ya SERÎALIZABLE pêvajoyek paralel asteng dike.
Environment Test
Pêşdebirên PostgreSQL hewl dan ku dema bersivê ya pirsên pîvana TPC-H kêm bikin. Daxistina pîvanê û . Ev karanîna nefermî ya pîvana TPC-H e - ne ji bo berhevdana databasê an hardware.
- TPC-H_Tools_v2.17.3.zip dakêşin (an jî guhertoya nûtir) .
- Navê makefile.suite biguherîne Makefile û wekî ku li vir hatî diyar kirin biguhezîne: . Bi fermana make kodê berhev bikin.
- Daneyên hilberandin:
./dbgen -s 10databasek 23 GB diafirîne. Ji bo dîtina ferqa di performansa pirsên paralel û ne-paralel de ev bes e. - Pelan veguherînin
tblвcsv с forиsed. - Depoyê klon bikin
pg_tpchû pelan kopî bikincsvвpg_tpch/dss/data. - Bi fermanekê pirsan biafirînin
qgen. - Bi fermanê daneyan li databasê bar bikin
./tpch.sh.
Paqijkirina rêzdar a paralel
Dibe ku ew ne ji ber xwendina paralel zûtir be, lê ji ber ku dane li gelek navên CPU-yê belav dibin. Di pergalên xebitandinê yên nûjen de, pelên daneya PostgreSQL baş têne tomar kirin. Bi xwendin-pêş-derketinê re, gengaz e ku meriv ji daxwazên PG daemon blokek mezintir ji hilanînê bistîne. Ji ber vê yekê, performansa pirsê ji hêla I/O-ya dîskê ve ne sînorkirî ye. Ew çerxên CPU-ê dixwe ku:
- rêzan yek bi yek ji rûpelên tabloyê bixwînin;
- nirx û şertên rêzikê bidin ber hev
WHERE.
Ka em pirsek hêsan bimeşînin 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 msPaqijkirina rêzdar pir pir rêzan bêyî hevgirtinê çêdike, ji ber vê yekê pirs ji hêla yek bingehek CPU ve tê darve kirin.
Heke hûn lê zêde bikin SUM(), hûn dikarin bibînin ku du karûbar dê alîkariya bilezkirina pirsê bikin:
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 msKombûna paralel
Nodeya Parallel Seq Scan rêzikan ji bo berhevkirina qismî çêdike. Nodeya "Partial Aggregate" van rêzan bi kar tîne SUM(). Di dawiyê de, jimareya SUM ji her pêvajoya karker ji hêla girêka "Gather" ve tê berhev kirin.
Encama dawîn ji hêla girêka "Berhevkirina dawîn" ve tê hesibandin. Ger we fonksiyonên berhevkirina we hene, ji bîr nekin ku wan wekî "ewle paralel" nîşan bikin.
Hejmara pêvajoyên karker
Hejmara pêvajoyên karker dikare bêyî destpêkirina serverê zêde bibe:
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 msLi vir çi diqewime? Pêvajoyên xebatê 2 carî zêde bûn, û daxwaz tenê 1,6599 carî zûtir bû. Hesabên balkêş in. 2 pêvajoyên karker û 1 rêberê me hebûn. Piştî guhertinê bû 4+1.
Leza meya herî zêde ya ji pêvajoya paralel: 5/3 = 1,66 (6) car.
Çawa dixebite?
Pêvajoyên
Pêkanîna daxwazê her gav bi pêvajoya pêşeng dest pê dike. Rêber her tiştî ne-paralel û hin pêvajoyek paralel dike. Pêvajoyên din ên ku heman daxwazan pêk tînin wekî pêvajoyên karker têne gotin. Pêvajoya paralel binesaziyê bikar tîne (ji guhertoya 9.4). Ji ber ku beşên din ên PostgreSQL li şûna mijaran pêvajoyan bikar tînin, pirsek bi 3 pêvajoyên karker dikare 4 carî ji pêvajoya kevneşopî zûtir be.
Têkilî
Pêvajoyên karker bi rêber re bi rêzek peyamê (li ser bingeha bîranîna hevpar) re têkilî daynin. Her pêvajoyek 2 rêz hene: ji bo xeletiyan û ji bo pirtikan.
Çend xebatên xebatê hewce ne?
Sînorê herî kêm ji hêla pîvanê ve tête diyar kirin . Dûv re bazdana daxwaznameyê pêvajoyên karkeran ji hewza ku ji hêla parametreyê ve hatî sînordar kirin digire . Sînorê dawîn e , ew e ku, hejmara tevahiya pêvajoyên paşnavê.
Ger ne gengaz bû ku pêvajoyek karker were veqetandin, pêvajo dê yek-pêvajoyek be.
Plansazkerê pirsê dikare li gorî mezinahiya tabloyê an pêvekê rêyên xebatê kêm bike. Parametreyên vê yekê hene и .
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 workerHer carê sifrê 3 qat jê mezintir e min_parallel_(index|table)_scan_size, Postgres pêvajoyek karker zêde dike. Hejmara karûbaran ne li gorî lêçûn e. Girêdana dorhêlî pêkanînên tevlihev dijwar dike. Di şûna wê de, plansaz qaîdeyên hêsan bikar tîne.
Di pratîkê de, ev rêgez her gav ji bo hilberînê ne maqûl in, ji ber vê yekê hûn dikarin ji bo tabloyek taybetî hejmara pêvajoyên karker biguhezînin: TASÊ ALTER ... SET (parallel_workers = N).
Çima pêvajoyek paralel nayê bikar anîn?
Ji bilî navnîşa dirêj a qedexeyan, di heman demê de kontrolên lêçûnê jî hene:
- ji bo nehiştina pêvajoyek paralel a daxwazên kurt. Ev parametre dema amadekirina bîranînê, destpêkirina pêvajoyê û pevguhertina daneya destpêkê texmîn dike.
: Têkiliya di navbera rêber û karkeran de dikare li gorî hêjmara tûpên ji pêvajoyên xebatê dereng were paşve xistin. Ev parametre mesrefa danûstandina daneyan hesab dike.
Nested Loop Joins
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)Komkirin di qonaxa paşîn de pêk tê, ji ber vê yekê Nested Loop Left Join operasyonek paralel e. Indeksa Parallel Tenê Scan tenê di guhertoya 10-ê de hate destnîşan kirin. Ew mîna şopandina rêzikên paralel dixebite. Rewş c_custkey = o_custkey her rêzika xerîdar yek fermanê dixwîne. Ji ber vê yekê ew ne paralel e.
Hash Join
Her pêvajoyek xebatkar tabloya xweya hash-ê heya PostgreSQL 11 diafirîne. Û heke ji van pêvajoyan ji çaran zêdetir hebin, performans dê baştir nebe. Di guhertoya nû de, tabloya hash tê parve kirin. Her pêvajoyek xebatkar dikare WORK_MEM bikar bîne da ku tabloyek haş biafirîne.
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 msPirsa 12 ji TPC-H bi zelalî pêwendiyek hash paralel nîşan dide. Pêvajoya her karker beşdarî afirandina tabloyek hash a hevpar dibe.
Merge Tevlî
Tevhevbûnek di xwezayê de ne paralel e. Xem neke ger ev gava paşîn a pirsê ye - ew hîn jî dikare paralel bimeşe.
-- 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)Girêka "Merge Join" li jorê "Gather Merge" ye. Ji ber vê yekê yekbûn pêvajoyek paralel bikar nayîne. Lê girêka "Parallel Index Scan" hîn jî bi beşê re dibe alîkar part_pkey.
Girêdana bi beşan
Di PostgreSQL 11 de ji hêla xwerû ve neçalak e: plansaziya wê ya pir biha heye. Tabloyên bi parvekirinên bi heman rengî dikarin dabeş bi dabeş bibin yek. Bi vî rengî Postgres dê tabloyên piçûktir ên hash bikar bîne. Her girêdana beşan dikare paralel be.
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)Ya sereke ev e ku girêdana di beşan de tenê heke ev beş têra xwe mezin bin paralel e.
Pêvek Parallel
dikare li şûna blokên cihêreng di nav tevgerên cûda de were bikar anîn. Ev bi gelemperî bi UNION ALL pirsan re dibe. Kêmasî kêm paralelî ye, ji ber ku her pêvajoyek karker tenê 1 daxwazê dike.
2 pêvajoyên karker li vir dimeşînin, her çend 4 çalak in.
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)Guherbarên herî girîng
- WORK_MEM li her pêvajoyê bîranînê sînordar dike, ne tenê pirsan: work_mem pêvajoyên girêdan = gelek bîr.
- - çend pêvajoyên xebatkar dê bernameya pêkanînê ji bo pêvajoyek paralel ji planê bikar bîne.
- - Jimara giştî ya pêvajoyên xebatkar li gorî hejmarên CPU yên li ser serverê eyar dike.
- - heman, lê ji bo pêvajoyên xebata paralel.
Encam
Li gorî guhertoya 9.6-ê, pêvajoyek paralel dikare performansa pirsên tevlihev ên ku gelek rêz an navnîşan dişoxilîne pir çêtir bike. Di PostgreSQL 10 de, pêvajoyek paralel ji hêla xwerû ve hatî çalak kirin. Ji bîr mekin ku wê li ser serverên bi karekî mezin OLTP neçalak bikin. Skenandinên rêzdar an şaneyên îndeksê gelek çavkaniyan dixwe. Ger hûn raporek li ser tevaya databasê dişoxilînin, hûn dikarin performansa pirsê bi tenê lê zêdekirina indexên winda an bi karanîna dabeşkirina rast çêtir bikin.
references
Source: www.habr.com