Veřejné registry jsou skvělé. A záludné.
Česko má na evropské poměry výborná otevřená data: ARES odpovídá bez registrace a bez API klíče, insolvenční rejstřík nabízí veřejnou webovou službu, katalog otevřených dat roste. Jenže dokumentace popisuje ideální svět a provoz vypadá jinak.
ARES má jediný publikovaný limit, 500 dotazů za minutu, a chování při překročení nikde popsané není. Hromadné vyhledávání bere nejvýš 100 IČO na dotaz. Takže když potřebujete denně obnovit tisíce subjektů, nezbývá než dávkovat, jet sériově a pečlivě si řídit pořadí: nejdřív subjekty, které jsme ještě nikdy netáhli, pak prioritní, pak zbytek podle stáří. Bez promyšleného pořadí se na nové záznamy nikdy nedostane — zastaralých s vyšší prioritou jsou desítky tisíc a spolknou celou dávku.
A některá data prostě neexistují. Zaniklé subjekty ARES maže úplně a statistický úřad k zaniklým fyzickým osobám ze zákona neposkytuje víc než IČO a datum zániku. Skoro půl milionu zaniklých subjektů v databázi proto zůstane beze jména — ne kvůli chybě, ale protože jména už nikde nejsou. Součástí řemesla je poznat, kdy přestat hledat.
Z 293 sekund na 0,26 milisekundy
Nejhezčí číslo projektu. Dávková aktualizace registrů si nejdřív vybírala prioritní subjekty poměrně přímočarým dotazem — který se na milionech řádků vyhodnocoval skoro pět minut, a to i tehdy, když nakonec nebylo co aktualizovat.
Řešení není žádná magie: příznak předpočítaný do vlastního sloupce, k tomu částečné indexy jen nad prioritními řádky a přepočet v dávkách po pěti tisících, aby dlouhá transakce nedržela zámky. Výběr pak trvá zlomek milisekundy. Cenná lekce byla i v detailu: jediné OR v podmínce dokáže databázi připravit o výhodu indexu. Dotaz, který vypadá skoro stejně, může běžet čtyřicet sekund, nebo okamžitě.
Obecné poučení: na milionech řádků se neplatí za funkce, ale za disciplínu. Každý dotaz v pozadí musí mít jasno, po čem jde a přes jaký index.
„Úspěšně dokončeno" ještě neznamená hotovo
Nejdražší chyby nebyly ty, které spadly, ale ty, které proběhly potichu špatně. Nástroj na databázové migrace umí za určitých okolností migraci tiše přeskočit — a přitom vypsat, že vše proběhlo úspěšně. Jednou se nám tak sloupec, o kterém aplikace byla přesvědčená, že existuje, v produkční databázi vůbec nevytvořil.
Od té doby platí pravidlo: po každé migraci se ověřuje skutečný stav databáze, ne výstup skriptu. A každá past, na kterou narazíme, se zapíše do pravidel projektu, aby ji ani člověk, ani AI agent nezopakoval. Přesně tenhle zápisník je mimochodem zdrojem tohoto článku.
Notifikace: nejtěžší je neposlat
Hlídač firem stojí na upozorněních — přibyl dluh, objevila se insolvence, změnil se jednatel. Technicky je to jednoduchá věc. Těžké je neposílat šum. První naplnění subjektu daty není změna. Doplnění dosud prázdného pole není změna. Hromadný import historických dat není tři sta tisíc změn za jednu noc.
Každý zdroj dat proto prochází stejnou úvahou: co je skutečná událost, kterou zákazník chce vidět, a co je jen pohyb dat na pozadí. Systém, který pošle upozornění včas a jen jednou, je výsledkem desítek takových malých rozhodnutí — a je to přesně ten druh práce, kde AI agenti pomáhají s implementací, ale rozhodnutí musí udělat člověk, který rozumí tomu, co zákazník od služby čeká.
Co si z toho bereme do dalších zakázek
- Napojení na registry plánovat podle reálných limitů, ne podle dokumentace. Dávkování, pořadí a rozpočet dotazů jsou součást návrhu, ne optimalizace na konec.
- Výkon řešit datovým modelem. Předpočítané příznaky a částečné indexy porazí chytrý dotaz pokaždé, když jde o miliony řádků.
- Nevěřit hlášení o úspěchu. Ověřovat skutečný stav — v databázi, v aplikaci, u zákazníka.
- Psát si provozní deník. Každá vyřešená past se zapíše do pravidel projektu. Podruhé už ji nikdo neřeší.
Celý příběh přepisu včetně čísel najdete v případové studii hlidacfirem.cz. A pokud provozujete systém, který podobnou péči potřebuje, napište nám.