NoSQL nezachrání špatný návrh dat, na který se zapomíná

Zapomeňte na to, že se agilní rituály dají dělat na dálku stejně jako naživo. Denní stand-up po videu je slabý odvar. Mnohem lepší je zavést dvě úrovně komunikace: krátký písemný update každé ráno a jednou týdně delší synchronizace se všemi. Písemný update nesmí být výčet činností, ale odpověď na tři otázky: co je hotové, co blokuje, co potřebuji od ostatních. Tím se předejde zbytečným schůzkám a zároveň vzniká dokumentace pro ty, kdo pracují v jiném čase.

Jak uspořádat první repozitář a nezbláznit se z toho Založení repozitáře je otázka jednoho příkazu. Poté je klíčové nastavit soubor .gitignore. Do něj patří všechno, co do historie nepatří: konfigurační soubory s hesly, lokální prostředí, složky s závislostmi nebo dočasné soubory. Častá chyba začátečníků je, že commitnou celý projekt včetně tajných klíčů. Pokud se to stane, je nutné klíč okamžitě zneplatnit a přepsat historii. Lepší je prevence: .gitignore vytvořit dříve než první commit.

Offsetové stránkování (?page=5&size=50) je jednoduché na implementaci i pochopení pro klienta. Problém je v tom, že databáze musí nejprve odskočit prvních N řádků a teprve pak vrátit výsledek. U stránky 10 000 to znamená načíst a zahodit statisíce řádků. Další komplikací je nestabilita: pokud mezi dvěma požadavky přibude nebo ubude záznam, klient uvidí duplicity nebo naopak položky přeskočí. Offset se hodí pro malé sady, administrační výpisy nebo tam, kde je potřeba skákat na konkrétní stránku.

Kde se to nejčastěji pokazí Typická chyba je přenést relační myšlení do dokumentů. Vývojář vytvoří kolekci zákazníků a kolekci objednávek, začne je spojovat ručně v aplikaci a diví se, že transakce nedrží pohromadě. U dokumentových databází se příbuzná data ukládají pohromadě, tedy objednávky uvnitř zákazníka, pokud je čteš spolu. Duplikace není hřích, je to vědomá daň za rychlost. Jen je nutné vědět, jak se duplikáty aktualizují, aby v systému nezůstaly dvě pravdy.

Rozhodování nezačíná u databáze, ale u dotazů. Sepiš si deset nejčastějších čtení a zápisů, které aplikace opravdu dělá, včetně jejich frekvence a požadavku na čerstvost dat. Teprve pak hledej model, který je zvládne bez složitých spojení. Dokumentová databáze se hodí, když čteš celek najednou – profil, objednávku, konfiguraci. Databáze klíč-hodnota poslouží pro cache, session nebo čítače. Grafová databáze má smysl, když dotazy procházejí mnoho vztahů do hloubky, například u doporučování. Sloupcová databáze zvládne obrovské objemy zápisů s předvídatelnými dotazy.

NoSQL se vyplatí, když roste objem dat nebo počet požadavků a relační databáze už naráží na limity jednoho serveru, když se schéma často mění a migrace jsou drahé, nebo když data přirozeně nemají tabulkovou podobu. Naopak zůstaň u relační databáze, pokud potřebuješ složité dotazy, agregace, silné transakce a data jsou menší než miliony řádků. Kombinace obojího je běžná a rozumná: relační databáze pro transakční jádro, NoSQL pro logy, vyhledávání nebo cache. Před nasazením zátěž otestuj, změř latenci a připrav plán, jak data exportovat, kdyby se řešení neosvědčilo.

Větve jsou dalším krokem. Nemusíte je používat od začátku, ale jakmile začnete pracovat na nové funkci nebo experimentu, větev se hodí. Vytvoříte ji příkazem branch, přepnete se na ni příkazem checkout. Hlavní větev zůstane stabilní a vy můžete zkoušet, aniž byste rozbili funkční verzi. Po dokončení větev sloučíte zpět. Typická chyba je zapomenout na větev přepnout a commitovat do hlavní větve omylem. Pomůže, když si před každou prací zkontrolujete, na jaké větvi jste.

NoSQL je souhrnné označení pro databáze, které se vzdávají pevného relačního schématu a tabulek propojených cizími klíči. Místo toho ukládají data jako dokumenty, klíč-hodnota páry, široké sloupce nebo grafy. Nejde o jednu technologii, ale o rodinu přístupů, které spojuje ochota obětovat část konzistence a dotazovacích možností výměnou za pružnost zápisu a horizontální škálování. Právě tady vzniká první past: lidé si myslí, že NoSQL znamená „bez pravidel". Ve skutečnosti znamená „pravidla si navrhneš sám" – a pokud je nenavrhneš, dostaneš nekonzistentní data, která se nedají opravit.

Základní práce začíná u Dockerfile. Každý příkaz vytváří vrstvu. Čím více vrstev, tím větší image a pomalejší build. Slouč příkazy pro instalaci balíčků do jednoho RUN a po instalaci vždy odstraň mezipaměť. Typická chyba je kopírování celého projektu před instalací závislostí. Tím se při každé změně kódu invaliduje cache a instalace běží znovu. Řešení je jednoduché: nejdřív zkopíruj soubor se závislostmi, nainstaluj je, a teprve potom zbytek kódu.