Migrace na PostgreSQL, při níž se ztratí data? Tento krok to způsobí

Základem je unit testování. Testujte jednu logickou jednotku – funkci, metodu, třídu – bez databáze, sítě nebo souborového systému. Používejte testovací dvojníky (stubs, mocks) jen tam, kde je to nutné. Častá chyba: příliš mnoho mocků, které testují implementaci místo chování. Unit testy musí být rychlé, deterministické a nezávislé na sobě. Pokud jeden test potřebuje jiný, není to unit test. Držte se pravidla, že unit testy tvoří 70–80 % všech testů.

Pull request není jen místo pro schválení. Je to poslední šance odhalit chyby dřív, než se dostanou do hlavní větve. Nastavte si ochranu hlavní větve tak, aby vyžadovala alespoň jedno schválení a zelené testy. Do popisu pull requestu napište, co změna řeší a jak ji ověřit — recenzent pak nemusí hádat. Vyhněte se dvěma krajnostem: schvalování bez čtení a blokování kvůli stylistickým drobnostem, které patří do automatické kontroly.

Na co si dát pozor u datových typů a dotazů Zásadní rozdíl je v datových typech. MySQL je tolerantnější: například INT bez znaménka, TINYINT jako boolean nebo ENUM se v PostgreSQL chovají jinak. Datum 0000-00-00, které MySQL běžně přijme, PostgreSQL odmítne. Podobně řetězce s neplatnými znaky nebo prázdné hodnoty v číselných sloupcích. Před migrací je proto nutné data vyčistit a ověřit, že každý sloupec odpovídá cílovému typu. Nejedná se o formalitu – neplatná hodnota zastaví import celé tabulky.

Před samotným přenosem si připravte testovací prostředí se stejnou verzí PostgreSQL, jakou plánujete v provozu. Data exportujte po částech, ne jedním velkým souborem, a průběžně kontrolujte počty řádků a kontrolní součty u klíčových tabulek. Po importu ověřte cizí klíče, indexy a sekvence – u sekvencí je častou chybou, že začínají od jedné a kolidují s už vloženými hodnotami. Teprve potom spouštějte aplikaci.

Funkce drž krátké a zaměřené na jednu věc. Jakmile začne mít víc než tři úrovně vnoření nebo přes dvacet řádků, rozděl ji. Vyhýbej se přepínačům, které mění chování podle mnoha boolean parametrů — místo vytvor(true, false, true) použij objekt s pojmenovanými volbami nebo samostatné funkce. Častá chyba je také sdílený měnitelný stav: globální proměnná, kterou mění několik funkcí, se v praxi nechová předvídatelně. Preferuj návratové hodnoty a předávej data parametrem.

NoSQL není jedna technologie, ale skupina databází, které opouštějí pevné tabulky a cizí klíče. Místo toho ukládají data jako dokumenty, klíč-hodnota páry, široké sloupce nebo grafy. Každý typ řeší jiný problém: dokumentové databáze drží celý objekt pohromadě, klíč-hodnota slouží k bleskovému čtení podle identifikátoru, grafové databáze zvládají vztahy mezi entitami. Než začnete, položte si otázku, jestli vůbec potřebujete měnit přístup. Pokud data sedí v tabulkách a dotazy jsou rychlé, přechod jen přidá práci.

Nasazení NoSQL znamená i provozní změny. Musíte řešit replikaci, zálohování, monitoring a plánování kapacity. Některé databáze vyžadují ruční ladění komprese a indexů, jiné to zvládají samy. Testujte scénáře výpadku uzlu ještě před produkcí. Ověřte, jak se chová zápis při přetížení a jestli aplikace umí opakovat operace. Často se vyplatí začít s menším clusterem a růst po ověření. Kombinace relační a NoSQL databáze v jednom systému není slabost, ale běžná praxe.

Hlavní důvod, proč NoSQL vzniklo, je škálování a pružnost schématu. Relační databáze zvládne vertikální růst jen do určitého bodu, pak je potřeba rozdělit data na více strojů. Distribuované NoSQL databáze to dělají nativně, často pomocí shardingu a replikace. Druhý důvod je vývoj: když se struktura dat mění každý týden, migrace tabulek zdržuje. Dokumentové databáze umožní uložit různé verze objektu vedle sebe a aplikace si poradí s chybějícími poli. To je výhoda i past, protože bez kontroly schématu snadno vznikne nekonzistentní nepořádek.

Praktický postup je jednoduchý. Sepište si přístupové vzory: co se čte, jak často, podle čeho se filtruje a co se zapisuje. Zjistěte, jestli data porostou do stovek milionů záznamů a jestli musí být dostupná i při výpadku části clusteru. Pak zvolte typ databáze. Pro katalog produktů s různými atributy se hodí dokumentový model. Pro relace mezi uživateli, doporučení a sítě je přirozený graf. Pro čítače, cache a fronty zvolte klíč-hodnota. A pokud potřebujete analytiku přes mnoho dimenzí, NoSQL nemusí být správná odpověď.

Na co si dát pozor v praxi První chyba je zvolit NoSQL jen proto, že je moderní. U transakcí, kde potřebujete atomicitu přes více entit, je relační databáze stále bezpečnější volba. NoSQL transakce existují, ale mívají slabší záruky a složitější obsluhu. Druhá chyba je ignorovat modelování podle dotazů. V relační databázi navrhnete tabulky a dotazy přijdou později. U NoSQL je to obráceně: nejdřív zjistěte, jak se data budou číst, a podle toho navrhněte dokumenty nebo klíče. Třetí chyba je podcenit konzistenci. Distribuované systémy často volí dostupnost před okamžitou shodou, takže se můžete setkat s zastaralými daty. Pro platby nebo skladové zásoby je to nepřijatelné.