Přeskočit na hlavní obsah

MySQL 5.0 díl.2

Typ tabulky InnoDB zvládá i další vlastnost a tou je tzv. transakční zpracování. Ve chvíli, kdy Vaše aplikace bude používat akční dotazy nad důležitými daty, jistě budete hledat způsob, jak tyto data co nejlépe ošetřit.

K tomu dobře poslouží transakce. Setkal jsem se i s názory, kteří transakční zpracování odsuzují z toho či onoho důvodu. Já, jako člověk, který tyto věci využívá v praxi mohu jen podotknout, že je to pro mě určitá záchrana při práci s akčními dotazy.

Co to je, to transakční zpracování dat? Jedná se způsob, pomocí kterého mohu své předešlé kroky navrátit zpět nebo je potvrdit. Série příkazu UPDATE, DELETE, INSERT, které jsou spuštěny při transakčním zpracování, se provedou tehdy, když uznám, že po změně nedojde k znehodnocení dat. Fyzicky se dané akce provedou až po úspěšném ukončení, do té doby jsou dočasně uloženy jen jako série příkazů, které čekají na ukončení. To sebou přináší i tu vlastnost, že zpracování může být v polovině přerušeno (např. výpadkem proudu) a přesto je možné dané úkony dokončit. Je jasné, že tuto vlastnost musíme brát s rezervou a neočekávat vždy spásnou pomoc od nedokončených transakcí. Tím mám na mysli, že se daná série příkazů již nikdy neprovede, nikoli, že by znehodnotila data.

Příkazy pro transakční zpracování jsou následující:

  • start transaction – spouští provedení transakčního zpracování

  • rollback – navrací veškeré změny a uvede data zpět do stavu před spuštěnou transakcí

  • commit – potvrzuje příkazy, zapisuje změny a uvolňuje systémové prostředky potřebné při transakci



Použití transakcí
Domnívám se, že je zbytečné zde vypisovat sérii nějakých akčních dotazu, kde na konci provedu commit či rollback. Spíše než to, je lepší malá ukázka v PHP, jak lze transakce smysluplně využít.

Příklad:

class Error
{
private $error = array();

public function __construct() {}

public function addError($err)
{
if (!in_array($err, $this->error)) {
$this->error[] = $err;
}
}

public function isError()
{
return (boolean) count($this->error);
}

}

$mysqli = new mysqli(/* connect */);
$error = new Error();

$mysqli->query("start transaction");

$query = "UPDATE uzivatele SET prijmeni = 'Novák' WHERE login = 'paveln'";
if ($mysqli->query($query) === false) {
$error->addError($mysqli->error);
}

/* dalsi akcni dotazy */

if (!$error->isError()) {
$mysqli->query("commit");
} else {
$mysqli->query("rollback");
}


Použil jsem zde záměrně vlastní jednoduchou třídu na kontrolu chyb. Je jasné, že příklad je pouze ilustrativní, ale potvrzení transakce mohu provést jedině ve chvíli, kdy jsem si jist, že to má data nijak neznehodnotí. Toto považuji za smysluplné použití transakčního zpracování, kdy pomocí nějaké vlastní aplikace budu rozhodovat, zda sérii příkazů zruším, či potvrdím.

Při práci s tabulkami při transakčním zpracování bychom si měli dát pozor zejména na příkaz: TRUNCATE TABLE, který vymaže data z tabulky a nastaví auto_increment na 1. Po provedení takového příkazu totiž není možné pomocí rollback získat data zpět.

Omezení existuje celá řada, k tomu doporučuji manuál a prostudovat samotné transakce tam.

Poslední věcí o které se zmíním je nastavení automatických transakcí. V souboru my.cnf nalezneme direktivu innodb_flush_log_at_trx_commit, která pokud je nastavena na 1, provádí automaticky transakce. Toto chování se mi zdá nežádoucí a jako takové ho pro jistotu vypínám.
Důvod proč něco takového dělám je rychlost aplikace. Pokud například vkládám velké množství dat, které není nijak zásadní pro běh aplikace a data mám zálohována, provedu úkon bez transakčního zpracování. Jednou ohromnou nevýhodou je totiž extrémní nárůst potřebných systémových prostředků.

Transakce byste měli používat s rozvahou, ale také se jich nebát, protože sebou přináší jistý komfort při modifikaci dat.

V příštím díle se budu věnovat triggerům a důvodům, proč něco takového využívat.

Komentáře

  1. `innodb_flush_log_at_trx_commit` vůbec neovlivňuje provádění transakcí. Určuje, jestli se má při dokončení transakce zapsat log, což má vliv na výkon, ale pokud bezprostředně potom dojde ke spadnutí serveru, tak data přežijí.

    Automatické provádění transakcí nastavuje příkaz SET AUTOCOMMIT.

    Taky nevím, proč se tento seriál jmenuje MySQL 5.0, když je o tabulkách typu InnoDB, které mají popsané vlastnosti už dávno...

    OdpovědětVymazat
  2. Ale o tom přece transakce částečně jsou. Pokud dojde k nějakému výpadku či neočekávané údálosti, existuje daný log, z kterého je MySQL schopna pochopit, co se vlastně provádělo a k těmto příkazům se zpět vrátit. Přiznávám, že by zde mělo být spíše napsáno, že se jedná o zapnutí ukládání do logu pro nečekaný výpadek DB.

    Právě to automatické spouštění transakcí není vždy ideální řešení. Ruční spouštění transakcí je v mnoha případěch lepší řešení. Zejména, pokud se budu bavit o plnění milionů vět z jiných DBMS systémů.

    Není jen o tabulkách InnoDB, i jiném díle jsem psal např. o triggerech, které jsou až ve verzi 5.0.

    OdpovědětVymazat
  3. `innodb_flush_log_at_trx_commit` opravdu nemá nic společného s tím, jestli se operace budou provádět v transakci nebo ne. Podívej se do "dokumentace":http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html#optvar_innodb_flush_log_at_trx_commit. Je to čistě výkonností nastavení.

    Nevšiml jsem si, že bys psal o triggerech. Psal jsi jen o omezeních cizího klíče a to MySQL podporuje od nepaměti: "Starting from MySQL 3.23.44, InnoDB features foreign key constraints.":http://dev.mysql.com/doc/refman/4.1/en/innodb-foreign-key-constraints.html

    OdpovědětVymazat
  4. Je to slovíčkaření, psal jsem článek o triggerech, jedná se spíše o bug, ale je to vše kolem MySQL. Navíc v tomto chci pokračovat a dalším dílem mají být právě triggery, které jsou vlastností až verze 5.0. Nikde jsem netvrdil, že InnoDB je vlastností až verze 5.0.

    Jen výkonnostní samozřejmě ne, nějaký důvod to má a to je ten, že ukládá právě zmiňovaný log, který lze použít při nějaké neočekávané chybě DB.

    Souhlas, že innodb_flush_log_at_trx_commit neslouží k zapínání transakcí, díky za upozornění.

    OdpovědětVymazat
  5. V pohodě. Jen mě zarazilo, že seriál nazvaný MySQL 5.0 má první dva díly o tom, co už je v MySQL od verze 3.23 :-).

    OdpovědětVymazat

Okomentovat

Populární příspěvky z tohoto blogu

Jak si v IT vydělat hodně peněz?

Na začátek by bylo dobré, abych objasnil samotný titulek, který může na někoho působit jako červený hadr. Článek nebude o obecných pravidlech, ale bude vyprávět můj vlastní příběh, na kterém vám zkusím ukázat, jak se dá docílit úspěchu, či alespoň správně nastartovat svojí vlastní kariéru v IT.

I když se z názvu článku dá dedukovat, že se vše bude točit kolem peněz, není tomu tak. Alespoň ze dvou třetin určitě ne. Ale to už předbíhám, pojďme to raději vzít hezky popořadě...

Kdybychom měli mluvit o roce 2017 jako o přelomové době, nejspíše to nebude pravda. I když pro někoho to může být rok plný úspěchů a štěstí v podobě narození zdravých dětí, svatby či první velké lásky, tak z pohledu lidstva se jedná o rok, který jen kopíruje předešlé a v oblasti technologií nás posouvá stejným tempem jako rok předtím.

Jsem naprosto přesvědčen o tom, že i když se současná doba tak nenazývá, tak prožíváme dobu, která jednou bude označena za revoluční, a to zejména díky vynálezu internetu, který je st…

Jak by se firmy neměly chovat k programátorům?

Každý, kdo pracuje v IT oboru, se jistě již setkal s různými „geniálními nápady“, od kterých si firma slibovala zlepšení produktivity či snížení nákladů. Ať už je to zavedení agilních principů, striktní kontrola práce či zavedení nové a skvělé metodiky, o které si „šéf“ přečetl včera na internetu. Jsou z toho skutečně tak nadšení i samotní vývojáři? A bude nový nápad fungovat?
K napsání tohoto článku mě navedly různé programátorské diskuze, kde si lidé stěžovali na firmu, kde pracují. Příklady, které zde uvedu, jsou z reálné praxe. Ať už jsem je zažil jako řadový programátor, či jako šéf týmu.
I když je poptávka po programátorech tak vysoká, že Vás headhunteři nahánějí i ve chvílích, kdy o to opravdu nestojíte, tak i přes to je mnoho lidí, kteří se bojí opustit svoje současné zaměstnání.
Čeho se nejčastěji bojíme? Je to samozřejmě nejistota, kterou si často omlouváme větami jako: „Tady mám své pohodlí, co když to jinde mít nebudu?“ nebo „I když mě to v práci štve a nebaví, tak mě ale…

Jak jsem technologicky postavil startup

Tento příběh pojednává o technologiích, nástrojích a vůbec o všem, co jsem potřeboval k tomu, abych byl schopen, postavit startup na zelené louce.

Každý správný příběh začíná stejně: "Jednou jsem...."

Kapitola první: Nápad
Jednou jsem se setkal s člověkem, který měl nápad na produkt, který se v průmyslu zatím nevyskytuje. I přes prvotní skepsi, kdy jsem si říkal: "Tohle už přeci dávno v průmyslu existuje, ne?", jsem došel ke zjištění, že nikoli.

Tím jsem se dostal ke svému prvnímu poučení. Průmysl je technologicky dost zabržděný. Osobně se domnívám, že těch důvodů, proč tomu tak je, je několik. Za prvé je to fakt, že většina lidí, kteří se pohybují v tomto odvětví jsou často konzervativní a za správné považují pouze léty osvědčené věci. Druhým důvodem je to, že jakákoli změna znamená riziko. Ať už z pohledu finanční ztráty tak i z pohledu stability výroby. No a třetím a nejzásadnějším důvodem je to, že ač zde máme spousty technologických vymožeností, narážíme na to,…