Changes between Version 1 and Version 2 of Transakcii

Timestamp:

02/08/26 21:17:19 (2 weeks ago)

Author:

213192

Comment:

--

Transakcii

@@ -1 +1 @@
 == Трансакции 
 
-Трансакција е логичка целина од повеќе операции над базата на податоци. Тие располагаат со повеќе својства: 
-
-* -атомичност: или сите операции ќе се извршат(commit) или ниедна нема да се зачува(rollback). Пример ако внесеме нов играч и во истата трансакција внесуваме статистики за тој играч, не сакаме да имаме статистики без играч 
-
+Трансакција е логичка целина од повеќе операции над базата на податоци. Тие располагаат со повеќе својства (ACID својства): 
+
+* атомичност: или сите операции ќе се извршат(commit) или ниедна нема да се зачува(rollback). Пример ако внесеме нов играч и во истата трансакција внесуваме статистики за тој играч, не сакаме да имаме статистики без играч 
+
+* конзистентност: многу е важно секоја трансакција да го одржува интегритетот на базата, односно секој запис да ги почитува ограничувањата на базата. На пример, во базата, играчот мора да има валиден тим, во спротивно нема да се изврши трансакцијата.
+
+* изолација: трансакциите се изолирани една од друга. Така, во PostgreSQL нивото на изолација најчесто е READ COMMITTED, што значи дека една трансакција гледа само податоци кои се веќе извршени. Пример: додека една трансакција ажурира вредност, друга не може да види полу-променети податоци.
+
+* трајност: најважно од се е промените да се запишат и зачуваат по извршувањето. За тоа PostgreSQL користи WAL (ќе го споменеме понатаму). Ако серверот се рестартира, податоците нема да бидат изгубени по извршена трансакција.
+
+=== Изолациони нивоа
+
+Изолационите нивоа дефинираат колку една трансакција ќе биде изолирана од другите. Во PostgreSQL постојат:
+
+* READ UNCOMMITTED: трансакцијата  може да чите и непотврдени промени (dirty reads)
+
+* READ COMMITTED: трансакцијата чита само комитирани промени
+
+* REPEATABLE READ: сите SELECT операции во една трансакција гледаат исти податоци
+
+* SERIALIZABLE: највисоко ниво на изолација - трансакциите се случуваат една по друга
+
+READ COMMITTED vs SERIALIZABLE 
+
+{{{
+BEGIN; 
+
+ 
+
+SELECT highest_market_value_in_eur 
+
+FROM players 
+
+WHERE player_id = 26; 
+
+UPDATE players 
+
+SET highest_market_value_in_eur = 7000000 
+
+WHERE player_id = 26; 
+
+ 
+
+COMMIT; 
+
+SELECT highest_market_value_in_eur 
+
+FROM players 
+
+WHERE player_id = 26; 
+
+ 
+
+ 
+
+COMMIT; 
+}}}
+
+Истата трансакција гледа различна вредност, ова е дозволено во READ COMMITTED 
+
+{{{
+BEGIN ISOLATION LEVEL SERIALIZABLE; 
+
+ 
+
+SELECT highest_market_value_in_eur 
+
+FROM players 
+
+WHERE player_id = 26; 
+
+ 
+
+UPDATE players  
+
+SET highest_market_value_in_eur = 9000000  
+
+WHERE player_id = 26;  
+
+COMMIT;  
+
+ 
+
+ 
+
+SELECT highest_market_value_in_eur 
+
+FROM players 
+
+WHERE player_id = 26; 
+
+ 
+
+ 
+
+COMMIT; 
+}}}
+
+Serializable нема non-repeatable read, конзистентност на ниво на трансакција. 
+
+=== Deadlocks
+
+Deadlock настанува кога две или повеќе трансакции меѓусебно се блокираат, најчесто поради тоа што едната чека ресурс што го содржи другата. Најчеста причина за појавување на deadlock е неконзистентен редослед на заклучување на редови.  
+
+{{{
+BEGIN;  
+
+ 
+
+SELECT * FROM players WHERE player_id = 10 FOR UPDATE;  
+
+ 
+
+SELECT * FROM players WHERE player_id = 20 FOR UPDATE;  
+
+ 
+
+COMMIT; 
+
+BEGIN; 
+
+ 
+
+SELECT * FROM players WHERE player_id = 20 FOR UPDATE; 
+
+ 
+
+SELECT * FROM players WHERE player_id = 10 FOR UPDATE; 
+
+ 
+
+COMMIT; 
+}}}
+
+Овие две трансакции ажурираат два играчи, но во различен редослед. PostgreSQL детектира deadlock, но една многу добра карактеристика на PostgreSQL e тоа што има deadlock detector при што автоматски прекинува една трансакција.  
+
+Како да избегнеме deadlock? 
+
+{{{
+SELECT * FROM players 
+
+WHERE player_id IN (10, 20) 
+
+ORDER BY player_id 
+
+FOR UPDATE; 
+}}}
+
+Deadlock состојбите претставуваат сериозен предизвик во системи со висока конкурентност. PostgreSQL користи автоматска детекција на deadlock, при што една од трансакциите се прекинува за да се избегне застој на системот. Примената на конзистентен редослед на заклучување и краткотрајни трансакции значително го намалува ризикот од вакви ситуации. 
+
+=== Locks и MVCC во PostgreSQL
+
+Во системи со повеќе истовремени корисници, базата на податоци мора да обезбеди конзистентност и изолација на податоците, без притоа да се жртвуваат перформансите. PostgreSQL го решава овој проблем преку комбинација на механизми за заклучување (locking) и Multi-Version Concurrency Control (MVCC).
+
+Во овој дел се прикажува разликата помеѓу table-level locking, row-level locking и MVCC, со практични примери кои покажуваат како различните пристапи влијаат врз конкурентноста, блокирањето и видливоста на податоците помеѓу трансакции.
+
+Table-level locking
+
+* целата табела е заклучена
+* други трансакции чекаат, дури и ако работат на друг ред
+* многу лоша конкурентност
+
+{{{
+BEGIN; 
+
+LOCK TABLE players IN ACCESS EXCLUSIVE MODE; 
+
+-- табелата е целосно заклучена 
+
+SELECT * FROM players; (ACCESS EXCLUSIVE е најсилен lock) 
+}}}
+
+Row-level locking
+
+* многу подобра верзија од table-level locking
+* се заклучува само конкретниот ред, другите редови се слободни
+
+{{{
+BEGIN; 
+
+SELECT * FROM players WHERE player_id = 1 FOR UPDATE; 
+
+-- само редот со id=1 е заклучен 
+
+SELECT * FROM players WHERE player_id = 2; 
+
+-- работи нормално 
+
+UPDATE players SET highest_market_value_in_eur = highest_market_value_in_eur - 100 WHERE player_id = 1; 
+
+-- чека, редот е заклучен 
+}}}
+
+MVCC(Multi-Version Concurrency Control)
+
+* наместо locks, PostgreSQL креира нови верзии на редиците (помалку блокирања)
+
+{{{
+-- Session 1
+BEGIN;
+
+UPDATE players
+SET market_value_in_eur = market_value_in_eur - 5000000
+WHERE player_id = 19054; 
+
+-- трансакцијата е започната, но не е направен COMMIT
+}}}
+
+{{{
+-- Session 2
+SELECT market_value_in_eur
+FROM players
+WHERE player_id = 19054;
+-- Session 2 ја гледа старата вредност
+}}}
+
+{{{
+-- Session 1 
+COMMIT;
+}}}
+
+{{{
+-- Session 2
+SELECT market_value_in_eur
+FROM players
+WHERE player_id = 19054;
+-- сега Session 2 ја гледа новата вредност
+}}}
+
+MVCC е одличен бидејќи нема блокирање на SELECT операции, нема dirty reads и има висока конкурентност.