Zálohování stále se měnících velkých dat

[Exceptions]

Jde-li konkrétně o banky.

Ono to řešení není tak složité, složité je jen v detailech. Ukázkový příklad, Oracle DB nad replikovaným diskovým polem, replikovaný transakční log, na vstupu se každý požadavek ukládá do auditního logu. Transakce se nejprve uloží do interní fronty a poté se provedou změny v modelu. Vše se striktně spouští v db transakci.

To co tzv. Core (či Core banking system, CBS). Je to databáze a k tomu rozhraní, které se stará o transakce, klienty, účty, účetnictví, číselníky atd. Na Core databázi se zpravidla nikdo z venku (ani aplikace) nepřipojuje, vše se replikuje přes transakční log, který se čte. Core bývá fyzicky, síťově a administračně oddělen od zbytku infrastruktury.

České banky mají Core velký zpravidla několik TB velký, RTO se pohybuje v hodinách. Při obnově se zahodí datová složka, vezme se poslední snapshot/checkpoint a od něho se aplikují jednotlivé transakce z logu (jedna po druhé). To už psali předřečníci.

Naše banky mají zpravidla dvě aktivní lokality, kam se data rovnou replikují. Transakční a auditní logy z core putují na pásky se zpožděním pár desítek minut.

Vedle toho pak nezávislé stojí jiné databáze a datové sklady, které data dále zpracovávají, posílají, zobrazují klientům v bankovnictví, dělají reporty a výstupy do ČNB atd. Aplikací a systémů nad Corem pak může být i několik stovek a to jsou pak systémy, s kterými se potkávají běžní lidé a zaměstnanci. Často ale neobsahují primární data a mohu je obnovit z Core systému. Tam se data zálohují už daleko jednodušejí, snaphosty virtuálů, dumpy dat a vesměs to je věcí týmu, kterému to patří, aby udělal backup and restore implementaci. Obnova se čvičí několikrát ročně a některé banky to mají již plně zautomatizované.

Technicky se ale nedá zabránit všem druhům útoků, důležitou roli hraje dohledový tým a automatizace, která izoluje v případě problémů celé systémy, dohledové centrum funguje nonstop. Díky vysokému tlaku ČNB, jsou naše banky v tomhle hodně progresivní. To už se ale nedá říct o těch systémech nad tím, s kterými se větčina vývojářů a uživatelů setkává.

Kdyby někoho zajímal rozsah, v jednom z Corů vidím třeba 2 000 tabulek a celkově obsahují 300 000 sloupců. K transakcím se ukládají i atributy a metadata, tj. z jakých terminálů transakce vznikla, různé identifikace a seriová čísla, IP adresy, časové známky, podpisy atd. atd.

[Reklama]

[RDa]

Kdyby někoho zajímal rozsah, v jednom z Corů vidím třeba 2 000 tabulek a celkově obsahují 300 000 sloupců.

A pouziva se to prakticky vse, nebo je to spis dusledek nasazeni nakoupene technologie, ktera byla vytvorena nebo dokonvergovala do univerzalniho reseni, aby zadna zmena schematu v teto casti uz nikdy nebyla potreba (coz rozhodne usnadnuje aktualizace a snizuje moznosti problemu, kdyz jsou vse pouze data a samotna struktura se nemeni).

Nebo je tam i nejaka segmentace dat (sam jsem pouzival ve vykonnem vyhledavaci), to pak pocet klidne narust muze libovolne, a usnadnuje to pak paralelizaci, ono jeden stroj s naivnim schematem databaze bude mit chte nechte sve limity.

[darebacik]

V bankach je podla mna transakcia mala (predpokladam 10-ky bajtov).

Ohledně 10-tek bajtů bych byl dost opatrný, určitě to spíše bodou 100-ky, ne li 1000. Ono na transakci není jenom odkud jak a kolik, ale budou tam třeba různé symboly, měna, popis příkazce, popis příjmence. Nedejbože, aby ta transakce byla kartou nebo mezinárodní, to pak přibude spousta dalších atributů.
Jinak taková banka má transakcí miliony denně.

Dobre, ale furt su to len nejake znaky (pismena, cisla + nealfanumericke znaky). Aj keby to netrepali do databazy, tak v textakoch to nezabara vela. Samozrejme pri milionoch transakcii je tych dat viac.

A představovat-si, že data katastru jsou xml se souřadnicemi je podle mě také naivní. To kde parcely jsou je jenom malá část dat. Katastr hlavně vede majitele, celé zástavní smlouvy. Podle mě český eviduje i celé kupní smlouvy. Různé omezení o manilupaci - zástavní smlouvy,...

Samozrejme, ze mapy nie su vsetko, ale ide o to co vsekto potrebuju na katastri udrziavat. Mozno to robia sposobom, ze si zmluvy a podobne dokumenty skenuju, ukladaju do png, alebo pdf a potom pre jedneho zakaznika vytvoria aj 100 MB.

Zaujmal ma pricip backupu, kde sa hodne casto zapisuju do DB data. Neslo mi ani tak o velkost dat, ale velmi caste frekvenciie zapisov

[Exceptions]

Kdyby někoho zajímal rozsah, v jednom z Corů vidím třeba 2 000 tabulek a celkově obsahují 300 000 sloupců.

A pouziva se to prakticky vse, nebo je to spis dusledek nasazeni nakoupene technologie, ktera byla vytvorena nebo dokonvergovala do univerzalniho reseni, aby zadna zmena schematu v teto casti uz nikdy nebyla potreba (coz rozhodne usnadnuje aktualizace a snizuje moznosti problemu, kdyz jsou vse pouze data a samotna struktura se nemeni).

Nebo je tam i nejaka segmentace dat (sam jsem pouzival ve vykonnem vyhledavaci), to pak pocet klidne narust muze libovolne, a usnadnuje to pak paralelizaci, ono jeden stroj s naivnim schematem databaze bude mit chte nechte sve limity.

ty data jsou normalizovaná a modelovaná, s validací, datovými typy a vše co si přeješ, dělá se i migrace schémat a dat za provozu. Dokud vše bylo věcí mainframů, byly běžné noční odstávky, kde se dělala údržba, validace. Dnes se přechází na 24/7 provoz, často to běží na věcech jako Oracle Exadata a už potkáš u kubernetes v core infrastruktuře (koukám na to trochu nelibě, ale co).

Zpravidla je core výsledkem dodávky jedné společnosti, partnera nebo vlastní in-house vývoj, nebývá to mišmaš všeho, co koupíš, to jsou až ty vrstvy nad tím. Je tam hodně číselníků, třeba třetina. Každá banka to má jiné, když jsme migrovalii data při slučování bank, tak to jsou tisíce člověkodnů jenom na to, abys ty data propojil a spároval, ikdyž na druhé straně logicky musí být hodně podobné.

Ty systémy jsou rozsáhlé, protože i rozsah služeb a funkcí je vysoký. Třeba PSD2, to jsou desítky nových tabulek jen kvůli tomuhle. Změny se dělají pořád a příprava nových věcí se děje denně, nasazování je pak dána jen tím, jak to má banka vnitřně nastavené, některá je schopná změny dělat skoro denně, jiná si to nechá do velkého balíčku jednou za půl roku. Core nemusí být složen fyzicky z jediné databáze, ale častěji to je soustava několika databází a segmentuje se to.

Jsem architekt, do provozních dat tolik nevidím a ani mě nezajímají, zajímá mě jen jak to je postavené, navrhnuté a jak s tím dál. Stejně tak nemohu sdělovat příliš konkrétní data, protože nevím, co je zveřejnitelné a co ne. Zagoogli si, jestli tě to více zajímá, např. z Komerční banky o tom veřejně mluví Frantisek Kubala.

Zaujmal ma pricip backupu, kde sa hodne casto zapisuju do DB data. Neslo mi ani tak o velkost dat, ale velmi caste frekvenciie zapisov

Zálohují a schraňují se transakční logy, tj. záznam o tom, že proběhla nějaká změna v databázi (insert, update, změna schémat). Počet transakcí jen ovlivňuje to, jak je transakční log velký, jsou to append-only soubory. Stav v databázi je pak až materializace právě těch jednotlivých transakcí, hodně zápisu ti nevadí, vždy máš nějaký point in time (transaction id), ty jsou seřazeny v čase.

[jjrsk]

...potom pre jedneho zakaznika vytvoria aj 100 MB....

Ty ses opravdu velkej naivista, to ti nebude stacit ani na kadibudku. Stavebni urady kterych je katastr soucasti bezne pracuji s GB per jeden projekt.

Zaujmal ma pricip backupu, kde sa hodne casto zapisuju do DB data. Neslo mi ani tak o velkost dat, ale velmi caste frekvenciie zapisov

To je jen otazka vykonu a funkce penez. Proste kdyz mas na vstupu Gbit ... musis zvladat ten Gbit i odesilat. Pokud to nedelas kontinuelne ale jednou za cas, tak pochopitelne nasobne vic.

A pokud bys presah moznosti HW, coz se muze stat, tak proste musis ten provoz rozdelit na vice stroju. Zadna raketova veda.

[Reklama]