Ny CPU maoderina dia manana cores maro. Nandritra ny taona maro, ny fampiharana dia nandefa fanontaniana amin'ny angon-drakitra mifanitsy. Raha fitakiana tatitra momba ny andalana maromaro ao anaty latabatra izany, dia mihazakazaka haingana kokoa izy rehefa mampiasa CPU maro, ary ny PostgreSQL dia afaka nanao izany hatramin'ny dikan-teny 9.6.
Naharitra 3 taona ny fampiharana ny endri-panontaniana mifanitsy - tsy maintsy naverina nanoratra ny kaody tamin'ny dingana samihafa amin'ny fanatanterahana ny fangatahana izahay. PostgreSQL 9.6 dia nampiditra fotodrafitrasa hanatsarana bebe kokoa ny kaody. Amin'ny dikan-teny manaraka, ny karazana fanontaniana hafa dia tanterahina mifanandrify.
fameperana
- Aza asiana execution parallèle raha efa sahirana ny cores rehetra, raha tsy izany dia hihena ny fangatahana hafa.
- Ny tena zava-dehibe, ny fanodinana mifanandrify amin'ny soatoavina WORK_MEM avo lenta dia mampiasa fitadidiana be dia be - ny fikambanan'ny tenifototra na ny karazana dia maka fahatsiarovana work_mem.
- Tsy azo atao haingana amin'ny fanatanterahana parallèle ny fangataham-panazavana OLTP ambany. Ary raha mamerina andalana iray ny fanontaniana dia hampiadana azy fotsiny ny fanodinana parallèle.
- Ny mpamorona dia tia mampiasa ny mari-pamantarana TPC-H. Angamba manana fanontaniana mitovy amin'izany ianao momba ny fanatanterahana parallèle tonga lafatra.
- Fanontaniana SELECT tsy misy fanidiana predicate ihany no atao mifanandrify.
- Indraindray dia tsara kokoa ny fanondroana araka ny tokony ho izy noho ny fisavana latabatra misesy amin'ny fomba mifanitsy.
- Ny fiatoana fanontaniana sy ny cursors dia tsy tohanana.
- Ny fiasan'ny fikandrana sy ny asa aggregate voalamina dia tsy mifanitsy.
- Tsy mahazo na inona na inona ianao amin'ny enta-mavesatra I/O.
- Tsy misy algorithm fandrindrana parallèle. Saingy ny fanontaniana misy karazana dia azo tanterahina mifanandrify amin'ny lafiny sasany.
- Soloy CTE (WITH ...) miaraka amin'ny SELECT nested mba ahafahan'ny fanodinana parallèle.
- Tsy mbola manohana ny fanodinana parallèle ny famonosana angona avy amin'ny antoko fahatelo (saingy afaka!)
- FULL OUTER JOIN dia tsy tohanana.
- max_rows dia manakana ny fanodinana parallèle.
- Raha toa ka manana fiasa tsy voamarika PARALLEL SAFE ny fanontaniana iray dia kofehy tokana izy io.
- Ny haavon'ny fitokana-monina SERIALIZABLE dia manakana ny fanodinana parallèle.
Test Environment
Ny mpamorona PostgreSQL dia nanandrana nampihena ny fotoana famalian'ny fanontaniana benchmark TPC-H. Download ny benchmark ary . Fampiasana tsy ofisialy amin'ny mari-pamantarana TPC-H izany - tsy natao fampitahana angon-drakitra na fitaovana.
- Ampidino ny TPC-H_Tools_v2.17.3.zip (na dikan-teny vaovao) .
- Avereno anarana makefile.suite ho Makefile ary ovay araka ny voalaza eto: . Angony ny kaody miaraka amin'ny baiko make.
- Mamorona angona:
./dbgen -s 10mamorona tahiry 23 GB. Ampy hijerena ny fahasamihafan'ny fanatontosana fanontaniana mifanitsy sy tsy mifanitsy. - Hanova rakitra
tblвcsv с forиsed. - Clone ny tahiry
pg_tpchary kopia ny rakitracsvвpg_tpch/dss/data. - Mamorona fanontaniana miaraka amin'ny baiko
qgen. - Ampidiro ao anaty angon-drakitra miaraka amin'ny baiko
./tpch.sh.
Fikarohana misesy parallèle
Mety ho haingana kokoa izany fa tsy noho ny famakiana parallèle, fa noho ny fiparitahan'ny angon-drakitra amin'ny cores CPU maro. Amin'ny rafitra fiasa maoderina, ny rakitra data PostgreSQL dia voatahiry tsara. Miaraka amin'ny famakiana mialoha dia azo atao ny mahazo sakana lehibe kokoa amin'ny fitahirizana noho ny fangatahan'ny daemon PG. Noho izany, ny fahombiazan'ny fangatahana dia tsy voafetra amin'ny disk I/O. Mandany tsingerin'ny CPU izy io mba:
- vakio tsirairay ny andalana avy amin'ny pejin'ny latabatra;
- ampitahao ny soatoavina sy ny fepetra
WHERE.
Andao hanao fanontaniana tsotra 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 msNy scan sequential dia mamokatra andalana be loatra tsy misy aggregation, noho izany dia tanterahan'ny core CPU tokana ny fangatahana.
Raha ampianao SUM(), hitanao fa ny workflows roa dia hanampy hanafaingana ny fangatahana:
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 msFanangonana parallèle
Ny node Parallel Seq Scan dia mamokatra andalana ho an'ny fitambarana ampahany. Ny node "Partial Aggregate" dia manapaka ireo tsipika ireo amin'ny fampiasana SUM(). Amin'ny farany, ny kaontera SUM avy amin'ny fizotran'ny mpiasa tsirairay dia angonin'ny node "Manangona".
Ny vokatra farany dia kajy amin'ny alalan'ny "Finalize Aggregate". Raha manana ny asa fanakambananao manokana ianao dia aza adino ny manisy marika azy ireo ho "parallel safe".
Isan'ny fizotry ny mpiasa
Ny isan'ny dingan'ny mpiasa dia azo ampitomboina raha tsy mamerina ny mpizara:
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 msInona no mitranga eto? Nitombo avo roa heny ny fizotran'ny asa, ary lasa 2 heny ny fangatahana. Mahaliana ny kajy. Nanana dingana mpiasa 1,6599 sy mpitarika 2 izahay. Taorian'ny fanovana dia lasa 1 + 4.
Ny hafainganam-pandeha ambony indrindra avy amin'ny fanodinana parallèle: 5/3 = 1,66(6) heny.
Ahoana no miasa?
Ireo dingana
Ny fanatanterahana ny fangatahana dia manomboka hatrany amin'ny dingana fitarihana. Ny mpitarika dia manao ny zava-drehetra tsy mifanitsy ary ny sasany fanodinana parallèle. Ny dingana hafa izay manao fangatahana mitovy dia antsoina hoe fizotry ny mpiasa. Mampiasa fotodrafitrasa ny fanodinana parallèle (avy amin'ny version 9.4). Satria ny ampahany hafa amin'ny PostgreSQL dia mampiasa fomba fiasa fa tsy kofehy, ny fangatahana miaraka amin'ny fizotran'ny mpiasa 3 dia mety ho in-4 haingana kokoa noho ny fanodinana nentim-paharazana.
fifandraisana
Ny fizotran'ny mpiasa dia mifandray amin'ny mpitarika amin'ny alàlan'ny filaharana hafatra (mifototra amin'ny fitadidiana iombonana). Ny dingana tsirairay dia misy filaharana 2: ho an'ny hadisoana sy ho an'ny tuple.
Firy ny workflows ilaina?
Ny fetra farany ambany dia voafaritra amin'ny parameter . Ny mpihazakazaka fangatahana dia maka ny fizotran'ny mpiasa avy amin'ny dobo voafetra amin'ny parameter . Ny fetra farany dia , izany hoe ny totalin'ny fizotran'ny background.
Raha toa ka tsy azo atao ny mizara ny fizotran'ny mpiasa, ny fanodinana dia ho dingana tokana.
Ny drafitry ny fangatahana dia afaka mampihena ny fizotran'ny asa arakaraka ny haben'ny latabatra na ny tondro. Misy masontsivana amin'izany и .
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 workerIsaky ny latabatra dia in-3 lehibe noho min_parallel_(index|table)_scan_size, Postgres manampy fizotry ny mpiasa. Ny isan'ny workflows dia tsy mifototra amin'ny vidiny. Ny fiankinan-doha boribory dia manasarotra ny fampiharana sarotra. Mampiasa fitsipika tsotra kosa ny mpandrindra.
Amin'ny fampiharana, ireo fitsipika ireo dia tsy mety amin'ny famokarana, noho izany dia azonao atao ny manova ny isan'ny fizotran'ny mpiasa ho an'ny latabatra manokana: ALTER TABLE ... SET (parallel_workers = N).
Nahoana no tsy ampiasaina ny fanodinana parallèle?
Ho fanampin'ny lisitry ny fameperana lava dia misy ihany koa ny fisavana ny vidiny:
- mba hisorohana ny fanodinana parallèle ny fangatahana fohy. Ity mari-pamantarana ity dia manombana ny fotoana hanomanana ny fitadidiana, ny fanombohana ny dingana ary ny fifanakalozam-baovao voalohany.
: Ny fifandraisana eo amin'ny mpitarika sy ny mpiasa dia mety hahemotra araka ny isan'ny tuple avy amin'ny fizotran'ny asa. Kajy ny vidin'ny fifanakalozana angona ity paramètre ity.
Mikambana amin'ny Nested 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)Ny fanangonana dia miseho amin'ny dingana farany, ka ny Nested Loop Left Join dia hetsika mifanitsy. Parallel Index Only Scan dia nampidirina tamin'ny version 10 ihany. Mitovitovy amin'ny scanning serial parallel izy io. toe-javatra c_custkey = o_custkey mamaky baiko iray isaky ny tady mpanjifa. Ka tsy mifanitsy.
Hash Join
Ny fizotry ny mpiasa tsirairay dia mamorona latabatra tenifototra mandra-pahatongan'ny PostgreSQL 11. Ary raha misy mihoatra ny efatra amin'ireo dingana ireo, dia tsy hihatsara ny fampisehoana. Amin'ny dikan-teny vaovao dia zaraina ny latabatra hash. Ny dingan'ny mpiasa tsirairay dia afaka mampiasa WORK_MEM mba hamoronana latabatra hash.
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 msNy fanontaniana 12 avy amin'ny TPC-H dia mampiseho mazava tsara ny fifandraisana tenifototra mifanitsy. Ny dingan'ny mpiasa tsirairay dia mandray anjara amin'ny famoronana latabatra hash mahazatra.
Merge Join
Ny fampifangaroana dia tsy mitovy amin'ny natiora. Aza manahy raha ity no dingana farany amin'ny fangatahana - mbola afaka mandeha mifanitsy.
-- 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)Ny node "Merge Join" dia hita eo ambonin'ny "Gather Merge". Noho izany, ny fampifangaroana dia tsy mampiasa fanodinana parallèle. Saingy ny node "Parallel Index Scan" dia mbola manampy amin'ny fizarana part_pkey.
Fifandraisana amin'ny fizarana
Ao amin'ny PostgreSQL 11 kilemaina amin'ny alàlan'ny default: manana fandaharam-potoana lafo be. Ny latabatra misy fizarazarana mitovy dia azo ampifandraisina amin'ny fisarahana. Amin'izany fomba izany dia hampiasa latabatra hash kely kokoa ny Postgres. Ny fifandraisana tsirairay amin'ny fizarana dia mety ho parallèle.
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)Ny tena zava-dehibe dia ny fifandraisana amin'ny fizarana dia mifanandrify raha toa ka lehibe ireo fizarana ireo.
Parallel Append
azo ampiasaina ho solon'ny bloc samihafa amin'ny workflows samihafa. Matetika izany dia mitranga amin'ny fangatahana UNION ALL. Ny fatiantoka dia kely kokoa ny parallelism, satria ny fizotran'ny mpiasa tsirairay dia manao fangatahana 1 fotsiny.
Misy fizotry ny mpiasa 2 mandeha eto, na dia azo atao aza ny 4.
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)Ny variables manan-danja indrindra
- WORK_MEM dia mametra ny fitadidiana isaky ny dingana, fa tsy fanontaniana fotsiny: work_mem dingana fifandraisana = fitadidiana be.
- - firy amin'ny mpiasa no miasa amin'ny programa mpanatanteraka hampiasaina amin'ny fanodinana mitovy amin'ny drafitra.
- - manitsy ny totalin'ny fizotran'ny mpiasa amin'ny isan'ny cores CPU ao amin'ny server.
- - mitovy, fa ho an'ny fizotran'ny asa parallèle.
vokatra
Amin'ny dikan-teny 9.6, ny fanodinana parallèle dia afaka manatsara ny fahombiazan'ny fanontaniana sarotra izay mijery andalana na index maro. Ao amin'ny PostgreSQL 10, ny fanodinana parallèle dia alefa amin'ny alàlan'ny default. Aza hadino ny manafoana izany amin'ny mpizara manana enta-mavesatra OLTP. Mandany loharanon-karena maro ny scan sequential na ny index scan. Raha tsy manao tatitra momba ny angon-drakitra manontolo ianao, dia azonao atao ny manatsara ny fahombiazan'ny fangatahana amin'ny alàlan'ny fampidirana tondro tsy hita fotsiny na fampiasana fizarazarana mety.
soratra masina
Source: www.habr.com