Já si vždycky říkám, proč podobné aplikace nenajíždějí postupně? Mohli to přece v tichosti otevřít několik dní před oficiálním termínem a odladit si to v testovacím provozu - stačilo by třeba nechat možnost si formulář předvyplnit a uložit, nápor by se tak zvyšoval postupně a měli by více času to vyladit. To oni né, oni raději budou s ostudou pracovat celý víkend.
Ještě více se to hodilo u registrací k očkování, kdy to měli otevírat postupně pro jednotlivé ročníky. Metoda kdo dřív přijde, ten se dřív očkuje, zcela jasně musí vést k totálnímu přetížení a kolapsu, to byla naprostá jistota.
Kolik že tato aplikace stála miliard?
Sčítání lidu mohla být hodně pokroková věc za Marie Terezie, nyní už je to jen činnost ze setrvačnosti a způsob jak rozhazovat další peníze. I když už za Marie Terezie byla jednou z hlavních motivací výběr daní a odvod do armády.
Zrovna dneska ráno jsem při čtení novin uvažoval, že kdyby tohle rozjeli v Azure, nemusel být žádný problém, nastavíte si automatické škálování, pár front, na pozadí třeba tu jejich slavnou cosmosdb a je hotovo. Více méně je to jen formulář, kde zadáte údaje a ty uložíte a maximálně to ověří jestli jste to už nevyplnili, ale pak jsem uvažoval, dál a více méně nejbližší region je k nám asi West Europe, takže 90% lidí bude spojení tranzitovat mimo ČR, takže to asi v Azure nebude. A ejhle najednou se zjistí, že to tam opravdu je...
Tak pry to zabili naseptavacem adres. Tedy dost pravdepodobne hodne busili selecty do na tento ucel neoptimalizovane tradicni SQL databaze. A v dusledku stacilo par tisic lidi, aby to cele polozili. Ocividne kvalitne provedene zatezove testy, kdyz neodhali slabinu v komponente, ktera bude dost 'na rane'.
Navíc je to ještě v napovídači adres (jestli ty zveřejněné údaje jsou ok). Klasika - interaktivní záležitost, která se špatně testuje, a navíc může utavit jinou komponentu.
Jediné jak by se tomu dalo předejít by bylo masivnější testování - a možná chytřejším návrhem - ale to se nedá uhlídat - v době, kdy se používají komponenty, a nikdo pořádně neví, co komponenta dělá uvnitř.
Takových chyb je mraky - u nekritického sw se tomu s dnešní komplexitou nedá zabránit. Co je problém, a nechápu, že se nedokáží poučit, je start projektu metodou velkého třesku z nuly naráz na 100%.
U takových chyb si škálováním nepomůžete. Ty systémy se nechovají lineárně - museli byste umět horizontálně škálovat na všech komponentách, a to je pouze vlhký sen. Jedna neoptimální komponenta může utavit CPU, utavit síťové prvky, monitoring. Tady pomůže jen správné řízení projektu, které nekončí předáním projektu, ale počítá ještě s náběhem projektu do plného provozu.
Připomíná mi to jednu firmu, kde měli hodně kritické performance problémy. Když jsem se jich ptal, jak testovali zátěž aplikace pro zhruba 20K aktivních uživatelů, tak mi bylo řečeno, že celá firma (cca 30 lidí) si naráz sedla a proklikala aplikaci.
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.
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.
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.
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;Dub;č.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.
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.
Start je daný zákonem. Mezi lidmi z IT, které napadne, že start velkým třeskem není dobrý nápad, a poslanci, kteří ten zákon schvalují, je strašně moc mezičlánků. Navíc lidi, kteří ten start budou řešit, se k tomu dostanou typicky až po té, co už je zákon schválen. Takže by to znamenalo předložit novelu, ta by musela projít Parlamentem. Navíc v téhle době, kdy Parlament nezvládá řešit ani věci související s Covidem. To je nereálné, bohužel.
Tak bohužel zdrojáky asi neuvidíme (takže nezištnou pomoc od ajťáků nedostanou) ale pokud skutečně na každý KeyUp při zadávání adresy posílali přes AJAX dotaz a nějak ho vyhodnocovali pomocí LIKE, tak to je hodně overkill (navíc to asi má smysl posílat po třech a více písmenech, ne dřív).
Snad to všechno nenacpali do jedné nenaškálované 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é.
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).
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_token.token FROM orgpages
INNER JOIN permissions ON orgpages.id=permissions.resource
INNER JOIN permissions AS permissions_token ON orgpages.id=permissions.resource
WHERE permissions.user_id = :user AND permissions_token.token IS NOT NULL AND permissions_token.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=permissions.resource
WHERE permissions.user_id = :user
) AS orgpages
INNER JOIN permissions ON orgpages.id=permissions.resource
WHERE permissions.token IS NOT NULL AND permissions.permission = '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_token.token IS NOT NULL AND permissions_token.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_token(perminssion) WHERE permission_token.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á.
Interaktivní věci není nutně tak těžké testovat. Rozhodně ne pitomý našeptávač... což bych nejspíš rozchodil na prakticky libovolně špatné webovce za odpoledne. Tady si ale oni systém navrhovali sami. Vygenerovat si ze začátku bydlišť (což je dostatečně podobné reálné zátěži) nějakou sadu řetězců, které pustím proti databázi je hodně podobná věc a dá se to měřit fakt jednoduše.
Jinak tohle je typická chyba špatného návrhu, pokud by to šlo proti nějaké SQL databázi. Adresy se mi během sčítání asi nezmění, to znamená, že je to read-only. Všechny adresy v Čr budou mít pár MB dohromady. Tohle se dá držet klidně v aplikačním serveru, do kterého se to hned po startu aplikace načte jako nějaký hledací strom/ množina nebo něco a hledá se v tom. Alternativně se dá použít něco jako Redis... asi není potřeba na tohle nasazovat Solr nebo ElasticSearch.
Jako všech 170 000 lidí asi najednou nevyplňuje adresy a i kdyby, tak mnou popisované řešení škáluje horizontálně bez problému s počtem aplikačních serverů.
Nejsem si jistý, ale pokud v dnešní době jakékoliv sčítání lidu utaví síťové prvky nebo monitoring tak asi děláme něco špatně. Jako 170 000 současných spojení by asi šlo řešit jedním serverem, který by ani nemusel být za load-balancerem, kdyby se tam necpaly nesmysly. Nakonec je to záležitost asi na měsíc nebo dva a potom se to dá zase vypnout nebo zmenšit na minimum... ideál pro cloud.
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. Takovéto explicitní sčítání lidu je v roce 2021 s velkou pravděpodobností mimo mísu. Musíme se tedy ptát, proč se ještě realizuje a kdo je zodpovědný za to, že se systém ještě neupravil, aby méně otravoval občana.
> 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í.
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.
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í.
@PQK
Nezapomínejte, že ve společnosti jsou - za mne oprávněné - obavy ze spojování databází ve státní správě.
Jestli problém není jinde, protože spojení databází se nabízí jako správná varianta z pohledu systému. Možná to bude tím, že stát toho "ví" a organizuje až moc a to ještě ke všemu často používá paradoxně tato data proti občanům. Tak si říkám, jestli to řešení neleží pak úplně jinde ...
Ano, IPv4 (IPv6 scitaní.cz nepodporuje) adresy patří očividně MS Azure. Není mi jasné, odkud Rojíček bere, že data "Jsou na území ČR v cloudu, který provozuje stát. Přístup je umožněn jen vybraným pracovníkům statistického úřadu". [0] Data jsou snad ukládána šifrovaně... možná je to tedy o něco složitější:
"Vámi poskytnuté údaje jsou ukládány šifrovaně, a to ve vysoce zabezpečeném prostředí Státní pokladny Centra sdílených služeb na území České republiky. Státní pokladna Centra sdílených služeb disponuje vlastními bezpečnými datovými centry s nejmodernější architekturou. Data jsou následně v tomto zabezpečeném prostředí zpracovávána za účelem vytvoření statistických informací" [1]
[0] https://denikn.cz/minuta/591813/?ref=mpm (konkrétní odkaz na ČTK tam bohužel nedali)
[1] https://www.irozhlas.cz/zpravy-domov/scitani-lidu-2021-formular-data-bezpecnost_2103251044_ako
Samozřejmě, je otázka, jestli je šifrování asymetrické hned na klientovi (asi ne) a jak se s klíči dále pracuje, když už se tím šifrováním kasají. Nic proti tomu nemám, ale je také dobrá otázka, proč už frontend nemohl být "ve vysoce zabezpečeném prostředí Státní pokladny Centra sdílených služeb" (asi protože se s těmi lidmi/ rozhraním nedá moc dobře pracovat? protože to prostě nebude skutečný cloud ale glorifikované datacentrum nejspíš nad typickým VMWare stackem, ale to hledat nebudu.)
Nejaky naznak IPv6 na scitani precijen je... realne jen nekdo neumi poradne nastavit DNS.
www.onlinescitani.cz is an alias for csu-prod.azurefd.net. csu-prod.azurefd.net is an alias for star-azurefd-prod.trafficmanager.net. star-azurefd-prod.trafficmanager.net is an alias for dual.t-0009.t-msedge.net. dual.t-0009.t-msedge.net is an alias for t-0009.t-msedge.net. t-0009.t-msedge.net is an alias for Edge-Prod-PRG01r3.ctrl.t-0009.t-msedge.net. Edge-Prod-PRG01r3.ctrl.t-0009.t-msedge.net is an alias for standard.t-0009.t-msedge.net. standard.t-0009.t-msedge.net has address 13.107.246.19 standard.t-0009.t-msedge.net has address 13.107.213.19 standard.t-0009.t-msedge.net has IPv6 address 2620:1ec:46::19 standard.t-0009.t-msedge.net has IPv6 address 2620:1ec:bdf::19
Já jsem nakonec vlatně rád, že v tom má stát elektronický bordel. Jenom by zase získali další vektor člověka něčím prudit. Kdykoliv stát něco někde propojí nebo zprovozní, tak je to jenom k dalším problémům a otravování. Nechť se zeptají na co chtějí, aspoň je vidět, co zas provádí ...
Ve webařině jsem 10 let a s porovnáním co jsem viděl za poslední roky, tak toto bych ještě označil za zdařilý projekt a maximálně tak lehké komplikace ... pokud jim to teda pod náporem neshořelo ;-)
Kdyby jen Marie Terezie.Taky cesar Augustus by mohl vypravet. No coz. Treba bychom meli vanoce trochu jinak...
To ze se museli lide presunout do sveho trvaleho bydliste je takova libustka kterou urednicka pakaz tak nejak stale tech 2000 let opakuje.
V minulosti ridicaky, stale nutnost navstivit yrvale bydliste nebo mit volicsky prukaz na volby jinde atd.