Changes between Initial Version and Version 1 of Monitoring

Timestamp:

05/04/26 21:45:27 (3 weeks ago)

Author:

213192

Comment:

--

Monitoring

@@ +1 @@
+=== Мониторинг
+
+== Query Latency Distribution
+
+Просечниот execution time не ја претставува реалната состојба во системот. На пример 990 прашалници имаат време на извршување 1мс, додека 10 имаат 5000мс. Просекот е 50мс, но може да видиме дека тие 10 прашалници се outliers. Токму овие 10 спори прашалници можат да го нарушат корисничкото искуство. 
+
+Пример за брз прашалник:
+{{{
+SELECT * FROM players WHERE player_id = 10;
+}}}
+
+Пример за спор прашалник:
+{{{
+SELECT 
+    p.player_name,
+    COUNT(t.transfer_id),
+    AVG(t.transfer_fee),
+    SUM(m.attendance)
+FROM players p
+JOIN transfers t ON p.player_id = t.player_id
+JOIN matches m ON m.home_team_id = p.club_id 
+              OR m.away_team_id = p.club_id
+GROUP BY p.player_name;
+}}}
+
+Исто така, имаме два типа на прашалници: еден што има 10000 повици на ден со време на извршување 2мс и друг со 50 повици на ден со 5 секунди време на извршување. Вториот прашалник претставува поголем проблем за нашиот систем бидејќи корисникот не сака да чека slow response.
+
+== Hot Data vs Cold Data Monitoring
+
+Како што веќе видовме, системот располага со повеќе табели. Некои од нив се користат повеќе од останатите и може да се каже дека во реален систем 20% од податоците генерираат 80% од оптоварувањето.
+
+Класичен пример може да најдеме во табелата players. Од сите играчи кои се во табелата, најинтересни се познатите играчи - топ играчи. Токму затоа овие играчи ќе се најдат во повеќе прашалници од останати играчи и ќе се создаде row-level contention. Мониторинг резултат од гореспоменатиот проблем е тоа што играчот со id 10 ќе има 1200 queries/min, додека тој со id 187 ќе има 5 queries/min. Истите сценарија можат да се најдат и во други табели.
+
+Од друга страна, имаме и cold data која ретко се користи, нема locks и contention. 
+
+== Пример
+
+Во Transfermarkt системот, „deadline day“ претставува екстремен случај на оптоварување, при што во краток временски интервал се извршуваат илјадници трансфер операции. За разлика од нормалниот режим, каде системот е претежно read-oriented, во овој период се јавува нагло зголемување на write операции и конкурентни трансакции.
+
+Во наредните примери ќе видиме и зашто ова е едно од најпредизивикувачките сценарија во системот. 
+
+1. Complex Transfer Transaction
+
+Секој трансфер не е едноставен INSERT, туку составена трансакција:
+{{{
+BEGIN;
+
+INSERT INTO transfers(player_id, from_club_id, to_club_id, transfer_fee, season)
+VALUES (25, 3, 8, 12000000, '2025');
+
+UPDATE players
+SET market_value = market_value + 1500000,
+    club_id = 8
+WHERE player_id = 25;
+
+UPDATE clubs
+SET budget = budget - 12000000
+WHERE club_id = 8;
+
+UPDATE clubs
+SET budget = budget + 12000000
+WHERE club_id = 3;
+
+COMMIT;
+}}}
+
+Може да видиме дека имаме 4 write операции во 3 различни табели и сето ова е само за еден играч, додека на deadline day имаме илјадници трансфери. Исто така, системот влегува во contention режим поради тоа што сите трансакции таргетираат исти ентитети (player_id = 25, club_id = 8) и latency и queries/sec се зголемуваат драстично. Уште еден проблем со кој се соочуваме е transaction queueing, а тоа се случува бидејќи трансакцијата која се извршува зад себе остава други трансакции кои чекаат ресурси. Овој проблем е чест и во нормални услови, но на deadline day е многу посериозен. 
+
+== Спојување на две табели во една
+
+Во последниот пример ќе направиме денормализација на системот, односно табелите players и player_valuations ќе ги споиме во една и ќе споредиме што е подобро.
+
+{{{
+SELECT
+p.last_name,
+pv.market_value_in_eur,
+pv.date
+FROM players p
+JOIN player_valuations pv
+ON p.player_id = pv.player_id
+WHERE p.player_id = 10
+ORDER BY pv.date DESC
+LIMIT 1;
+}}}
+
+Ова query има JOIN и ORDER BY + LIMIT.
+
+{{{
+CREATE TABLE players_with_value AS
+SELECT
+p.player_id,
+p.last_name,
+p.current_club_id,
+pv.market_value_in_eur,
+pv.date
+FROM players p
+JOIN player_valuations pv
+ON p.player_id = pv.player_id;
+}}}
+{{{
+SELECT last_name, market_value_in_eur
+FROM players_with_value
+WHERE player_id = 10
+ORDER BY date DESC
+LIMIT 1;
+}}}
+
+Користејќи ја новокреираната табела извршивме query кој не користи JOIN и има побрз пристап. Сепак, целосна денормализација не е најдоброто решение. За најдобри резултати во нашиот систем ќе искористиме partial denormalization, односно ќе направиме нова табела со моменталната/последната вредност на играчот:
+{{{
+CREATE TABLE players_current_value AS
+SELECT DISTINCT ON (player_id)
+player_id,
+market_value,
+date
+FROM player_valuations
+ORDER BY player_id, date DESC;
+}}}
+
+Предности што ги добиваме со ова се тоа што нема непотребно скенирање на целата историја доколку корисникот не ја бара, помалку write операции и помал contention.