Nútíma örgjörvar hafa marga kjarna. Um árabil hafa forrit sent samhliða fyrirspurnir í gagnagrunna. Ef það er skýrslufyrirspurn á mörgum línum í töflu, þá keyrir hún hraðar þegar margir örgjörvar eru notaðir og PostgreSQL hefur getað gert þetta frá útgáfu 9.6.
Það tók 3 ár að innleiða samhliða fyrirspurnareiginleikann - við þurftum að endurskrifa kóðann á mismunandi stigum framkvæmdar fyrirspurnar. PostgreSQL 9.6 kynnti innviði til að bæta kóðann enn frekar. Í síðari útgáfum eru aðrar tegundir fyrirspurna keyrðar samhliða.
Takmarkanir
- Ekki virkja samhliða framkvæmd ef allir kjarna eru þegar uppteknir, annars hægja á öðrum beiðnum.
- Mikilvægast er að samhliða vinnsla með háum WORK_MEM gildum notar mikið minni - hver hash sameining eða flokkun tekur upp work_mem minni.
- Ekki er hægt að flýta fyrir OLTP fyrirspurnum með lítilli leynd með samhliða framkvæmd. Og ef fyrirspurnin skilar einni röð mun samhliða vinnsla aðeins hægja á henni.
- Hönnuðir elska að nota TPC-H viðmiðið. Kannski hefurðu svipaðar fyrirspurnir um fullkomna samhliða framkvæmd.
- Aðeins SELECT fyrirspurnir án forsagnalæsingar eru keyrðar samhliða.
- Stundum er rétt flokkun betri en röð töfluskönnun í samhliða ham.
- Ekki er stutt við að gera hlé á fyrirspurnum og bendilum.
- Gluggaaðgerðir og samanlagðar föll í röðuðu setti eru ekki samsíða.
- Þú færð ekki neitt í I/O vinnuálaginu.
- Það eru engin samhliða flokkunaralgrím. En fyrirspurnir með flokkum er hægt að framkvæma samhliða í sumum þáttum.
- Skiptu út CTE (MEÐ ...) með hreiðri SELECT til að virkja samhliða vinnslu.
- Gagnaumbúðir frá þriðja aðila styðja ekki enn samhliða vinnslu (en þeir gætu!)
- FULL OUTER JOIN er ekki studd.
- max_rows slekkur á samhliða vinnslu.
- Ef fyrirspurn er með aðgerð sem er ekki merkt PARALLEL SAFE verður hún einþráður.
- Einangrunarstig SERIALIZABLE færslunnar slekkur á samhliða vinnslu.
Próf umhverfi
PostgreSQL forritarar reyndu að draga úr viðbragðstíma TPC-H viðmiðunarfyrirspurna. Sækja viðmiðið og . Þetta er óopinber notkun á TPC-H viðmiðinu - ekki til samanburðar á gagnagrunni eða vélbúnaði.
- Sæktu TPC-H_Tools_v2.17.3.zip (eða nýrri útgáfa) .
- Endurnefna makefile.suite í Makefile og breyttu eins og lýst er hér: . Settu kóðann saman með make skipuninni.
- Búa til gögn:
./dbgen -s 10býr til 23 GB gagnagrunn. Þetta er nóg til að sjá muninn á frammistöðu samhliða og ósamhliða fyrirspurna. - Umbreyta skrám
tblвcsv с forиsed. - Klóna geymsluna
pg_tpchog afritaðu skrárnarcsvвpg_tpch/dss/data. - Búðu til fyrirspurnir með skipun
qgen. - Hladdu gögnum inn í gagnagrunninn með skipuninni
./tpch.sh.
Samhliða raðskönnun
Það gæti verið hraðari ekki vegna samhliða lestrar, heldur vegna þess að gögnin dreifast yfir marga CPU kjarna. Í nútíma stýrikerfum eru PostgreSQL gagnaskrár vel í skyndiminni. Með lestur á undan er hægt að fá stærri blokk úr geymslu en PG púkinn biður um. Þess vegna takmarkast afköst fyrirspurna ekki af I/O disks. Það eyðir CPU lotum til að:
- lesa línur eina í einu af töflusíðum;
- bera saman strengjagildi og skilyrði
WHERE.
Við skulum keyra einfalda fyrirspurn 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 msRöðskönnunin framleiðir of margar raðir án samsöfnunar, þannig að fyrirspurnin er framkvæmd af einum CPU kjarna.
Ef þú bætir við SUM(), þú getur séð að tvö verkflæði munu hjálpa til við að flýta fyrirspurninni:
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 msSamhliða samsöfnun
Parallel Seq Scan hnúturinn framleiðir línur fyrir samsöfnun að hluta. „Hlutasamanlagður“ hnúturinn klippir þessar línur með því að nota SUM(). Í lokin er SUM-teljarinn úr hverju starfsferli safnað með „Safna“ hnútnum.
Lokaniðurstaðan er reiknuð út af „Finalize Aggregate“ hnútnum. Ef þú ert með þínar eigin söfnunaraðgerðir skaltu ekki gleyma að merkja þær sem „samhliða öruggar“.
Fjöldi starfsmannaferla
Hægt er að fjölga starfsferlum án þess að endurræsa þjóninn:
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 msHvað er í gangi hér? Það voru 2 sinnum fleiri vinnuferli og beiðnin varð aðeins 1,6599 sinnum hraðari. Útreikningarnir eru áhugaverðir. Við vorum með 2 starfsferla og 1 leiðtoga. Eftir breytinguna varð það 4+1.
Hámarkshraði okkar frá samhliða vinnslu: 5/3 = 1,66(6) sinnum.
Hvernig virkar það?
Ferlarnir
Framkvæmd beiðni byrjar alltaf með leiðandi ferli. Leiðtoginn gerir allt ósamhliða og einhverja samhliða vinnslu. Önnur ferli sem framkvæma sömu beiðnir eru kölluð vinnuferli. Samhliða vinnsla notar innviði (frá útgáfu 9.4). Þar sem aðrir hlutar PostgreSQL nota ferla frekar en þræði, gæti fyrirspurn með 3 vinnuferlum verið 4 sinnum hraðari en hefðbundin vinnsla.
Samskipti
Starfsmannaferlar hafa samskipti við leiðtogann í gegnum skilaboðaröð (byggt á sameiginlegu minni). Hvert ferli hefur 2 biðraðir: fyrir villur og fyrir tuples.
Hversu mörg verkflæði þarf?
Lágmarksmörkin eru tilgreind með færibreytunni . Beiðnahlauparinn tekur síðan vinnuferla úr lauginni sem takmarkast af færibreytunni . Síðasta takmörkunin er , það er heildarfjöldi bakgrunnsferla.
Ef ekki var hægt að úthluta vinnuferli verður vinnslan í einu ferli.
Fyrirspurnaskipuleggjandinn getur dregið úr verkflæði eftir stærð töflunnar eða vísitölunnar. Það eru breytur fyrir þetta и .
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 workerÍ hvert skipti sem borðið er 3 sinnum stærra en min_parallel_(index|table)_scan_size, Postgres bætir við vinnuferli. Fjöldi verkflæðis er ekki byggður á kostnaði. Hringlaga ósjálfstæði gerir flóknar útfærslur erfiðar. Í staðinn notar skipuleggjandinn einfaldar reglur.
Í reynd henta þessar reglur ekki alltaf fyrir framleiðslu, svo þú getur breytt fjölda starfsmannaferla fyrir tiltekna töflu: ALTER TABLE ... SET (parallel_workers = N).
Hvers vegna er samhliða vinnsla ekki notuð?
Til viðbótar við langan lista yfir takmarkanir eru einnig kostnaðarathuganir:
- til að forðast samhliða afgreiðslu á stuttum beiðnum. Þessi færibreyta metur tímann til að undirbúa minni, hefja ferlið og fyrstu gagnaskipti.
: Samskipti milli leiðtoga og starfsmanna geta tafist í hlutfalli við fjölda túlla úr verkferlum. Þessi færibreyta reiknar út kostnað við gagnaskipti.
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)Söfnunin á sér stað á síðasta stigi, þannig að Nested Loop Left Join er samhliða aðgerð. Parallel Index Only Scan var aðeins kynnt í útgáfu 10. Það virkar svipað og samhliða raðskönnun. Ástand c_custkey = o_custkey les eina pöntun á hvern viðskiptavinastreng. Svo það er ekki samsíða.
Hash Join
Hvert starfsmannsferli býr til sína eigin kjötkássatöflu þar til PostgreSQL 11. Og ef það eru fleiri en fjögur af þessum ferlum mun árangur ekki batna. Í nýju útgáfunni er kjötkássatöflunni deilt. Hvert starfsferli getur notað WORK_MEM til að búa til kjötkássatöflu.
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 msFyrirspurn 12 frá TPC-H sýnir greinilega samhliða kjötkássatengingu. Hvert starfsferli stuðlar að því að búa til sameiginlega kjötkássatöflu.
Sameina Join
Samruni er ekki samhliða í eðli sínu. Ekki hafa áhyggjur ef þetta er síðasta skrefið í fyrirspurninni - hún getur samt keyrt samhliða.
-- 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)„Sameina sameining“ hnúturinn er staðsettur fyrir ofan „Gather Merge“. Þannig að sameining notar ekki samhliða vinnslu. En „Parallel Index Scan“ hnúturinn hjálpar samt við hlutann part_pkey.
Tenging eftir köflum
Í PostgreSQL 11 sjálfgefið óvirkt: það hefur mjög dýra tímasetningu. Töflur með svipaða skiptingu er hægt að sameina skipting fyrir skipting. Þannig mun Postgres nota smærri kjötkássatöflur. Hver tenging hluta getur verið samsíða.
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)Aðalatriðið er að tengingin á köflum er aðeins samhliða ef þessir hlutar eru nógu stórir.
Samhliða viðb
hægt að nota í stað mismunandi blokka í mismunandi verkflæði. Þetta gerist venjulega með UNION ALL fyrirspurnum. Ókosturinn er minni samsíða, því hvert ferli vinnur aðeins úr 1 beiðni.
Hér eru 2 vinnuferli í gangi, þó 4 séu virkjuð.
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)Mikilvægustu breyturnar
- WORK_MEM takmarkar minni fyrir hvert ferli, ekki bara fyrirspurnir: work_mem ferlar tengingar = mikið minni.
- — hversu mörg starfsmannsferli framkvæmdaforritið mun nota fyrir samhliða vinnslu úr áætluninni.
- — stillir heildarfjölda starfsmannaferla að fjölda CPU-kjarna á þjóninum.
- - það sama, en fyrir samhliða verkferla.
Niðurstöður
Frá og með útgáfu 9.6 getur samhliða vinnsla bætt verulega árangur flókinna fyrirspurna sem skanna margar línur eða vísitölur. Í PostgreSQL 10 er samhliða vinnsla sjálfkrafa virkjuð. Mundu að slökkva á því á netþjónum með mikið OLTP vinnuálag. Raðskannanir eða vísitöluskannanir eyða miklu fjármagni. Ef þú ert ekki að keyra skýrslu um allt gagnasafnið geturðu bætt afköst fyrirspurna með því einfaldlega að bæta við vísitölum sem vantar eða nota rétta skiptingu.
tilvísanir
Heimild: www.habr.com