Vlákno názorů k článku
Sčítání lidu online mělo problémy, formulář by už měl fungovat, ale bývá přetížený (aktualizováno) od Petr Soukup - Já si vždycky říkám, proč podobné aplikace nenajíždějí...

Všechno jde, když víte, že to musíte ošetřit. Pro ten našeptávač by stačil dobře nadimenzovaný cluster elastic searche. Ale musíte vědět dopředu, že to je problém. Těch adres v ČR je tak málo, že se to vejde do pár GB možná i MB

U komplikovanějších systémů otestovat všechny aspekty dá stejně nebo možná víc práce než ten systém napsat. Ty systémy nejsou lineární, a bohužel málokdo se při testování dívá na zátěž komponent. Takže můžete udělat test s 200 uživateli, a může to fungovat, ale pokud se nepodíváte na CPU, tak neuvidíte, že vlastně už jste na hranici s výkonem, a s reálnou zátěží to fungovat nebude.

Lucene index pro našeptávání celých adres má na disku necelých 300 MB, pro našeptávání po částech by byl větší, ale ne řádově.

Ale nevím, zda v tomto případě zadání připouštělo mít tato data mimo hlavní databázi.

Abych pravdu řekl, nikdy by mne nenapadlo směrovat pro takovou aplikaci našeptávač vůči hlavní databázi. Finální ověření může být vůči cílové databázi, ale našeptávání pro potenciálně velkou zátěž by mělo jít na specializovanou dedikovanou databázi. Jinak si to fakt koleduje o malér. Našeptávání můžete přetížit, a nic se nestane. Pokud přetížíte cílovou databázi, tak končíte.

To řešíte technicky. Jenže do toho mluví také lidé, kteří mají na starosti bezpečnost, právníci s ochranou osobních údajů… Ale jak jsem psal, nevím, jak to bylo v tomhle případě.

U takové zátěže to nemůžete neřešit technicky. Chápu, že to musí být zabezpečené, ale v prvé řadě to musí být funkční. U velké zátěže technické ústupky nebo kompromisy mohou vyjít dost draho.

Chápu, že to musí být zabezpečené, ale v prvé řadě to musí být funkční.
Zkuste tohle říct před právníkem, který řeší ochranu osobních údajů, a pak nám povyprávějte, co se dělo, když ho vzkřísili…

Samozřejmě, že to musí být technicky funkční – jenom některá technicky dobrá řešení někdy není možné použít kvůli netechnickým požadavkům. Nevím, jestli to byl tenhle případ, ale těch netechnických požadavků tam bylo určitě spousta, protože požadavky na ochranu dat jsou v tomhle případě značné.

A tak v pripade komponenty naseptavace, ktery realne obsahuje jinak verejne dostupne udaje (aka RUIAN).... co konkretne je za bezpecnostni problem? Jestli tohle vsechno posilaji na tradicni SQL databazi (muzeme spekulovat, ale z ruznych vyjadreni to tak vypada), tak jim to logicky na hubu padat muze a bude - a pritom zcela zbytecne. Tam zadny problem tam z pohledu ochrany osobnich udaju nevidim, naopak tam cucham nevhodne technicke reseni.

Já neříkám, že v tomto případě tam je problém. Ale vím o případech, kdy data, která jsou legálně volně dostupná na internetu, musela být v systému uložena šifrovaně. Protože podle klasifikace dat spadla do kategorie, která musela být šifrovaná. Že je to nesmysl všichni věděli, ale nebyl to velký problém, takže nebyla motivace pustit se do byrokratického kolečka a vyjednat pro ta data výjimku.

Ono je nejsnazší něco odsoudit, když o tom člověk vůbec nic neví. Ale já nepotřebuju mít vše snadné, takže si stejně jako u dálničních známek nebo registrací na očkování dovolím ten luxus nedělat si názor v okamžiku, kdy o tom nic nevím, ale počkám si.

Vazne si budeme nalhavat, ze RUIAN data maji pro potreby naseptavace v databazi sifrovane? :D

Danny: Vidím, že si v diskusi vystačíte sám se sebou, protože úplně ignorujete, co jsem napsal.

Databáze RUIAN, u nás ji máme v MySQL, zabírá cca 450MB.

Myslím, že jdete s kanónem na vrabce. Adresní místa podle https://nahlizenidokn.cuzk.cz/StahniAdresniMistaRUIAN.aspx z celé ČR mají v zip archívu necelých 60 MB, dekomprimované necelých 350 MB a hodně informací mi tam z hlediska našeptávače připadá redundantní, takže to bude reálně určitě 50% nebo i méně z toho.

Konverze do UTF-8 lze udělat takto:
for f in *; do iconv -f ISO-8859-2 -t UTF-8 -o ../converted/$f $f; done

Hledání pomocí grepu např. "Vod" jako Vodičkova, trvá v tom výsledném datasetu na mém laptopu asi 0,1 sekundy takto hloupě nad textem (s výpisem do konzole by to bylo 1,1 sekundy)

Osobně bych nejdřív naivně jako programátor hodil ta relevantní data jako mapu seznamů map do Clojurového atomu s klíči podle počátečního písmena ulice, potom to klíč s městem a potom podle PSČ. Podle toho, co by uživatel zadal bych hledal v jedné z těchto map. Věřím, že by to bylo rychlé dost a pokud ne, tak bych tohle nějak optimalizoval pomocí vyhledávacích stromů nebo tak.

Jestli hledání bude v takové mapě seznamů map trvat milisekundu, tak to bude hodně. (Je to necelých 3 Mio. záznamů). Každý uživatel asi nebude potřebovat moc víc, než třeba 20 hledání. Takže třeba 20 ms na uživatele pokud by opravdu každý znak způsobil okamžité hledání. Při současných dejme tomu 250 000 spojení by to tedy bylo potřeba 5 000 sekund na obsloužení všech hledání současně - v jednom threadu. To je asi nepoužitelné. Na skromném serveru (v poměru ke sčítání lidu) o 8 jádrech by ale všechna hledání bylo možné uspokojit v rozmezí asi 10-15 minut. Nepřijde mi, že by se v rámci 15 minut na sčítání nahrnulo 2,5% populace ČR, ale muselo by se to změřit nebo třeba organizačně ošetřit.

Můj odhad je poměrně přesný, (počítejte zhruba 1/20 těchto časů, protože bych problém rozsekal podle počátečních písmen) a tohle je fakt nástřel tak, jak jsem to napsal, pracovalo by se se strukturovanými daty atd.:

(dotimes [_ 10] (time (dotimes [_ (* 3 1e6)] (str/includes? "Starý Jičín;33260;Du­b;č.p.;2;74101" "Vod"))))
"Elapsed time: 34.488828 msecs"
"Elapsed time: 30.82285 msecs"
"Elapsed time: 27.632666 msecs"
"Elapsed time: 27.926483 msecs"
"Elapsed time: 28.222405 msecs"
"Elapsed time: 27.998212 msecs"
"Elapsed time: 29.083514 msecs"
"Elapsed time: 28.84451 msecs"
"Elapsed time: 29.308315 msecs"
"Elapsed time: 29.250055 msecs"

Jak jsem psal, nejsou tam žádná překvapení, možná až na debilní kódování znaků podle ISO-8859 (hádám, že konkrétně ISO-8859-2) místo UTF-8.

Adam Kalisz: S kanónem na vrabce na to jdete vy. A to ještě bylo zadáním ulovit jelena. (Ten způsob hledání adres, co jste popsal, by totiž vůbec nefungoval).

Děkuji za odpověď, ale můžete psát prosím konkrétněji?

Potřebuju rychle vyhodit adresy, které určitě nejsou to, co občan hledá. Proto redukce podle prvního písmene - lidi asi ví, kde bydlí. Zbytek je buď hledání regexpem/ contains nebo něčím nad poměrně omezeným počtem (části) adres s tím, že třeba prvních 10 výsledků pošlu klientovi ke zvážení do našeptávače samozřejmě strukturovaně - držím si mapy těch polí, která jsou pro aplikaci důležitá.
Ano, můžu tam mít nějaký fuzzy search nebo tak, ale myslím, že u adres to není zase tak špatné, když kladu větší důraz na správně napsanou aspoň počáteční část ulice/ města nebo správné PSČ.

Rád se nechám překvapit, jestli nabídnete aspoň nějaký nástřel Vašeho řešení/ uvažování, které by podle Vás obstálo při zátěži dejme tomu 250 000 spojení.

Adam Kalisz: Na první problém byste narazil už při implementaci:
Podle toho, co by uživatel zadal bych hledal v jedné z těchto map.
Uživatel zadal „pra“. Budete to hledat v mapě ulic nebo v mapě obcí?

Na druhý problém byste narazil při testování. Třeba taková Vinohradská ulice v Praze má nějakých 230 domů, a to k ní přiléhají dva hřbitovy, tři náměstí a dva sady. To by vám uživatel poděkoval, vybírat to ručně, bez zadání domovního čísla. Ostatní vámi uvedené případy (obec a PSČ) mají typicky ještě daleko víc domů. Největší selektivitu má ulice a domovní číslo (zejména popisné), to vám ve většině případů dá pár výsledků.

Řešení není potřeba nastřelovat, protože řešení jsou hotová a dávno se používají – ve vláknu před vámi se o nich dokonce diskutuje. Adresa se vypíše ve formátu na řádek (tj. ulice a čísla, část obce, obec, PSČ), v místě mezer, čárek a lomítek se rozdělí na tokeny a vloží se do fulltextového indexu. Když řešíte jenom ty adresy, je ideální nějaký fulltextový index, třeba ElasticSearch nebo Solr. Škálování se pak řeší počtem instancí strojů s tím indexem. Když si s tím chcete dál hrát, můžete přidat třeba synonyma jako n. = nám. = náměstí.

Některá zadání ale mohou být komplikovanější, než jak jste ho napsal vy.

Žil jsem v přesvědčení, že ulice, obec, PSČ jsou tři různá políčka. Případně tam je i políčko na číslo domu. Žadatel může začít vyplňovat cokoliv z toho první a podle toho můžu zúžit výběr.

Možná je lepší takovou věc nechat třeba na tom Apache Solr nebo ElasticSearch (prostě Apache Lucene + něco navíc) ale kdybych měl tyto věci nasazovat jenom kvůli doplňování adres, tak mi přijde jako komplikace nad kterou třeba nemám dobrou kontrolu. Přesně z toho důvodu se třeba v OrgPadu spíše díváme směrem k LIKE nad PostgreSQL, ale to je ještě trochu hudba budoucnosti.
Podle mě je lepší mít méně komponent, které znám dobře a znám jejich chování v produkci, i když jsou na určitý use case třeba trochu slabší. Někdy je možná lepší napsat tu komponentu (obyčejně je to několik desítek řádků kódu na ten konkrétní úkol) sám a mít nad tím plnou kontrolu včetně třeba dobrých logů a metrik, než nasazovat projekt velikosti několik stovek tisíc řádků kódu, který má vlastní názor na konfiguraci, vlastní DSL na ovládání atd. Když zjistím, že moje komponenta nestačí, tak ji buď rozšířím/ zlepším a nebo zkusím zaintegrovat cizí. V tu dobu už mám ale zase víc zkušeností, třeba zjistím už, jaký je o to zájem/ zátěž komponenty apod.

Vždycky, když slyším "škálování se pak řeší počtem instancí strojů" u něčeho, jako je našeptávač k formulářové appce, tak si říkám, že je něco špatně. Jako nemám nic proti failover/ redundanci. Dnes se ale řeší až příliš věcí horizontálním škálováním s vysoce stoupající komplexitou místo aby se radši chvíli škálovalo vertikálně, než uvidím, že mi takové škálování stačit nebude. Možná to v tomto případě dává smysl, ale spíš si myslím, že by to měl nějaký tučnější i virtuální stroj utáhnout.

Očividně i OKSystems byli schopní chybu ještě ten den opravit nebo obejít projevy té chyby do dostatečné míry, tak to asi nebyla taková hrůza.

Tomu bych i věřil.

Zas poslanci to schvalují, ale ten zákon píše někdo jiný, typicky ministerstvo. Poslanci sice mohou podávat pozměňovací návrhy, ale jsem si skoro jistý, že to časové rozložení pochází od navrhovatele. A pokud to ministerstvo napíše bez konzultace s ČSÚ, tak je to jejich neschopnost.

Jenže i na ministerstvu i na ČSÚ to řeší hlavně právníci.

Kdyby se část těch právníků vyházelo, ještě by se ušetřilo a věci by mohli být jednodušší. To přece není až takový problém.

Kdyz je vyhodite, tak se vrati obloukem - to byste musel strilet, stejne jako ekonomy.

Vsechno ma byt v rovnovaze - technicka, ekonomicka i legislativni stranka. Jakmile se zacne jedna strana preferovat, tak je konec - v Boeingu by mohli vypravet, jak kvuli usporam a marketingu "usetrili".

LIKE na moderních databázích není problém, když tam dáte index. Ale zrovna na tohle je dělaný elastic a inmemory databáze. Pokud by to bylo napsané v Cčku, jedna mašina to musí utáhnout bez problémů.

jj souhlas - pokud to je dobře nakonfigurované. Já reaguji na tu oficiální zprávu, že jim tento modul pro našeptávání adres přetížil DB, takže to v důsledku nejelo jako celek. Těžko samozřejmě říct, do jaké míry mlží, ale trošku to vypadá tak, že to mají všechno narvané do jedné DB.

Těžko říct. Nemám přístup k neoficiálním informacím, a nevím vůbec nic, jak je to udělané. Z toho, co bylo zveřejněné, si nedokážu udělat vůbec žádnou představu. Možná použili jazyk pro laiky, možná mlží, ale v podstatě neřekli nic konkrétního. Ale je to možné. Pán Bůh ví na čem to běží a jak je to udělané.

A co taky FTS na PostgreSQL? ;-)

To asi nemají, když jim to nestíhá :-) Jinak co jsem zdálky sledoval pár statních zakázek (resp. ne pár, ale tři), tak tam se jelo Oracle nebo DB/2, protože prachy na to byly a nikdo nebrblal, že je to nějaký divný opensource (a samozřejmě by to ve všech třech případech, o kterých vím, PostgreSQL naprosto bez problémů ustíhala).

Nemusí to ani být Cčko, stačí jazyk, který má JIT kompilaci.

Je dobré vědět, že LIKE je v pohodě... nevidím u hodně věcí důvod duplikovat velkou část infrastruktury pro hledání, když už člověk databázi má. Vidím nějaké výhody v cache pro nejvýše zatíženou část, např. jak jsem nastínil výše s našeptávačem adres.

Nevidím důvod, proč by cokoliv z aplikačního kódu muselo být napsáno v C. Je pár lidí, kteří to umí a může to být bezpečné. Ten zbytek ať radši použije třeba Javu a ti osvícenější třeba Clojure... výkonu bude pořád ještě dostatek a nebo se v cloudu naklikne o facku větší server. Nemá smysl řešit něco na co nejvyšší efektivitu, když je to jednorázovka na sčítání lidu a za 10 let bude nejspíš úplně jiná technologie.

Záleží na zátěži - pro 10K přihlášených uživatelů na dnešních strojích nemusíte nic vymýšlet. Pro 100K přihlášených uživatelů to ani dnešní hw nemusí utáhnout, pokud by se objevil jakýkoliv problém. U předpokládané velké zátěže chcete dekompozici, navíc když se nabízí oddělit kritickou komponentu od nekritické, tak je hloupé to nevyužít.

A ty komponenty musíte mít na jiném železe. Můžete mít všechno perfektně vymyšlené, ale jedna nekritická a tudíž ne tak důkladně otestovaná komponenta vám utaví CPU, a jakmile se dostanete na 80% výkonu CPU, tak ten systém se může začít chovat nepredikovatelně - některé operace se silně zpomalí, začnou problémy s timeouty, mohou se vám objevit chyby na síťové úrovni. Věřte mi, že jsem tyto problémy viděl ne nejlepším železe, které můžete v cloudu mít.

Já udělám dotaz s LIKEM s trigramovým indexem za 2-5 ms i na velkých datech (pokud data budou v RAM). Na dedikované mašině s správným algoritmem máte garantováno, že data budete mít v RAM, a můžete se dostat na 10us. To třeba u napovídání výrazně zvyšuje uživatelský komfort. Pomalé napovídání tam nemusí být.

Efektivitu samozřejmě má smysl řešit - zvlášť u aplikací, které oslovují velký počet uživatelů a kde dopředu nevíte, jaká bude zátěž. První dojem je první dojem, a ostudu kterou utržíte už neodčiníte. Pokud máte relativně efektivní systém (není to realtime), tak můžete mít velkou rezervu v hw, a lépe překonáte případný problémy. Bez výkonnostní rezervy vás i malá prkotina rozhodí.

Ty mašiny mají brutální výkon - ale roste komplexnost aplikací (používají se komponenty, o kterých pouze předpokládáte, že se nějak chovají), a klesá technická zdatnost a odbornost vývojářů - a ty aplikace jsou hodně pomalé. Jako školitel i jako konzultant potkávám hodně vývojářů, a se znalostmi technologie je to čím dál tím horší. Pokud si ti vývojáři plavou ve svém rybníku, a píší aplikace na které jsou zvyklí, tak se to odehrává relativně bez průserů. Aplikace jsou sice pomalé, ale všichni si zvykli. Pokud se potkají s něčím novým, a problémem, tak nemají tušení, co se děje, a co je špatně. Problém je, že hw výkon ani neroste lineárně - a náročnost některých algoritmů, úloh může být exponenciální.

Jako u velkých systémů apod. určitě máte minimálně z pohledu DB mnohem větší zkušenosti než já. Fakt se mi ale nezdá, že by na sčítání lidu nemohl stačit stroj typu m6g.metal (64 jader Graviton 2, 256 GB RAM, 2 x 1900 NVMe SSD) za 5500 $ na dva měsíce, dejme tomu, že pro redundanci tam bude ještě jeden v hot-standby a taky se zaplatí za traffic apod. Myslím, že ~ 20 000 $ za ty dva měsíce by mohly stačit. To je ani ne půl milionu korun - ano, to je hodně peněz. Za tým rozumných 3-4 inženýrů v Praze dám ale za měsíc jako firma asi víc.

Možná by stačilo několik strojů CCX51 u Hetznera za ~ 330 € na měsíc (32 dedikovaných vCPU, 128 GB RAM, 600 GB NVMe SSD + pár TB SSD block storage (50 €/ TB/ měsíc)). Prostě ty stroje jsou fakt strašná děla na formulářovou appku.

Pokud máte nějaký konkrétnější příklad, kde by 100 000 spojení "tavilo" servery, tak sem s ním. U formuláře, klidně i s našeptávačem, to ale podle mě bude spíše nezajímavá zátěž.

Ve špičce jste schopný takovou mašinu utavit. To není problém - několik neoptimálních dotazů vykonávaných paralelně v 400 procesech vám vyžere veškerý výkon. Není problém mít dotaz 500 ms a po úpravách a přidání správných indexů tentýž dotaz má 5 ms (na 100GB databázi a data jsou v RAM). 64 core takových dotazů zvládne 120 za sec (zvládnete obsloužit 200 uživatelů za sec - ale ve frontě jich máte 1000).

Samozřejmě, že když se ta aplikace vyladí, tak nepotřebujete ani desetinový stroj, a ještě budete mít rezervu. Jenže na to vyladění potřebujete určitý čas v režimu hodně podobném provozu. Napsat složitější aplikaci, která funguje na první dobrou je velice drahá záležitost - jsou provozy, kde to je nutné, a náklady jsou 10x až 100x větší než u běžných komerčních aplikací (jaderná energetika, letectví, ..).

Vemte si automobilový sport - tam na vyladění konkrétního vozu potřebujete odjezdit závodně jednu sezónu - a nikomu to nepřijde divné. Jenom v IT se očekávají snad zázraky, a čeká se, že aplikace poběží od 1 minuty na plný výkon - přičemž dopředu neznáte a ani nemůžete znát zátěž. A co se týká software, tak to je mnohem větší hromada sraček než to, s čím se musí potýkat strojaři a konstruktéři. Máte nad sebou desítky vrstev, desítky různých heuristik a optimalizací, a nikdo nemůže seriózně říct, jak se to bude chovat pod skutečnou zátěží.

Bohužel, ke všem problémům, kam se dostanu, podepisuji NDA, takže nesmím sdělovat detaily. I 100K uživatelů by se za normálních okolností mělo nějak rozumně rozprostřít v čase. Nicméně, když máte někde nějaké úzké hrdlo nebo například zámek, který uživatele sesynchronizuje, tak mohou udělat velký tlak na některé komponenty. Pokud je možné použít fronty, tak se vám requesty naštosují do front, což je ook, může ale dojít k timeoutům, a k lagování. Pokud nemáte fronty, a otevřete příliš mnoho vláken nebo procesů, tak vám mohou CPU vyžrat zámky (spinlocky) nebo context switch a průchodnost celého systému dramaticky klesne - o několik řádů.

Na databázích je hodně hezky vidět nelineární chování - do určitého násobku počtu paralelně vykonávaných dotazů vůči CPU cores se roste výkon databáze. Pak stagnuje, a pak dramaticky klesá. Bohužel v praxi se ukazuje, že je dost těžké odhadnout jaká bude zátěž, a je to těžké i nasimulovat. Třeba i proto, že to drahé železo z brutálním výkonem máte jen jedno, a rozhodně vám nikdo nekoupí druhé pro testy. Další problém je, že těch opravdových špiček je málo, a nemáte moc příležitostí vidět systém při extrémní zátěži. Navíc dost problémů je způsobeno souhrou určitých faktorů - od úplně pitomého návrhu, přes problémy s virtualizací, problémů s výkonem hw, špatné diagnostiky. Většina problémů s kterými jsem se setkal jsou a byly řešitelné. Ale potřebujete čas na to aby se projevily, abyste je mohl identifikovat, a aby se daly opravit.

Díky moc za výživnou odpověď.

Ano, za něco přes rok jsme měli přesně jeden dotaz nad PostgreSQL, který byl problematický a nevíme přesně proč:


-- :name get-shared-orgpages :? :*
-- :doc gets all orgpages shared with a given user
SELECT orgpages.id, orgpages.val, orgpages.owner, permissions_to­ken.token FROM orgpages
INNER JOIN permissions ON orgpages.id=per­missions.resou­rce
INNER JOIN permissions AS permissions_token ON orgpages.id=per­missions.resou­rce
WHERE permissions.user_id = :user AND permissions_to­ken.token IS NOT NULL AND permissions_to­ken.permission = 'V'


Tohle je nyní v pohodě:


-- :name get-shared-orgpages :? :*
-- :doc gets all orgpages shared with a given user
-- We are using inner query because joining two permission tables at the same
-- moment causes the server CPU usage to blow up. Unsure why.
SELECT orgpages.id, orgpages.val, orgpages.owner, permissions.token FROM (
SELECT * FROM orgpages
INNER JOIN permissions ON orgpages.id=per­missions.resou­rce
WHERE permissions.user_id = :user
) AS orgpages
INNER JOIN permissions ON orgpages.id=per­missions.resou­rce
WHERE permissions.token IS NOT NULL AND permissions.per­mission = 'V'


V podstatě je tohle jediné místo, kde je něco jako "unsure" v komentáři. Ano, v Clojure apod. jsou taky určité pasti/ méně očividná místa, kde by něco mohlo vybouchnout, ale je jich fakt hodně málo a obyčejně jsou dost známá. Mám pocit ještě z předchozí práce, že ale s SQL přeci jen bojuje víc lidí.

Máte tip na nějaké dobré knihy/ jiné materiály, které byste doporučil programátorům a administrátorům SQL, klidně s větším ohledem na PostgreSQL? Mám pocit, že buď jsou obecně o SQL se skoro nulovým vhledem do konkrétní implementace z administrátorského hlediska (nebo je to o MySQL, Oracle, MSSQL) a nebo jsou to špeky pro ty servery s 100k+ spojeními, o kterých se bavíme. Možná je taky prostě psát čtivé a přitom výkonné SQL těžké.

S SQL bojuje víc lidí, protože jim chybí absolutní základy, a vůbec netuší, jak SQL databáze fungují - a přitom je to docela snadné.

Dobrá je knížka https://use-the-index-luke.com/ a ta je hodně útlá. Kdysi jsem jí recenzoval na rootu. Četl jsem chválu na https://theartofpostgresql.com/ - autor umí psát a perfektně rozumí Postgresu (a pár důležitých věcí do pg napsal).

Jinak k Postgresu - podívejte se na český web a přečtete si alespoň Desatero

https://postgres.cz/wiki/Desatero

případně volně dostupné podklady k mým školením https://postgres.cz/wiki/%C5%A0kolen%C3%AD

permissions_to­ken.token IS NOT NULL AND permissions_to­ken.permission = 'V'

Tam budete mít patrně silnou závislost mezi sloupci, tudíž je možné, že tam podstřelují odhady a padá to do nested loopu - základ je podívat se na EXPLAIN ANALYZE - a zkontrolovat odhady. Řešením bývá buďto vícesloupcový index nebo podmíněný index - střílím to od stolu CREATE INDEX ON permission_to­ken(perminssi­on) WHERE permission_to­ken.token IS NOT NULL

Moc děkuji za materiály a radu.

To desatero vypadá, že je místy poměrně aktuální, jinde ale mluví o PSQL řad 7, 8 a 9. Nejsem si jistý, jestli tyto připomínky platí i u PSQL 12, 13 apod. a nebo to je již jinak. (Asi není potřeba na toto odpovídat, určitě si ještě během následujících týdnů a měsíců desatero projdu vícekrát.)

To desatero se postupně vyvíjelo, - tak jak se vyvíjel Postgres a jak já jsem získával zkušenosti s Postgresem. Snažím se to udržovat aktuální. Ty fundamenty Postgresu se moc nemění - MVCC je v Postgresu +/- stejné 20 let. Zlepšuje se výkon - zlepšuje se chování na aktuálním železu, ale na druhou stranu dost se zvedá velikost dat - dnes 100GB databáze už je skoro běžná záležitost a není to díky blobům, a klesá obecný přehled vývojářů, což je daň za specializaci. Dřív chca nechca se aplikace musela podřídit databázi - jinak to nefungovalo. Dneska se už dá databáze znásilnit.

Když jsem před 25 roky začínal, tak člověk byl prostě programátor (nerozlišoval se jazyk, nerozlišoval se backend/frontend - ani to tehdy na PC neexistovalo) - a skoro se dalo rozumět všemu. To už dneska moc nejde.

S tou specializací máte pravdu. Problémem také je, že je prakticky všechno přesložitěné. Od webu po assembler je prakticky všude konzistentní jen to, že jsou věci nekonzistentní :-) a možná zbytečně složité.
To, co by mělo poskytovat robustní základ poskytuje spíše takové lešení. Programátoři a administrátoři se točí kolem nedodělků a ztrácí čas podružnostmi, které by ve spoustě případů mohl vyřešit program/ počítač automaticky a neotravovat.

Mimochodem PostgreSQL není úplně výjimkou. Je v něm několik věcí, při kterých musím prakticky server odstavit, protože se změnilo nějaké nastavení, přidal modul nebo tak něco, sám to určitě víte mnohem lépe kde všude a co všechno nejde dělat při produkčním použití a je potřeba údržba. Nevím, jak moc se vývojáři zamýšlí nad tím, jestli by nešlo náhodou více těchto zásahů řešit za běhu včetně třeba aktualizace/ upgrade serveru. Přechod mezi verzemi by tak byl nejspíš mnohem hladší.

Jinak jsou místa, kde si člověk ještě šáhne na všechno od frontendu a financí až po backend a administraci serverů. Jsou to typicky malé startupy, kde prostě musí všichni umět do jisté míry všechno. Ano, i zde je specializace, ale často umí programovat jak CEO tak CTO a CFO, CTO obyčejně s odstupem nejlépe. CEO by ale podle dokumentace uměl asi v případě nějaké nehody třeba po telefonu s CTO rozjet produkci. Bylo by to vyčerpávající, ale kdyby nic jiného nezbývalo, tak by to asi zvládl.
Všechno tohle jde aspoň po nějaký čas typicky na úkor osobního života... to je holt podnikání (taky nejspíš znáte dobře).

Postgres byla databáze pro fabriky, univerzity a státní instituce, kde se nejelo 24x7. To, že dnes se v tomto módu používá neznamená, že je pro to psaná. Na druhou stranu, co se bavím se zákazníky, tak vždy mají nějaké servisní okno. A zase díky architektuře postgres je držák. Hromada vlastností vychází z možností přelomu 80/90 let, kdy Postgres vznikal, a kdy jste se snažili využít výkon železa do maxima. A je to také dáno možnostmi komunity, která na vývoj nemá tolik prostředků, jako komerčního sw (i když vývoj je dnes dobře zajištěný). Až cca 10 let zpátky byl Postgres čistě hobby projekt.

Samozřejmě, že vývojáři se hodně zamýšlejí nad údržbou - ale jde o kompromis mezi složitostí vývoje, údržby, používání, výkonem. Nemůže být všechno. Něco je dáno architekturou (založenou na procesech) - a vlastnostmi sdílené paměti v operačním systému. Pokud chcete stejnou adresaci sdílené paměti, tak ji musíte alokovat pouze při startu. Ale to je minimum extenzí. Většinu extenzí můžete bez problémů přidat a odebrat bez restartu. Zase dost adminů ten Postgres restartuje zbytečně, protože netuší, co potřebuje restart a na co stačí reload. A co vidím, tak i admini, kteří používají Postgres roky a považují se za seniory nemají ani základní znalosti. A bez znalostí je všechno těžké.

Já abych se dostal na nějaký level, tak jsem 10 let nedělal nic jiného. Platí pravidlo 10 000 hodin, aby se člověk dostal na expertní úroveň. Znalosti a zkušenosti samy od sebe nepřijdou. Člověk jim musí jít naproti. Na běžných projektech se člověk tady nic moc nenaučí, je to taková navoněná bída (a v cizině je totéž - technologicky zdatných firem je málo - ale jedině tam se člověk něco naučí). Teprve když jsem se nachomýtl k vývoji Postgresu, a začal dělat i support a řešit nejen svoje problémy, tak se člověk mnohem rychleji posouvá.

LIKE je v pohodě, ale musíte mít správnou databázi, a správný index. Jinak v pohodně není, a na větších datech a při větší zátěži vám může bezproblémově vyžrat CPU - je to jedna na CPU z nejnáročnějších operací.

Všechno jde, když o tom problému víte. Dost katastrof, problémů a chyb byla způsobena přehlédnutím opomenutím v nějaké nekritické komponentě.

Jinak data se sbírají i když už je máte - říká se tomu chtěná redundance. Ta data si potřebujete ověřit.

> Jiný kolega zde v diskuzi měl také pravdu, že všechna potřebná data stát již má v mnohem lepší kvalitě z různých úkonů se státní správou.

Nezapomínejte, že ve společnosti jsou - za mne oprávněné - obavy ze spojování databází ve státní správě.

Proto radši sčítání lidu jednou za deset let, než online provázání do detailu ...

Tohle je separátní téma, jestli stát potřebuje na všechno informace, jestli nestačí nějaký statistický souhrn (který anonymizuje) apod.
Tady šlo čistě o to, že státní zaměstnanci si ulehčují práci, protože prostě zadají plošné sčítání místo aby si data posháněli z jednotlivých úřadů. Nikdo neříká, že by potom tyto úřady mohly resp. měly moct jen tak ke všem těmto datům přistupovat. Další výhodu by mělo, že kdyby se potil ČSÚ se všemi úřady, možná by byl větší tlak mít data v nějakém rozumném, konzistentním formátu a z toho by vyplývalo mít možná od ČSÚ nebo jiných orgánů odpovídající nástroje.

Na druhou stranu po zkušenosti s vyplňováním statistiky o nově vzniknuvší firmě ve formuláři ČSÚ je možná jediná realistická varianta zůstat u toho plošného sčítání a radši po nich nic nechtít. UX tam byl absolutně otřesný, formulace dotazů byla horší než kdyby člověk četl nějaký obskurní zákon. Hlavně ale musí otravovat subjekty, které mají plnou hlavu jiných věcí.

Počkat, v které "státní" databázi je informace o tom, kolik v kterém bytě bydlí konkrétních lidí, jaké mají vzdělání, kam, čím a jak často dojíždí apod.?

Adam Kalisz:
– Občan ČR: Nebudu si měnit trvalé bydliště, stát to nepotřebuje vědět, počty obyvatel přece zná ze sčítání.
– Tentýž občan ČR: Proč musím ve sčítání uvádět bydliště, vždyť ho stát eviduje v evidenci obyvatel.

Sčítání se dělá právě proto, aby se podchytily i ty případy, kdy má stát v registrech špatná nebo žádná data. To, že se stejná data sbírají různými způsoby, je běžné – je to známý způsob, jak předcházet chybám a systematickému zkreslení. Je možné, že si jednou řekneme, že ta existující data už jsou tak dobrá, že sčítání nepotřebujeme – ale asi to zatím není případ ČR. Ale zrovna evidence obyvatel před sebou podle mě má ještě dlouhou cestu.

Kdepak. Stát tohle vědět (přesně) nepotřebuje. A i kdyby čistě náhodou potřeboval, nemá komu co rozkazovat, aby mu, navíc zadarmo a ve svém volném čase, něco jen tak zbůhdarma vyplňoval. Stát tady má být pro to, aby lidem sloužil, ne naopak.

bez přezdívky: Aby stát lidem mohl sloužit, potřebuje k tomu mít informace. Sčítání se provádí na celém světě a je jen málo států, kde už berou data jenom z existujících evidencí.

Na základně dat ze sčítání se stejně nic rozhodovat nedá, ty příklady od ČSU jsou něco mezi vtipem a fanfiction.

Nestanovují se na základě toho náhodou třeba senátní volební obvody? Také jsou to informace o migraci, třeba zda a jak se vylidňuje venkov, zda se lidé stěhují do větších měst nebo rovnou do Prahy apod. Že si Praha udělá odhad na základě mobilů je hezké, ale není to zjištěné pro celou ČR a nepozná se z toho, odkud do Prahy ti lidé přicházejí.