Blog | Co dělat, když mám starou aplikaci se spoustou dat v SQL?

Co dělat, když mám starou aplikaci se spoustou dat v SQL?

Máte starší aplikaci. V ní je obrovský objem dat o která nemůžete přijít. Jenže databáze má zastaralou strukturu a nechcete při přepisu aplikace dál přežívat se starou db strukturou. Navíc nemůžete aplikaci vypnout a změny v db v průběhu vývoje potřebujete dostat i do nové aplikace. A protože jste agilní, předpokládáte, že budou obě aplikace nějakou dobu koexistovat. Co dělat?

Máte několik možností:

  • datové pumpy
  • nová struktura jako view staré
  • stará struktura jako view nové
  • refactoring databáze
  • výměna modelu

Datová pumpa

Datová pumpa je nástroj, který umí jedno nebo oboustranně synchronizovat mezi různými databázemi. Můžete dokonce i přecházet mezi různými dodavateli databází.

Můžete použít existující nástroj, který obvykle umožňuje natahat si vztahy mezi různými datovými strukturami v obou databázích, přidat různé modifikátory apod. Výsledkem je, že pak stačí pustit pumpu a ona přelije data mezi databázemi.

Další možností je napsat si svou pumpu sám. Ať už tak, že postavíte nad db vrstvu něco, co bude odchytávat změny dat a synchronizovat je i v druhé databázi, nebo tak, že budete pomocí triggerů chytat změny a nalévat je do nové struktury (pozor, funguje obvykle jen pokud přecházíte na stejného dodavatele s jinou strukturou).

V závislosti na schopnosti synchronizovat obousměrně může být nová aplikace read only, nebo nemusí.

Nová struktura jako view staré

Další možností je vytvořit novou strukturu jako skupinu views staré struktury. Nová aplikace běží v read only módu, ale už používá novou datovou strukturu.

V okamžiku spuštění nové aplikace a vypnutí staré, jsou všechny view přetaveny v obyčejné tabulky a je to.

Některé databázové systémy umí za jistých podmínek insertovat do view, pak by bylo možné částečně i v době vývoje umožnit v části aplikace i zápis.

Stará struktura jako view nové

Druhý přístup je opačný. Jednorázově se přehrají data do nové struktury. Pro starou strukturu se připraví views. Stará aplikace běží jako read-only a zapisuje se v nové aplikaci.

Tento přístup bude asi nejvzácnější, protože u každé netriviální aplikace nějakou dobu trvá, než pokryjete všechna důležitá workflow.

Je možné kombinovat tento přístup s přístupem výše. Nejdřív je read-only nová aplikace, po určité době se přístup prohodí.

Refactoring databáze

Další možností je dělat refactoring databáze. Tento přístup je náročný v tom, že musíte upravovat jak starou, tak novou aplikaci. A pokud nemáte práci s db napsanou čistě, ale je (jak to u starých aplikací často bývá) rozesetá po celém kódu včetně view, nebude tento přístup vůbec levný.

Výhodou tohoto přístupu je, že obě verze aplikace mohou mít právo zápisu.

Výměna modelu

Poslední možnost, kterou jsem i přímo zažil (v kombinaci s datovými pumpami) při přepisu rozsáhlého informačního systému (vývoj, stejně jako přepis stál desítky člověkoroků) je to, že nová aplikace se napíše na starou strukturu. Vývojáři zároveň vyvíjí model i pro novou strukturu.

Na hranici modelu a controlleru, aplikace vystavuje Services, které nejsou vázané 1:1 na databázovou strukturu a vrací entity, které neodpovídají 1:1 řádkám v databázi.

Aplikace může zapisovat. Pumpa synchronizuje data do nové struktury jen pro potřeby vývoje a testování.

Ve staré aplikace části, které byly přepsány, se vypínají a části modelu se přepínají na novou strukturu (jsou-li data nesvázaná s jinými entitami) nebo zatím zůstávají ve staré (je-li potřeba se k datům doJOINovat).

Jasnou nevýhodou jsou 2 low-level části modelů, které musí mít stejné rozhraní.


Mimo soutěž si teď pohrávám ještě s jiným přístupem. Ten samozřejmě není aplikovatelný pro většinu aplikací. Jde o použití kombinace Apache Kafka a Apache Samza. V tomto přístupu ukládáte všechny eventy, které kdy změnily vaši databázi (to děláte v Kafce). A s pomocí Samzy vytváříte materializované pohledy na data (nepotřebujete cache, to, že data nejsou ve 3. normální formě nevadí). Když změníte struktury, stačí jen znovu přehrát celou historii a dostanete nová data. Víc je tento přístup popsán zde (článek doporučuju přečíst, je vynikající).

Pokud se dostanete do situace, že potřebujete novou datovou strukturu, do Samzy jen přidáte nové struktury, necháte je přegenerovat proti celé historii. A pak už chodící eventy se vám propisují do obou struktur. Tento přístup je nejlepší.

Akorát často vyžaduje, aby taková architektura byla v aplikaci od začátku. A objem eventů nesmí být tak velký, že není možné tato data uchovávat.

Programování

Předejte zkušenosti i dalším a sdílejte tento článek!

Předchozí článek
Následující článek


Jiří Knesl
Business & IT konzultant

Jiří Knesl poprvé začal programovat v roce 1993. Od té doby, díky skvělým učitelům a později zákazníkům, měl možnost neustále růst v oboru vývoje webových aplikací a informačních systémů. v roce 2002 se přidal zájem o ekonomii a v roce 2006 o organizaci práce. Vším tím se konstantně profesně zabývá jak ve svém podnikání, tak i u zákazníků. Za posledních 5 let vydal na tato témata přes 400 článků.

Prohlédněte si moje reference

Mám zkušenosti z rozsáhlých projektů pro korporace, velké podniky, střední i malé firmy, ale i pro startupy v cloudu. Zvyšoval jsem jejich know-how, pomáhal nastavovat jejich organizační strukturu, byl lektorem a mentorem v náročných situacích. Podívejte se, jak vidí můj přínos samotní klienti.

Sledujte mé postřehy na sociálních sítích