Transakční databáze

    Transakční databáze, OLTP (Online Transaction Processing), je databáze, kterou aplikace jako e-shop používá k běžnému provozu: vytváří objednávku, aktualizuje sklad, dohledá jednoho zákazníka. Je navržená na velké množství malých, rychlých a spolehlivých operací probíhajících souběžně, ne na skenování a agregaci historie. Typicky za ní stojí PostgreSQL, MySQL, nebo jiná databáze, na které běží samotná platforma e-shopu.

    Co transakční databáze dělá

    Transakční databáze, odborně OLTP (Online Transaction Processing), je databáze, na které běží samotný provoz aplikace. Vytvoř objednávku, uprav sklad, najdi jednoho konkrétního zákazníka, to jsou operace, na které je stavěná.

    Zpracovává jednu operaci najednou, rychle a spolehlivě

    Návrh transakční databáze je optimalizovaný na velké množství malých operací probíhajících souběžně, ne na skenování milionů řádků. Každá objednávka, změna stavu skladu nebo aktualizace zákazníka je samostatná operace, která musí proběhnout rychle a spolehlivě.

    Je to motor provozu, ne nástroj na analýzu historie

    Transakční databáze drží aktuální stav aplikace, ne historii toho, jak se stav v čase měnil. Typicky za ní stojí PostgreSQL, MySQL, nebo jiná databáze, na které je postavená e-shopová platforma sama.

    Kde firmy pálí peníze

    Nejčastější chyby netýkají se výběru konkrétní technologie, ale toho, jak se transakční databáze používá nad rámec toho, na co je stavěná.

    • Analytický dotaz ohrožuje běžící provoz

      Pustit těžký report přímo na transakční databázi znamená zatížit stejný výkon, na kterém právě běží checkout a příjem objednávek. Hrozí zpomalení, nebo i výpadek části e-shopu, který zrovna obsluhuje zákazníky.

    • Historická data se z výkonových důvodů ztrácejí

      Aby transakční databáze zůstala rychlá, stará data se z ní často mažou nebo archivují mimo dosah běžných dotazů. Dlouhodobé trendy nebo meziroční srovnání pak z ní nejde spočítat, protože podklad k nim tam už není.

    • Snaha ušetřit na odděleném skladu se prodraží jinde

      Neplánovat samostatnou analytickou vrstvu a řešit všechno na produkční databázi vypadá zpočátku jako úspora. Dřív nebo později se ale prodraží na spolehlivosti provozu, protože transakční databáze musí najednou zvládat i zátěž, na kterou nebyla navržená.

    Kdy transakční databáze stačí sama o sobě

    Na běžný provoz aplikace, jednotlivé operace v reálném čase, transakční databáze stačí a je pro to ten správný nástroj. Jakmile ale přibude potřeba dívat se na data napříč časem nebo napříč zdroji, sama na to stavěná není.

    Kdy je potřeba přidat oddělenou analytickou vrstvu

    Ve chvíli, kdy je potřeba report, trend za delší období, nebo pohled spojující data z e-shopu, účetnictví a reklamy dohromady, přichází na řadu samostatná analytická databáze, mimo produkční provoz.

    Plné srovnání a zdůvodnění

    Proč jedna databáze nestačí na obojí, jak přesně se transakční a analytická databáze liší a jak Datimo odděluje reporting od provozu, popisujeme v pojmu Transakční a analytická databáze.