Online zpracování transakcí (OLTP)

  • Článek

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, musí databázový systém vrátit zpět všechny kroky, které byly již provedeny v rámci této transakce. V tradiční rdBMS se toto vrácení zpět automaticky provede, pokud transakci nelze dokončit. Konzistence znamená, že transakce vždy opouštějí data v platném stavu. (Jedná se o velmi neformální popis atomicity a konzistence. Existují více formálních definic těchto vlastností, například ACID.)

Transakční databáze mohou podporovat silnou konzistenci transakcí pomocí různých strategií uzamčení, jako je pesimistické uzamčení, aby se zajistilo, že všechna data jsou silně konzistentní v kontextu podniku 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 3úrovňové architektuře. 3ú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, silně 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
Úloha Těžké zápisy, střední čtení
Indexování Primární a sekundární indexy
Velikost datumu Malá až střední
Model Relační
Obrazec dat Tabelární
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, pokud by jakékoli hmatatelné zpoždění zpracování mělo negativní dopad 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 – to znamená rozdělení dat do menších bloků, které jsou méně redundantní. To podporuje efektivitu, protože umožňuje systému OLTP zpracovávat velký počet transakcí nezávisle a vyhnout se dodatečnému zpracování potřebnému k zachování integrity dat v přítomnosti redundantních dat.

Problémy

Implementace a používání systému OLTP může způsobit několik problémů:

  • Systémy OLTP nejsou vždy vhodné pro zpracování agregací nad velkým objemem dat, i když existují výjimky, jako je dobře plánované řešení založené na SQL Serveru. Analýza dat, která spoléhají na agregované výpočty nad miliony jednotlivých transakcí, jsou pro systém OLTP velmi náročné na prostředky. Mohou být pomalé a mohou způsobit zpomalení tím, že blokují jiné transakce v databázi.
  • Při provádění analýz a generování sestav s daty, která jsou vysoce normalizovaná, jsou dotazy obvykle složité, protože většina dotazů potřebuje denormalizuje data pomocí spojení. Zásady vytváření názvů pro databázové objekty v systémech OLTP jsou také obvykle terse a stručné. Vyšší normalizace spojená s terse zásadami vytváření názvů znesnadňuje podnikovým uživatelům dotazování systémů OLTP bez pomoci DBA nebo vývojáře dat.
  • Ukládání historie transakcí na neomezenou dobu a ukládání příliš velkého množství dat v libovolné tabulce může vést k pomalému výkonu dotazů v závislosti na počtu uložených transakcí. 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 nebo mobilní nebo desktopové aplikace komunikují se systémem OLTP, obvykle prostřednictvím zprostředkujícího rozhraní REST API.

Většina úloh v praxi není čistě OLTP. K dispozici je také analytická komponenta. Kromě toho se zvyšuje poptávka po generování sestav v reálném čase, jako je spouštění sestav v provozním systému. Označuje se také jako HTAP (Hybridní transakční a analytické zpracování). Další informace najdete v tématu OLAP (Online Analytical Processing).

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

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

Pokud chcete zúžit možnosti, začněte zodpovězením těchto otázek:

  • 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ředpokladů, které se týkají používané databáze.

  • Jsou vaše požadavky na propustnost zápisu zvláště vysoké? Pokud ano, zvolte možnost, která poskytuje tabulky v paměti.

  • Je vaše řešení víceklientní? Pokud ano, zvažte možnosti, které podporují fondy kapacity, kde více instancí databáze načítá z elastického fondu prostředků místo pevných prostředků na databázi. To vám může pomoct lépe distribuovat kapacitu napříč všemi instancemi databáze a zlepšit tak nákladovou efektivitu vašeho řešení.

  • Musí být vaše data čitelná s nízkou latencí ve více oblastech? Pokud ano, zvolte možnost, která podporuje čtení sekundárních replik.

  • Musí být vaše databáze vysoce dostupná napříč geograficky grafický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.

  • 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.

Matice schopností

Následující tabulky shrnují klíčové rozdíly v možnostech.

Obecné možnosti

Schopnost Azure SQL Database SQL Server na virtuálním počítači Azure Azure Database for MySQL Azure Database for PostgreSQL
Je spravovaná služba Yes Ne Ano Yes
Běží na platformě – Windows, Linux, Docker – N/A
Programovatelnost 1 T-SQL, .NET, R T-SQL, .NET, R, Python SQL SQL, PL/pgSQL, PL/JavaScript (v8)

[1] Nezahrnuje podporu klientských ovladačů, což umožňuje mnoha programovacím jazykům připojit se k úložišti dat OLTP a používat ho.

Možnosti škálovatelnosti

Schopnost Azure SQL Database SQL Server na virtuálním počítači Azure Azure Database for MySQL Azure Database for PostgreSQL
Maximální velikost instance databáze 4 TB 256 TB 16 TB 16 TB
Podporuje fondy kapacity. Ano Ano No Ne
Podporuje horizontální navýšení kapacity clusterů. No Ano No Ne
Dynamická škálovatelnost (vertikální navýšení kapacity) Yes Ne Ano Yes

Analytické možnosti úloh

Schopnost Azure SQL Database SQL Server na virtuálním počítači Azure Azure Database for MySQL Azure Database for PostgreSQL
Dočasné tabulky Ano Ano No Ne
Tabulky v paměti (optimalizované pro paměť) Ano Ano No Ne
Podpora columnstore Ano Ano No Ne
Adaptivní zpracování dotazů Ano Ano No Ne

Možnosti dostupnosti

Schopnost Azure SQL Database SQL Server na virtuálním počítači Azure Azure Database for MySQL Azure Database for PostgreSQL
Čitelné sekundární soubory Ano Ano Ano Yes
Geografická replikace Ano Ano Ano Yes
Automatické převzetí služeb při selhání do sekundárního Yes No No Ne
Obnovení k určitému bodu v čase Ano Ano Ano Yes

Možnosti zabezpečení

Schopnost Azure SQL Database SQL Server na virtuálním počítači Azure Azure Database for MySQL Azure Database for PostgreSQL
Zabezpečení na úrovni řádků Ano Ano Ano Yes
Maskování dat Ano Ano No Ne
Transparentní šifrování dat Ano Ano Ano Yes
Omezení přístupu na konkrétní IP adresy Ano Ano Ano Yes
Omezení přístupu pouze pro povolení přístupu k virtuální síti Ano Ano Ano Yes
Ověřování Microsoft Entra Yes Ne Ano Yes
Ověřování Active Directory No Ano No Ne
Vícefaktorové ověřování Yes Ne Ano Yes
Podporuje funkci Always Encrypted. Ano Ano No Ne
Privátní IP adresa No Ano No Ne

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

Další kroky