Online zpracování transakcí (OLTP)

Správa transakčních dat pomocí počítačových systémů se označuje jako online zpracování transakcí (OLTP). Systémy OLTP zaznamenávají obchodní interakce, ke kterým dochází v každodenní operaci organizace, a podporují dotazování těchto dat, aby bylo možno odvozovat.

Transakční data

Transakční data jsou informace, které sledují interakce související s aktivitami organizace. Tyto interakce jsou obvykle obchodní transakce, jako jsou platby přijaté od zákazníků, platby dodavatelů, produkty procházející inventarizací, přijatými objednávkami nebo službami dodaných. Transakční události, které představují samotné transakce, obvykle obsahují časovou dimenzi, některé číselné hodnoty a odkazy na jiná data.

Transakce obvykle musí být atomické a konzistentní. Atomicita znamená, že celá transakce vždy proběhne úspěšně nebo selže jako jedna jednotka práce a nikdy nezůstane v polokončném stavu. Pokud transakci nelze dokončit, databázový systém musí vrátit zpět všechny kroky, které byly již provedeny jako součást této transakce. V tradičním systému řízení relačních databází (RDBMS) k tomuto vrácení zpět dojde automaticky, když se transakce nemůže dokončit. Konzistence znamená, že transakce vždy zanechávají data v platném stavu. Tyto transakce jsou neformální popisy atomicity a konzistence. Existují formální definice těchto vlastností, jako jsou atomické, konzistentní, izolované a odolné (ACID).

Transakční databáze mohou podporovat silnou konzistenci transakcí pomocí různých strategií uzamčení, jako je pesimistické uzamčení. Tyto strategie pomáhají zajistit, aby všechna data zůstala konzistentní v kontextu úlohy pro všechny uživatele a procesy.

Nejběžnější architekturou nasazení, která používá transakční data, je vrstva úložiště dat v třívrstvé architektuře. Tříúrovňová architektura se obvykle skládá z prezentační vrstvy, vrstvy obchodní logiky a vrstvy úložiště dat. Související architektura nasazení je N-úrovňová architektura, která může mít více středních vrstev zpracovávajících obchodní logiku.

Typické vlastnosti transakčních dat

Transakční data mají tendenci mít následující vlastnosti.

Požadavek Popis
Normalizace Vysoce normalizované
Schéma Schéma při zápisu, vynucené
Konzistence Silná konzistence, záruky ACID
Integrita Vysoká integrita
Používá transakce. Ano
Strategie uzamykání Pesimistické nebo optimistické
Aktualizovatelné Ano
Připojitelné Ano
Pracovní zátěž Intenzivní zápisy, umírněné čtení
Indexování Primární a sekundární indexy
Velikost datumu Malá až střední
Flexibilita dotazů Vysoce flexibilní
Měřítko Malé (MB) až velké (několik TB)

Kdy použít toto řešení

Zvolte OLTP, když potřebujete efektivně zpracovávat a ukládat obchodní transakce a okamžitě je zpřístupnit klientským aplikacím konzistentním způsobem. Tuto architekturu použijte v případě, že jakékoli hmatatelné zpoždění zpracování má negativní vliv na každodenní provoz firmy.

Systémy OLTP jsou navržené tak, aby efektivně zpracovávaly a ukládaly transakce a dotazují se na transakční data. Cílem efektivního zpracování a ukládání jednotlivých transakcí systémem OLTP je částečně dosaženo normalizací dat, což rozdělí data do menších, méně redundantních bloků dat. Tento krok umožňuje systému OLTP zpracovávat velký počet transakcí nezávisle. Vyhýbá se také dodatečným procesům potřebným k zachování integrity dat v přítomnosti redundantních dat.

Výzvy

Systém OLTP může vytvořit několik výzev:

  • Při analýze dat, které se opírají o agregované výpočty nad miliony jednotlivých transakcí, je to pro systém OLTP velmi náročné na prostředky. Mohou být pomalé a způsobit zpomalení tím, že blokují další transakce v databázi. V důsledku toho systémy OLTP nejsou vždy ideální pro zpracování agregací nad velkým množstvím distribuovaných dat. Existují ale výjimky, jako je dobře naplánované schéma.

  • Při provádění analýz a vytváření sestav dat, která jsou vysoce normalizovaná, jsou dotazy obvykle složité, protože většina dotazů potřebuje denormalizovat data pomocí spojení. Vyšší normalizace může firemním uživatelům ztížit dotazování bez pomoci správce databáze (DBA) nebo vývojáře dat.

  • Pokud ukládáte historii transakcí po neomezenou dobu nebo ukládáte příliš mnoho dat v libovolné tabulce, může to vést k pomalému výkonu dotazů v závislosti na počtu transakcí, které ukládáte. Běžným řešením je udržovat relevantní časové období (například aktuální fiskální rok) v systému OLTP a přesměrovat historická data do jiných systémů, jako je datové tržiště nebo datový sklad.

OLTP v Azure

Aplikace, jako jsou weby hostované ve službě App Service Web Apps, rozhraní REST API spuštěná ve službě App Service a mobilní nebo desktopové aplikace, obvykle komunikují se systémem OLTP prostřednictvím zprostředkujícího rozhraní REST API.

Většina úloh v praxi není zcela OLTP. Často zahrnují také analytickou komponentu a vyžadují tvorbu sestav v reálném čase, například vytváření sestav na základě dat z operačního systému. Tato úloha se označuje jako hybridní transakční a analytické zpracování (HTAP). Další informace najdete v tématu OLAP (Online Analytical Processing).

V Azure splňují následující úložiště dat základní požadavky pro OLTP a správu transakčních dat:

Klíčová kritéria výběru

Pokud chcete volby zúžit, začněte odpovězte na následující otázky:

  • Chcete místo správy vlastních serverů spravovanou službu?

  • Má vaše řešení specifické závislosti pro kompatibilitu Microsoft SQL Serveru, MySQL nebo PostgreSQL? Vaše aplikace může omezit úložiště dat, která můžete zvolit na základě ovladačů, které podporuje pro komunikaci s úložištěm dat, nebo předpoklady, které činí o tom, kterou databázi používá.

  • Jsou požadavky na propustnost zápisu vysoké? Pokud ano, zvolte možnost, která poskytuje tabulky v paměti nebo možnosti globální distribuce, jako je Azure Cosmos DB.

  • Je vaše řešení víceklientní? Pokud ano, zvažte možnosti, které podporují kapacitní fondy. Více instancí databáze čerpají z flexibilního fondu prostředků, namísto pevných prostředků přidělených na databázi. Elastické fondy vám můžou pomoct lépe distribuovat kapacitu napříč všemi instancemi databáze a zlepšit nákladovou efektivitu vašeho řešení. Azure Cosmos DB nabízí více modelů izolace pro scénáře s více tenanty.

  • Musí být vaše data čitelná s nízkou latencí ve více oblastech? Pokud ano, zvolte možnost, která podporuje čitelné sekundární repliky nebo globální distribuci.

  • Musí být vaše databáze vysoce dostupná napříč geografickými oblastmi? Pokud ano, zvolte možnost, která podporuje geografickou replikaci. Zvažte také možnosti, které podporují automatické převzetí služeb při selhání z primární repliky na sekundární repliku.

  • Vyžaduje vaše úloha zaručené transakce ACID? Pokud pracujete s nerelačními daty, zvažte službu Azure Cosmos DB, která poskytuje záruky ACID prostřednictvím transakčních dávkových operací v rámci logického oddílu.

  • Má vaše databáze specifické potřeby zabezpečení? Pokud ano, prozkoumejte možnosti, které poskytují možnosti, jako je zabezpečení na úrovni řádků, maskování dat a transparentní šifrování dat.

  • Vyžaduje vaše řešení distribuované transakce? Pokud ano, zvažte elastické transakce ve službě Azure SQL Database a ve spravované instanci SQL. Spravovaná instance SQL také podporuje tradiční volání prostřednictvím koordinátoru distribuovaných transakcí (MSDTC).

Přispěvatelé

Tento článek aktualizuje a udržuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

  • Last updated on