Změňte sběr dat - Change data capture

v databáze, změnit sběr dat (CDC) je sada softwaru designové vzory slouží k určení a sledování dat, která se změnila, aby bylo možné provést akci pomocí změněných dat.

CDC je přístup k integraci dat, který je založen na identifikaci, zachycení a dodání změn provedených ve zdrojích podnikových dat.

CDC se často vyskytuje v datový sklad Prostředí, protože zachycení a uchování stavu dat v čase je jednou ze základních funkcí datového skladu, ale CDC lze použít v jakékoli databázi nebo systému úložiště dat.

Metodologie

Vývojáři systému mohou nastavit mechanismy CDC mnoha způsoby a jakýmkoli způsobem nebo kombinací systémových vrstev od logiky aplikace až po fyzické úložiště.

Ve zjednodušeném kontextu CDC má jeden počítačový systém data, o nichž se předpokládá, že se změnily z předchozího časového bodu, a druhý počítačový systém musí přijmout opatření na základě těchto změněných dat. První je zdroj, druhý je cíl. Je možné, že zdroj a cíl jsou fyzicky stejný systém, ale to by logicky nezměnilo návrhový vzor. V jednom systému může existovat více řešení CDC.

Časová razítka na řádcích

Tabulky, jejichž změny musí být zachyceny, mohou mít sloupec, který představuje čas poslední změna. Názvy jako LAST_UPDATE atd. Jsou běžné. Jakýkoli řádek v jakékoli tabulce, který má v tomto sloupci časové razítko, které je novější než poslední čas, kdy byla data zachycena, se považuje za změněný.

Čísla verzí na řádcích

Návrháři databází dávají tabulkám, jejichž změny musí být zachyceny, sloupec obsahující číslo verze. Jména jako VERSION_NUMBER atd. Jsou běžná. Když se data v řádku změní, jeho číslo verze se aktualizuje na aktuální verzi. Je nutná podpůrná konstrukce, jako je referenční tabulka s aktuální verzí. Když dojde k zachycení změny, všechna data s číslem nejnovější verze se považují za změněná. Po dokončení zachycení změn se referenční tabulka aktualizuje o nové číslo verze.

Existují tři nebo čtyři hlavní techniky pro provádění CDC s čísly verzí,[je zapotřebí objasnění ] výše uvedený odstavec je pouze jeden.

Použijte při optimistickém zamykání

Čísla verzí mohou být užitečná pro optimistické zamykání v KYSELINA transakční nebo systémy pro správu relačních databází (RDBMS). Příklad ve scénářích pro čtení a aktualizaci pro CRUD aplikace v systémy pro správu relačních databází, nejprve se načte řádek spolu se stavem jeho čísla verze; v samostatné transakci, a AKTUALIZACE SQL příkaz je proveden spolu s dalším Klauzule WHERE který obsahuje číslo verze nalezené z počátečního čtení. Pokud nebyl aktualizován žádný záznam, obvykle to znamená, že se čísla verzí neshodovaly, protože nějaká jiná akce / transakce již aktualizovala řádek a následně číslo verze. Několik objektové relační mapování nástroje používají tuto metodu k detekci optimistických scénářů zamykání (včetně Přezimovat ).

Indikátory stavu na řádcích

Tato technika může buď doplnit nebo doplnit časová razítka a správu verzí. Může nakonfigurovat alternativu, pokud je například na řádku tabulky nastaven stavový sloupec označující, že se řádek změnil (např. Booleovský sloupec, který při nastavení na true znamená, že se řádek změnil). V opačném případě může fungovat jako doplněk k předchozím metodám, což naznačuje, že řádek, přestože má nové číslo verze nebo pozdější datum, by stále neměl být na cíli aktualizován (například data mohou vyžadovat ověření člověka).

Čas / Verze / Stav na řádcích

Tento přístup kombinuje tři dříve diskutované metody. Jak již bylo uvedeno, není neobvyklé vidět více řešení CDC v provozu v jednom systému, kombinace času, verze a stavu však poskytuje obzvláště výkonný mechanismus a programátoři by je měli využívat jako trio, kde je to možné. Tyto tři prvky nejsou nadbytečné ani nadbytečné. Jejich společné použití umožňuje logiku jako: „Zachyťte všechna data pro verzi 2.1, která se změnila mezi 1. 6. 2005 12:00 a 7. 1. 2005 12:00, kde stavový kód označuje, že je připraven k produkci.“

Spouštěče na stolech

Může zahrnovat a publikovat / přihlásit se k odběru vzor pro komunikaci změněných dat do více cílů. V tomto přístupu spouští protokolovat události, ke kterým dojde v transakční tabulce, do jiné tabulky front, kterou lze později „přehrát“. Představte si například tabulku účtů, když se transakce berou proti této tabulce, aktivují se spouštěče, které by pak ukládaly historii události nebo dokonce delty do samostatné tabulky front. Tabulka fronty může mít schéma s následujícími poli: Id, TableName, RowId, TimeStamp, Operation. Data vložená pro náš vzorek účtu mohou být: 1, Účty, 76, 11. 2. 2008 0:15, Aktualizace. Složitější návrhy mohou zaznamenávat skutečná data, která se změnila. Tuto tabulku front lze poté „přehrát“, aby se replikovala data ze zdrojového systému do cíle.

[Další diskuse je nutná]

Příkladem této techniky je vzor známý jako spoušť protokolu.

Programování událostí

Kódování změny do aplikace ve vhodných bodech je další metodou, která může inteligentně rozlišit, že se data změnila. Ačkoli tato metoda zahrnuje programování vs. snadněji implementované „hloupé“ spouštěče, může poskytnout přesnější a žádoucí CDC, například pouze po POVINNOSTI nebo až poté, co se určité sloupce změní na určité hodnoty - přesně to, co cílový systém hledá.

Skenery protokolů

Většina systémů pro správu databází spravuje a transakční protokol který zaznamenává změny provedené v obsahu databáze a v metadata. Skenováním a interpretací obsahu protokolu transakcí databáze je možné zachytit změny provedené v databázi nerušivým způsobem.

Použití protokolů transakcí pro sběr dat o změnách nabízí výzvu v tom, že struktura, obsah a použití protokolu transakcí jsou specifické pro systém správy databáze. Na rozdíl od přístupu k datům neexistuje žádný standard pro protokoly transakcí. Většina systémů pro správu databází nedokumentuje interní formát svých protokolů transakcí, i když některé poskytují programová rozhraní pro jejich protokoly transakcí (například: Oracle, DB2, SQL / MP, SQL / MX a SQL Server 2008).

Mezi další problémy při používání protokolů transakcí pro sběr dat o změnách patří:

  • Koordinace čtení protokolů transakcí a archivace souborů protokolu (software pro správu databáze obvykle archivuje soubory protokolu off-line pravidelně).
  • Překlad mezi formáty fyzického úložiště, které jsou zaznamenány v protokolech transakcí, a logickými formáty, které uživatelé databáze obvykle očekávají (např. Některé protokoly transakcí ukládají pouze minimální rozdíly ve vyrovnávací paměti, které nejsou přímo užitečné pro spotřebitele změn).
  • Řešení změn ve formátu protokolů transakcí mezi verzemi systému správy databáze.
  • Eliminace nepotvrzených změn, které databáze zapsala do protokolu transakcí a později stáhl se.
  • Řešení změn metadat tabulek v databázi.

Řešení CDC založená na souborech protokolu transakcí mají odlišné výhody, které zahrnují:

  • minimální dopad na databázi (ještě více, pokud někdo používá log doprava ke zpracování protokolů na vyhrazeném hostiteli).
  • není třeba programově měnit aplikace, které používají databázi.
  • nízký latence při získávání změn.
  • transakční integrita: skenování protokolů může vytvořit proud změn, který přehraje původní transakce v pořadí, v jakém byly potvrzeny. Takový proud změn zahrnuje změny provedené ve všech tabulkách účastnících se zachycené transakce.
  • není třeba měnit schéma databáze

Matoucí faktory

Jak se často vyskytuje ve složitých doménách, konečné řešení problému CDC možná bude muset vyvážit mnoho konkurenčních problémů.

Nevhodné zdrojové systémy

Změnit sběr dat jak zvyšuje složitost, tak snižuje hodnotu, pokud zdrojový systém uloží metadata se změní, když nebudou změněna samotná data. Například některé Datové modely sledovat uživatele, který se naposledy podíval, ale nezměnil data ve stejné struktuře jako data. Výsledkem je hluk v Change Data Capture.

Sledování zachycení

Sledování změn ve skutečnosti závisí na zdroji dat. Pokud jsou data přetrvává v moderní databáze pak Change Data Capture je jednoduchá záležitost oprávnění. Běžně se používají dvě techniky:

Pokud data nejsou v moderní databázi, stává se z CDC výzva programování.

Push versus pull

  • Tlačit: zdrojový proces vytváří snímek změn v rámci vlastního procesu a dodává řádky po proudu. Následný proces používá snímek, vytváří vlastní podmnožinu a dodává je do dalšího procesu.
  • Sem: cíl, který je bezprostředně po proudu od zdroje, připraví požadavek na data ze zdroje. Cíl po proudu poskytuje snímek k dalšímu cíli, jako v modelu push.

Alternativy

Pomalu se měnící dimenze (SDC) příklad modelu

Někdy pomalu se měnící dimenze se používá jako metoda.[1]

Viz také


Reference

  1. ^ Eroe, Erit (2015). 4ggg. Rty.

Viz také

externí odkazy