Když dotaz vázne, pomůže jen plán a indexy

Než začnete přepisovat dotaz, zjistěte, co databáze skutečně dělá. Většina problémů nevzniká kvůli syntaxi, ale kvůli tomu, že optimalizátor nemá k dispozici vhodné statistiky nebo indexy. Prvním krokem je spustit EXPLAIN (nebo EXPLAIN ANALYZE, pokud jej databáze podporuje) a přečíst plán. Sledujte, zda jde o sekvenční průchod celou tabulkou, kde se očekávalo hledání podle indexu, a jak zařídit malou kuchyniý je odhad počtu řádků proti skutečnosti. Rozdíl mezi odhadem a realitou je nejčastější příčina špatné volby joinu.

Konfiguraci uložte do repozitáře, ne do hlav Konfigurační soubory mají být součástí projektu a verzované spolu s kódem. Pokud nastavení žije jen v lokálním počítači, každý nový člověk ho musí objevit sám a každá změna se ztratí. Do repozitáře patří konfigurace nástrojů, soubor s verzemi závislostí a skripty pro běžné úkoly. Naopak citlivé údaje, přístupové klíče a cesty specifické pro konkrétní stroj tam nepatří. Ty se řeší přes proměnné prostředí a ukázkový soubor, který se do repozitáře přidá bez skutečných hodnot.

Pozor také na to, co vlastně testujete. Testovat privátní pomocné funkce nebo vnitřní implementaci vede k testům, které se rozbijí při každém refaktoringu, i když se chování navenek nezmění. Testujte rozhraní a výsledky, ne postup. A pokud používáte externí služby, nahraďte je v testech jednoduchými atrapami. Jinak budou testy pomalé a nespolehlivé. pytest k tomu nabízí monkeypatch a další nástroje, ale i prosté předání závislosti jako argumentu často stačí.

Image je neměnná šablona, kontejner je její běžící instance. Když spustíte příkaz docker run, Docker vytvoří kontejner z image. Pokud do kontejneru zapisujete data, po jeho smazání zmizí. To je častý šok: uživatel si uloží databázi do kontejneru, restartuje ho a data jsou v tahu. Řešením je takzvaný volume – připojení adresáře z hostitelského počítače do kontejneru. Data pak přežijí i smazání kontejneru. Stejně tak porty: aplikace uvnitř kontejneru poslouchá na nějakém portu, ale zvenčí se k ní nedostanete, dokud port nezveřejníte přes -p. Bez toho si budete marně klepat na localhost.

Kde lidé nejčastěji chybují Typická chyba je SELECT * v produkčním dotazu. Přenášíte sloupce, které nepotřebujete, bráníte pokrytí indexem a zvyšujete síťový provoz. Stejně problematické je vnořování dotazů do smyčky byt v paneláku aplikaci — místo jednoho dotazu s IN nebo JOIN odešlete stovky malých dotazů a režie na komunikaci převýší samotný výpočet. Další častý problém je implicitní přetypování: porovnáváte-li číselný sloupec s řetězcem, databáze může index ignorovat.

Typické chyby se opakují. Konfigurace se rozšíří o desítky voleb, kterým nikdo nerozumí. Nastavení se zdvojuje na více místech a při změně se jedno zapomene. Nástroje se aktualizují bez ohlášení a rozbijí běh u části týmu. Řešení je jednoduché: jedno místo pro každou oblast, změny procházejí stejnou kontrolou jako kód a každá úprava má popis, proč se děje. Nový člen týmu musí být schopen spustit projekt podle několika kroků a bez ptaní.

Nezapomínejte na statistiky. Databáze se rozhoduje podle nich a zastaralé údaje vedou k nesprávným plánům. Pravidelná aktualizace statistik, případně ruční údržba po velkých dávkových změnách, často zlepší výkon více než jakýkoli přepis dotazu. U transakcí držte je krátké, abyste neblokovali ostatní. A nakonec měřte: nasaďte sledování pomalých dotazů, porovnejte výsledky před a po změně a teprve pak měňte kód.

U spojení dávejte pozor na kartézské součiny. Pokud zapomenete podmínku v JOIN, výsledek může explodovat a server padne na spotřebě paměti. U agregací a řazení pomáhá omezit množství dat ještě před seskupením — filtr patří do WHERE, ne do HAVING, pokud nezávisí na agregované funkci. Při stránkování velkých výsledků se OFFSET chová špatně; pro velké posuny je vhodnější klíčové stránkování podle jednoznačného sloupce.

Nakonec si nastavte pravidelnou revizi. Jednou za čas projděte konfigurační soubory a zkontrolujte, zda všechny volby stále něco dělají. Odstraňte to, co se už nepoužívá, a sloučte to, co se překrývá. Sjednocená konfigurace není cíl, ale průběžná údržba. Když ji budete držet krátkou a srozumitelnou, tým přestane řešit prostředí a začne řešit skutečnou práci.

Když někdo tvrdí, že na úklid a dohledávání nemá čas, obvykle to znamená, že ho stráví stejně, jen neplánovaně a pod tlakem. Skrytá práce se nedá zrušit, pouze odložit. Proto je lepší ji přiznat v odhadu a mít rezervu, než ji tajit a slibovat nereálný termín. U složitějších úkolů se vyplatí rozdělit odhad na dvě čísla: dobu soustředěné práce a dobu čekání a režie. Tím se odhalí, kde vzniká největší nejistota.

If you have any issues regarding the place and how to use ProměNa Bytu, you can contact us at our web page.