Мониторинг

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.