Changes between Version 6 and Version 7 of Phase4_Performance_Analysis


Ignore:
Timestamp:
06/26/26 02:24:18 (3 days ago)
Author:
226052
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Phase4_Performance_Analysis

    v6 v7  
    66* payment_copy - непартиционирана табела за плаќања;
    77* payment - партиционирана табела според payment_date, со индекс за датум и вработен.
    8 За оваа анализа беше користено pgbench. Секој тест се извршува со повеќе паралелни клиенти, при што се мерат просечна латентност и TPS, односно број на трансакции во секунда. Во сите тестови бројот на неуспешни трансакции беше 0.
     8За оваа анализа беше користено pgbench. Секој тест се извршува со повеќе паралелни клиенти, при што се мерат просечна латентност, standard deviation и TPS односно број на трансакции во секунда. Standard deviation покажува колку варира времето на извршување околу просечната латентност, па помала вредност значи постабилни и попредвидливи перформанси.
    99
    1010
    1111Пример за извршување на benchmark тест:
    1212
    13 {{{ 
    14 pgbench -n -U admin -d film_rental -c 10 -j 2 -T 60 -f /tmp/movie_recommendation_rental_copy.sql  
     13{{{
     14pgbench -n -U admin -d film_rental -c 10 -j 2 -T 60 -f /tmp/movie_recommendation_rental_copy.sql -l --log-prefix=/tmp/movie_recommendation_rental_copy_c10
    1515}}}
    1616
    … …  
    2323* -T 60 означува времетраење од 60 секунди;
    2424* -f ја задава SQL датотеката што се извршува.
     25* --log-prefix ја задава патеката и префиксот на log датотеките во кои pgbench ги запишува резултатите.
    2526
    2627Истата команда се повторуваше со различен број клиенти, на пример 10, 20, 30 и 50, и со SQL датотеки за неоптимизираната и оптимизираната верзија.
     28
     29
     30За пресметување на standard deviation од pgbench log датотеките се користеше следната awk команда:
     31
     32{{{
     33awk '
     34$3 ~ /^[0-9]+$/ {
     35  n++;
     36  x=$3/1000;
     37  sum+=x;
     38  sumsq+=x*x
     39}
     40END {
     41  mean=sum/n;
     42  stddev=sqrt((sumsq - (sum*sum/n))/(n-1));
     43  printf "transactions=%d\nmean=%.3f ms\nstddev=%.3f ms\n", n, mean, stddev
     44}
     45' /tmp/movie_recommendation_rental_copy_c10*
     46}}}
     47
     48Во log датотеките што ги генерира pgbench, секој ред претставува една извршена трансакција. Третата колона ($3) го содржи времето на извршување на таа трансакција, изразено во микросекунди. Бидејќи во табелите резултатите се прикажуваат во милисекунди, вредноста од третата колона се дели со 1000. Потоа од сите добиени вредности се пресметуваат просечната латентност и standard deviation.
    2749
    2850== Детални резултати
    … …  
    97119За оптимизираната верзија се користи истата логика, но наместо rental_copy се користи партиционираната табела rental.
    98120
    99 || '''Clients''' || '''Threads''' || '''rental_copy latency''' || '''rental_copy TPS''' || '''rental latency''' || '''rental TPS''' ||
    100 || 10            || 2             || 2235.603 ms               || 4.473                 || 1083.428 ms          || 9.230            ||
    101 || 20            || 4             || 4036.198 ms               || 4.955                 || 2208.459 ms          || 9.056            ||
    102 || 50            || 4             || 9487.494 ms               || 5.270                 || 5247.761 ms          || 9.528            ||
    103 
    104 Q1 покажува значително подобрување кај оптимизираната табела. Кај 10 клиенти латентноста е намалена за околу 51.5%, а TPS е зголемен за околу 106.3%. Кај 50 клиенти латентноста е намалена за околу 44.7%, а TPS е зголемен за околу 80.8%. Ова се случува бидејќи прашалникот користи customer_id, inventory_id и rental_date. Индексите помагаат при пребарување на историјата на корисникот, а партиционирањето помага при делот од прашалникот кој ја пресметува популарноста за 2024 година.
     121|| '''Clients''' || '''Threads''' || '''rental_copy latency''' || '''rental_copy stddev''' || '''rental_copy TPS''' || '''rental latency''' || '''rental stddev''' || '''rental TPS''' || '''Промена''' ||
     122|| 10 || 2 || 2345.556 ms || 945.171 ms || 4.263 || 1653.931 ms || 549.645 ms || 6.046 || ~29.5% побрзо ||
     123|| 20 || 4 || 4820.854 ms || 1526.728 ms || 4.149 || 3020.244 ms || 889.134 ms || 6.622 || ~37.4% побрзо ||
     124|| 50 || 4 || 9811.989 ms || 2272.239 ms || 5.096 || 7444.747 ms || 1702.896 ms || 6.716 || ~24.1% побрзо ||
     125
     126Q1 покажува подобрување кај оптимизираната табела кај сите нивоа на конкурентност. Кај 10 клиенти латентноста се намалува од 2345.556 ms на 1653.931 ms, а кај 50 клиенти од 9811.989 ms на 7444.747 ms.
     127
     128Standard deviation исто така е помала кај оптимизираната верзија. Кај 10 клиенти се намалува од 945.171 ms на 549.645 ms, а кај 50 клиенти од 2272.239 ms на 1702.896 ms. Ова покажува дека партиционирањето и индексите не само што го намалуваат просечното време на извршување, туку го прават извршувањето постабилно.
    105129
    106130=== Q2 - Popular Films 2024
    … …  
    124148За оптимизираната верзија се користи истата логика, но наместо rental_copy се користи партиционираната табела rental.
    125149
    126 || '''Clients''' || '''rental_copy latency''' || '''rental_copy TPS''' || '''rental latency''' || '''rental TPS''' || '''Промена''' ||
    127 || 10 || 2222.438 ms || 4.500 || 1628.696 ms || 6.140 || ~26.7% побрзо ||
    128 || 20 || 4205.239 ms || 4.756 || 3828.958 ms || 5.223 || ~8.9% побрзо ||
    129 || 30 || 6545.865 ms || 4.583 || 6648.265 ms || 4.512 || ~1.6% побавно ||
    130 || 50 || 11077.453 ms || 4.514 || 11290.484 ms || 4.429 || ~1.9% побавно ||
    131 
    132 Q2 има мешани резултати. Кај 10 и 20 клиенти партиционираната табела е побрза, но кај 30 и 50 клиенти резултатот е речиси ист или малку полош.
    133 Ова покажува дека партиционирањето не секогаш гарантира подобрување. Кај овој прашалник, освен читање од rental, има и GROUP BY, ORDER BY и LIMIT. При поголем број паралелни клиенти главен трошок може да станат агрегацијата и сортирањето, а не само читањето на редови од табелата.
     150|| '''Clients''' || '''Threads''' || '''rental_copy latency''' || '''rental_copy stddev''' || '''rental_copy TPS''' || '''rental latency''' || '''rental stddev''' || '''rental TPS''' || '''Промена''' ||
     151|| 10 || 4 || 2183.371 ms || 944.412 ms || 4.580 || 1545.473 ms || 584.405 ms || 6.471 || ~29.2% побрзо ||
     152|| 20 || 4 || 3769.550 ms || 1473.425 ms || 5.306 || 3215.116 ms || 1297.115 ms || 6.221 || ~14.7% побрзо ||
     153|| 30 || 4 || 5653.717 ms || 1793.595 ms || 5.306 || 4893.620 ms || 1679.520 ms || 6.130 || ~13.4% побрзо ||
     154|| 50 || 4 || 10163.130 ms || 3034.697 ms || 4.920 || 7924.103 ms || 2330.346 ms || 6.310 || ~22.0% побрзо ||
     155
     156Q2 покажува подобри резултати кај партиционираната табела. Латентноста е помала кај сите тестирани нивоа на конкурентност, а TPS е повисок. Standard deviation исто така е помала кај оптимизираната верзија, што покажува постабилно време на извршување. Иако прашалникот содржи GROUP BY и ORDER BY, партиционирањето по rental_date и индексот врз rental_date, inventory_id помагаат затоа што филтерот е ограничен на 2024 година.
    134157
    135158
    … …  
    156179За оптимизираната верзија се користи истата логика, но наместо payment_copy се користи партиционираната табела payment.
    157180
    158 || '''Clients''' || '''payment_copy latency''' || '''payment_copy TPS''' || '''payment latency''' || '''payment TPS''' || '''Промена''' ||
    159 || 10 || 2627.300 ms || 3.806 || 1055.953 ms || 9.470 || ~59.8% побрзо ||
    160 || 30 || 8545.741 ms || 3.511 || 3325.437 ms || 9.021 || ~61.1% побрзо ||
    161 || 50 || 16138.221 ms || 3.098 || 5321.565 ms || 9.396 || ~67.0% побрзо ||
    162 
    163 Q3 покажува најстабилно подобрување кај аналитичките прашалници. Прашалникот пресметува месечен приход по продавница за 2024 година, а табелата payment е партиционирана според payment_date. Бидејќи условот користи временски интервал за 2024 година, PostgreSQL може да ја чита партицијата за 2024 година наместо целата табела. Затоа латентноста е намалена за околу 60-67%, а TPS е зголемен за околу 149-203%.
     181|| '''Clients''' || '''Threads''' || '''payment_copy latency''' || '''payment_copy stddev''' || '''payment_copy TPS''' || '''payment latency''' || '''payment stddev''' || '''payment TPS''' || '''Промена''' ||
     182|| 10 || 4 || 2806.844 ms || 891.434 ms || 3.563 || 1121.703 ms || 536.035 ms || 8.915 || ~60.0% побрзо ||
     183|| 30 || 4 || 10642.000 ms || 5393.351 ms || 2.819 || 3062.069 ms || 1034.027 ms || 9.797 || ~71.2% побрзо ||
     184|| 50 || 4 || 24061.723 ms || 9254.155 ms || 2.078 || 5118.177 ms || 1494.030 ms || 9.769 || ~78.7% побрзо ||
     185
     186Q3 има најдобри резултати бидејќи филтерот по payment_date директно го користи партиционирањето на табелата payment. Кај 50 клиенти латентноста се намалува од 24061.723 ms на 5118.177 ms, а TPS се зголемува од 2.078 на 9.769. Standard deviation е значително помала кај партиционираната табела. Кај 50 клиенти се намалува од 9254.155 ms на 1494.030 ms. Ова покажува дека партиционирањето според payment_date значително ја подобрува и брзината и стабилноста на извештајот.
    164187
    165188=== Q4 - INSERT rental
    … …  
    179202За оптимизираната верзија се користи истата логика, но внесувањето се прави во партиционираната табела rental.
    180203
    181 || '''Clients''' || '''rental_copy latency''' || '''rental_copy TPS''' || '''rental latency''' || '''rental TPS''' || '''Промена''' ||
    182 || 10 || 3.121 ms || 3204.533 || 2.855 ms || 3502.623 || ~8.5% побрзо ||
    183 || 30 || 2.949 ms || 10173.818 || 3.147 ms || 9533.949 || ~6.7% побавно ||
    184 || 50 || 6.756 ms || 7400.777 || 3.088 ms || 16190.222 || ~54.3% побрзо ||
    185 
    186 INSERT операциите имаат мешани резултати. Кај 10 и 50 клиенти партиционираната табела е побрза, но кај 30 клиенти непартиционираната табела има малку подобар резултат.
    187 Причината е тоа што при внесување PostgreSQL мора да одреди во која партиција припаѓа новиот ред и мора да ги ажурира индексите. Тоа додава мал overhead, но при поголемо конкурентно оптоварување партиционираната структура може да помогне затоа што записите се насочуваат кон конкретна партиција.
     204|| '''Clients''' || '''Threads''' || '''rental_copy latency''' || '''rental_copy stddev''' || '''rental_copy TPS''' || '''rental latency''' || '''rental stddev''' || '''rental TPS''' || '''Промена''' ||
     205|| 10 || 4 || 2.750 ms || 0.818 ms || 3636.964 || 2.875 ms || 0.937 ms || 3478.295 || ~4.5% побавно ||
     206|| 30 || 4 || 3.000 ms || 1.177 ms || 9999.631 || 3.340 ms || 1.557 ms || 8981.431 || ~11.3% побавно ||
     207|| 50 || 4 || 7.099 ms || 2.297 ms || 7043.696 || 3.501 ms || 2.220 ms || 14281.463 || ~50.7% побрзо ||
     208
     209Кај INSERT операциите резултатите се мешани. Кај 10 и 30 клиенти rental_copy има малку подобри резултати, бидејќи кај партиционираната табела PostgreSQL дополнително одредува во која партиција треба да се внесе редот. Кај 50 клиенти партиционираната табела покажува подобар резултат: латентноста се намалува од 7.099 ms на 3.501 ms, а TPS се зголемува од 7043.696 на 14281.463.
    188210
    189211=== Q5 - UPDATE rental
    … …  
    203225За оптимизираната верзија се користи истата логика, но ажурирањето се прави врз партиционираната табела rental.
    204226
    205 || '''Clients''' || '''rental_copy latency''' || '''rental_copy TPS''' || '''rental latency''' || '''rental TPS''' || '''Промена''' ||
    206 || 10 || 590.026 ms || 16.948 || 7.044 ms || 1419.709 || ~98.8% побрзо ||
    207 || 30 || 1483.097 ms || 20.228 || 12.318 ms || 2435.437 || ~99.2% побрзо ||
    208 || 50 || 2646.029 ms || 18.896 || 16.689 ms || 2996.003 || ~99.4% побрзо ||
    209 
    210 UPDATE операцијата покажува најголемо подобрување. Условот користи конкретен rental_date, па кај партиционираната табела PostgreSQL може да пребарува само во релевантната партиција. Кај rental_copy системот мора да пребарува низ голема непартиционирана табела. Затоа латентноста е многу поголема, а TPS е многу помал.
     227|| '''Clients''' || '''Threads''' || '''rental_copy latency''' || '''rental_copy stddev''' || '''rental_copy TPS''' || '''rental latency''' || '''rental stddev''' || '''rental TPS''' || '''Промена''' ||
     228|| 10 || 4 || 704.821 ms || 61.336 ms || 14.188 || 7.093 ms || 3.997 ms || 1409.861 || ~99.0% побрзо ||
     229|| 30 || 4 || 1923.308 ms || 457.842 ms || 15.598 || 26.970 ms || 16.112 ms || 1112.346 || ~98.6% побрзо ||
     230|| 50 || 4 || 3124.384 ms || 700.922 ms || 16.003 || 17.475 ms || 13.475 ms || 2861.279 || ~99.4% побрзо ||
     231
     232UPDATE операцијата покажува најголемо подобрување. Кај 10 клиенти латентноста се намалува од 704.821 ms на 7.093 ms, а кај 50 клиенти од 3124.384 ms на 17.475 ms. Standard deviation исто така значително се намалува. Кај 50 клиенти се намалува од 700.922 ms на 13.475 ms. Причината е што UPDATE условот користи конкретен rental_date, па кај партиционираната табела PostgreSQL ја ограничува операцијата на релевантната партиција.
    211233
    212234== Вкупно подобрување
    213 Партиционираните табели и индексите покажуваат значително подобрување кај прашалници кои се временски ограничени и кај операции кои можат да се насочат кон конкретна партиција.
     235
     236Партиционираните табели и индексите покажуваат најголемо подобрување кај прашалници кои користат временски филтер врз колоната по која е направено партиционирањето. Освен просечната латентност, во оваа анализа се зема предвид и standard deviation, која покажува колку е стабилно времето на извршување.
     237
    214238Најголеми придобивки:
    215239
    216 * Q3 - Monthly Revenue: околу 64.5% просечно намалување на латентноста.
    217 * Q5 - UPDATE rental: околу 99.2% просечно намалување на латентноста.
    218 * Q1 - Movie Recommendation: околу 45.8% просечно намалување на латентноста.
     240* Q3 - Monthly Revenue: најголемо подобрување кај временски ограничените извештаи. Кај 50 клиенти латентноста се намалува од 24061.723 ms на 5118.177 ms, а standard deviation се намалува од 9254.155 ms на 1494.030 ms. Кај 50 клиенти латентноста се намалува од 24061.723 ms на 5118.177 ms, а standard deviation се намалува од 9254.155 ms на 1494.030 ms.
     241* Q5 - UPDATE rental: најголемо подобрување кај write операциите. Кај 50 клиенти латентноста се намалува од 3124.384 ms на 17.475 ms, а standard deviation се намалува од 700.922 ms на 13.475 ms.
     242* Q1 - Movie Recommendation: има подобрување кај сите нивоа на конкурентност, при што оптимизираната верзија има помала латентност и помала standard deviation.
     243* Q2 - Popular Films: по новите мерења со standard deviation, партиционираната табела има подобри резултати кај сите тестирани нивоа на конкурентност.
    219244
    220245Мешани резултати:
    221 * Q2 - Popular Films има подобрување кај 10 и 20 клиенти, но мало влошување кај 30 и 50 клиенти.
    222 * Q4 - INSERT има подобрување кај 10 и 50 клиенти, но мало влошување кај 30 клиенти.
    223 
    224 Ова покажува дека оптимизацијата мора да се мери. Партиционирањето не е автоматско решение за сите прашалници. Најмногу помага кога WHERE условот ја користи колоната по која е направено партиционирањето.
    225 
    226 == Операции на читање со мешани резултати
    227 
    228 * Q1 - Movie Recommendation: јасно подобрување кај сите нивоа на конкурентност.
    229 * Q2 - Popular Films: подобро кај помал број клиенти, но речиси исто или малку полошо кај поголем број клиенти.
    230 * Q3 - Monthly Revenue: најдобар пример каде партиционирањето директно го намалува бројот на редови што треба да се читаат.
    231 
    232 Кај читањата кои содржат големи агрегации и сортирања, како Q2, главниот проблем не е секогаш табелата од која се чита. Понекогаш главниот трошок е обработката по читањето, односно GROUP BY и ORDER BY.
     246
     247* Q4 - INSERT rental: резултатите се мешани. Кај 10 и 30 клиенти rental_copy е малку побрза, затоа што INSERT во партиционирана табела има дополнителен overhead за избор на партиција. Кај 50 клиенти партиционираната табела е подобра, со помала латентност и поголем TPS.
     248
     249Ова покажува дека оптимизацијата мора да се мери со повеќе метрики. Партиционирањето не е автоматско решение за сите операции, но е многу корисно кога прашалникот користи WHERE услов врз партициската колона, како rental_date или payment_date. Помалата standard deviation кај повеќето оптимизирани тестови покажува и постабилно, попредвидливо извршување.
     250
     251== Операции на читање
     252
     253* Q1 - Movie Recommendation: оптимизираната верзија има помала латентност, поголем TPS и помала standard deviation кај сите нивоа на конкурентност.
     254* Q2 - Popular Films: по новите мерења, партиционираната табела има подобри резултати кај сите тестирани нивоа на конкурентност. Сепак, прашалникот содржи GROUP BY и ORDER BY, па агрегацијата и сортирањето остануваат значаен дел од трошокот.
     255* Q3 - Monthly Revenue: најдобар пример каде партиционирањето директно го намалува бројот на редови што треба да се читаат, бидејќи филтерот користи payment_date, а табелата payment е партиционирана според истата колона.
     256
     257Кај операциите на читање, најдобри резултати се добиваат кога WHERE условот ја користи колоната по која е направено партиционирањето. Дополнително, помалата standard deviation кај оптимизираните верзии покажува дека извршувањето е постабилно и попредвидливо.
    233258
    234259== Операции на запишување
    235260
    236 * INSERT: просечно подобрување, но со варијации.
    237 * UPDATE: многу големо подобрување поради филтрирање по rental_date.
    238 
    239 Кај INSERT, партиционирањето може да додаде overhead затоа што секој ред мора да се насочи во соодветна партиција. Кај UPDATE, партиционирањето е многу корисно кога условот ја користи партициската колона, бидејќи пребарувањето се ограничува на мала партиција наместо на целата табела.
     261* INSERT: резултатите се мешани. Кај 10 и 30 клиенти rental_copy е малку побрза, но кај 50 клиенти партиционираната табела има подобра латентност и повисок TPS.
     262* UPDATE: има многу големо подобрување кај партиционираната табела, затоа што условот користи конкретна вредност за rental_date.
     263
     264Кај INSERT, партиционирањето може да додаде overhead затоа што PostgreSQL мора да одреди во која партиција треба да се внесе новиот ред. Кај UPDATE, партиционирањето е многу корисно кога условот ја користи партициската колона, бидејќи пребарувањето се ограничува на релевантната партиција наместо на целата табела.
    240265
    241266== Заклучок
     267
    242268За ова специфично работно оптоварување:
    243269
    … …  
    245271* Индексите значително помагаат кај прашалници со WHERE услови и JOIN операции врз често користени колони.
    246272* Q3 и Q5 покажуваат најголемо подобрување, затоа што директно ја користат колоната по која е направено партиционирањето.
    247 * Q2 покажува дека партиционирањето не го решава секој проблем, бидејќи агрегацијата и сортирањето можат да станат главен bottleneck.
    248 * INSERT операциите треба да се мерат внимателно, бидејќи партиционирањето и индексите можат да додадат мал overhead.
     273* Q1 и Q2 покажуваат подобрување кај SELECT прашалници кои користат временски филтри, но кај Q2 агрегацијата и сортирањето остануваат значаен дел од трошокот.
     274* INSERT операциите треба да се мерат внимателно, бидејќи партиционирањето може да додаде overhead при внесување, особено при помал број клиенти.
     275* Standard deviation е важна метрика затоа што покажува колку се стабилни перформансите. Кај повеќето оптимизирани тестови standard deviation е помала, што значи дека времето на извршување е попредвидливо.
    249276
    250277Најсоодветен пристап за оваа база е да се задржи партиционирањето по датум за големите трансакциски табели rental и payment, да се користат индекси само за најчестите филтри и спојувања, и редовно да се проверуваат резултатите со EXPLAIN ANALYZE и pgbench.
    251278
    252279
    253 
    254 
    255 
    256 
    257 
    258 
    259 
    260 
    261 
    262 
    263 
    264 
    265 
    266 
    267 
    268 
    269 
    270 
    271 
    272 
    273