Příspěvky

91

Server / Re:PostgreSQL - zvládne 400m řádků?

« kdy: 28. 12. 2021, 14:42:44 »

Zdar,

mam jednu PostgreSQL tabulku s touhle strukturou a 400 miliony radku:

id (autoinc), 10x text (max 256zn.), 10x jsonb (max par tisic znaku)

Na par text sloupeccich je dany index.

Jaky potrebuji HW, nebo co a jak tam nastavit, aby to zvladalo kolem 1k SELECT/UPDATE/INSERT dotazu (tj. 3k dotazu) za vterinu soucasne (a tohle bude muset bezet "nonstop").

Dotazy se vazi na jeden text sloupecek jako identifikator (je unikatni ale je na nem index), zadne slozite veci u toho dotazu nejsou.
Zkousel jsem to na serveru se ssd disky a 64gb ram a... tfujky, absolutne to nedava.
S ohledem na obsah tabulky by ji asi neslo rozdelit do vice tabulek.

Co s tim? Klidne muzu vymenit za jinou db, ale radeji bych zustal u PostgreSQL.

U téhle velikosti to už chce používat partitioning, a při nonstop zátěži 1K DML a 3K SELECTů za sec to už chce i vymyslet nějaké horizontální škálování. Minimálně potřebujete vacuovat tabulky, a budete potřebovat reindexaci. Update velkých tabulek je dost drahá záležitost - zvlášť pak když jsou bloatlý indexy. 1000 DML za sec nekolika kb jsonu - to musí být peklo. To vám pomalu nemůžou dát ani ta SSDčka.

Můžete zkusit MySQL - UPDATE tabulky s větším množstvím oindexovaných sloupců je na MySQL rychlejší. Nicméně je otázkou, co se vám vejde do paměti, a jak často budete muset hrabat na disk. I pro MySQL platí, že pro rychlý přístup musí být drtivá většina dat v RAMce. Pro ten požadovaný výkon musíte mít dotazy hodně pod 10 ms, spíš pod ms, takže to chce hodně RAM, hodně IOPS, a hodně CPU.

92

Server / Re:Pomohl vám Elasticsearch?

« kdy: 24. 12. 2021, 13:29:32 »

Z 20K položek musí libovolná sql databáze našeptávat realtime  

Jde o to, zda chcete jenom hloupě našeptávat přesně ty položky, které v databázi jsou, nebo jestli chcete řešit překlepy, psaní bez diakritiky, synonyma apod.

Tohle všechno umí fulltext v pg (MySQL neznám, takže tam nevím).

93

Server / Re:Pomohl vám Elasticsearch?

« kdy: 23. 12. 2021, 13:15:16 »

Dále je tu parametrické vyhledávání produktů.
V ES je rovněž možné takové vyhledávání použít, ale nevím jestli je ES pro tento účel vhodný.

Áno, ES je pre tento účel vhodný, má na to špecializované indexy.

Je tu někdo kdo řešil podobnou migraci a byl by ochotný sdílet zkušenosti před/po?
Měla taková migrace smysl?
Zaznamenali jste lepší odezvy svých vyhledávačů?

Špecializované fulltextové vyhľadávače spravidla prinášajú nasledovné výhody:
- podpora skloňovania (stemming alebo lematizácia) - pri dátach, kde je dôležité hľadať podľa obsahu neštruktúrovaného textu (napr. články) je dôležité, aby vyhľadávač našiel aj skloňované tvary hľadaných výrazov (niektoré relačné databázy už na to majú podporu, neviem, či aj MariaDB)
- podpora zvýrazňovania nájdených slov v texte - uľahčuje používateľom posúdenie, či ponúkané výsledky vyhľadávania naozaj zodpovedajú tomu, čo chcel nájsť
- podpora generovania krátkych sumárov z textu pre potreby zobrazenia ukážky vo výsledkoch vyhľadávania, ideálne z tej časti textu, kde sa našli hľadané výrazy (a so zvýraznením nájdených výrazov)
- možnosť automaticky ponúknuť používateľom obsahovo podobné dokumenty
- vyššia rýchlosť vyhľadávania v porovnaní s fulltextovým vyhľadávaním v relačných db

V závislosti od konkrétneho usecase-u odporúčam zvážiť aj použitie fulltextového engine-u Solr - pokiaľ nepotrebujete špecializované výpočty nad dátami, tak je IMHO jednoduchší na implementáciu, pričom má rovnaké jadro ako ES.

Dost ze zde uvedeného seznamu mají dnešní fulltexty v databázích (třeba i ten z Postgresu). Co je potřeba říct, je že Elastic je inmemory databáze, a inmemory indexy z podstaty mají jinou strukturu než klasické indexy, a operace nad nimi jsou rychlejší. U vyšší zátěže - nad 1000 req. za sec to svůj význam má. U méně zatížených systémů to může být zbytečný a drahý kanón na vrabce.  V GD na údržbě elasticku, který běžel jako podvozek splunku dělal jeden člověk na fulltime, aby to udržel při životě. A v případě identifikace problémů byl splunk extra užitečný.

94

Studium a uplatnění / Re:Průměrná doba pracovní neschopnosti za rok?

« kdy: 22. 12. 2021, 07:49:17 »

Pracovní neschopnost trvala v průměru 42,4 dne

ty bláho, tak to by měl zajímalo kdo ten průměr dělá... Osobně jsem nebyl nemocný více jak 20 let, ani ve svém okolí neznám moc lidí, kteří by byly nemocní.

Přes 40 pracovních dnů, to je šíleně moc...

to číslo ale řiká úplně něco jiného a ty v něm tedy nejsi. Ta věta se vztahuje pouze na ty nemocné (neříká ani kolik jich bylo z celku) a pro ně nemocenská byla v průměru 42 dní za rok. Pozor počítají se i toho případy ošetřovačky, kdy jsi doma s dětmi, když jsou nemocní, stejně tak v tom jsou započteno těhotenství. Právě ošetřovačky a chronicky nemocní tohle číslo takhle zvedají. Nezapomeň na vážné úrazy či hospitalizace, tam to snadno skáče do měsíců.

Navíc, je to průměr, který je citlivý na extrémy. Něco jiného by byl medián.

95

Server / Re:Mazání řádků na SQL serveru a uvolňování místa

« kdy: 18. 12. 2021, 04:29:13 »

(Tady je vidět, k čemu je alespoň základní IT vzdělání, tohle se bere na VŠ snad hned v prváku.)

Tak třeba na informatice na matfyzu byly databáze doporučené ve druháku a o vacuumu se tam nemluvilo (samozřejmě si to nemůžu s jistotou 7 let pamatovat, ale ve slidech se slovo vacuum nevyskytuje a slidy k tomuto předmětu jsou celkem verbose).

To, o čem je zde řeč, je shrink. Většinou se o tom mluví v momentě, kdy se mluví o implementaci DELETE, který fyzicky nemaže záznamy ze souboru, a tudíž je zřejmé, že na shrinknutí musí být speciální operace - rebuild ať už podporovaný databází nebo ruční dump/load. Taky se o tom může mluvit, když se řeší, jak se fyzicky data ukládají na disk.

96

Server / Re:Mazání řádků na SQL serveru a uvolňování místa

« kdy: 17. 12. 2021, 19:43:11 »

Velmi záleží na objemu dat a toho, co se v daném sloupci vyskytuje za hodnoty, např. pokud budu mít 10000 záznamů jsou indexy v podstatě k ničemu. Naopak pokud mám 100mil záznamů, tak ano, ale pokud daný sloupec může být jen boolean, index postrádá smysl. Ale to jen tak na okraj. Bohužel hodně lidí si myslí, že více indexů, tím super rychlost...

I tohle je pravdivé jen částečně. Nezáleží na typu hodnota, ale na histogramu hodnot. Když budete mít tabulku se sto milionem záznamů, ale řádků s hodnotou true bude 100 a ty budete hledat, index se vám sakra vyplatí (zejména funkční, ve kterém budou jenom ty true hodnoty). I u těch desítek tisíc záznamů se může sloupec dost vyplatit, zejména pokud ta tabulka bude velká nebo dokonce data, která vás zajímají, vyčtete rovnou z indexu.

Podmíněnými indexy (alespoň takhle se to jmenuje vpg) můžete ty nezajímavé hodnoty odfiltrovat. Výsledný index bude výrazně menší - jen 100 hodnot, což má jen pozitivní efekty

97

Server / Re:Mazání řádků na SQL serveru a uvolňování místa

« kdy: 17. 12. 2021, 13:35:37 »

Diky,
je to MariaDB a nejde o performance, ale o uvolneni cca 10 TB mista na disku, ktery uz nestaci.
trochu nas prekvapuje, ze to musime resit my a ze se to nedeje v ramci nejake maintainace automaticky a periodicky

Tohle nedělá žádná databáze. Defragmentace, shrink, ... je časově náročná operace, většinou vyžaduje dost agresivní zámky, a to si nemůžete dovolit volat automaticky.

Ovšem pochybuju že budou zákazníci vždy tak disciplinovaní, že si to nastaví sami, zvlášť u Mysql/MariaDB.  Taky bych spíš čekal, že to bude mít provider nějak defaultně nastavené - třeba s možností si to v cronu přenastavit nebo něco podobného.

Jinak mimochodem Postgres v rámci auto vacuum provádí co přesně?

Nikdy jsem MySQL neprovozoval, takže nevím. Ale tipoval bych, že se to řeší nastavením maximální velikosti na disku a pak nějakým varovným mailem - případně plánovanou nebo neplánovanou odstávkou. U hostingů za 200 kč na měsíc nikdo nic nebude extra řešit. U těch důležitějších systémů tam se to dá možná pořešit bezodstávkově multimastrem.

Na druhou stranu, pokud se nemění poměry tabulek, tak shrinkování tabulek nedává moc velký smysl (pokud neřešíte bloating).

autovacuum řeší - lazy vacuum - odstranění mrtvých verzí (při 20% změněných řádků), platné verze jsou beze změny, analyze - přepočítání statistik (10%) a vacuum freeze (200M transakcí) - "jakoby" reset transakčních id. Všechny zmíněné příkazy mohou hodně cvičit s diskem, ale žádný nevyžaduje exkluzivní zámek.

98

Server / Re:Mazání řádků na SQL serveru a uvolňování místa

« kdy: 17. 12. 2021, 05:27:04 »

Diky,
je to MariaDB a nejde o performance, ale o uvolneni cca 10 TB mista na disku, ktery uz nestaci.
trochu nas prekvapuje, ze to musime resit my a ze se to nedeje v ramci nejake maintainace automaticky a periodicky

Tohle nedělá žádná databáze. Defragmentace, shrink, ... je časově náročná operace, většinou vyžaduje dost agresivní zámky, a to si nemůžete dovolit volat automaticky.

99

Server / Re:Postgresql - SPI-Trigger nebo udf-funkce

« kdy: 10. 11. 2021, 04:16:17 »

Obecne bych jeste rad znal nazor, zda se to SPI programovani stale nejak vubec pouziva -> na internetu je toho relativne malo. Aby to nebyla slepa ulicka.

SPI API se normálně používá pro psaní postgresových extenzí. A pokud chcete pracovat přímo s pamětí, tak C je víceméně jediná cesta. Vlastní extenze nejsou v Postgresu něco až tak neobvyklého. Samozřejmě, že většina uživatelů nic takového nedělá, ale ti zase většinou nemusí dělat přímo s pamětí. Omezení je jediné. Vaše extenzi určitě nanajdete v cloudu, pokud byste chtěl provozovat pg jako službu.

O psaní extenzí je toho na netu docela dost. Není to nic komplikovaného, i když pro vetšinu uživatelů je to raketová věda, ale to je i lateral join nebo CTE.

100

Server / Re:Postgres - nekompletni restore pres pg_dump

« kdy: 16. 09. 2021, 08:49:57 »

pg_dump backupuje i prazdne tabulky.

Je mozne, ze originalni databaze byla poskozena, a ze pg_dump nedobehl kvuli chybe. Pripadne pg_dump mohl nedobehnout kvuli chybejicim pristupovym pravum k databazovym objektum. U pg_dumpu je vzdy (jako u kazde aplikace) sledovat result code. Duvodu proc nemusi dobehnout muze byt cela rada. Obcas se take stane, ze se backupuji jine db na jinych serverech, nez uzivatel myslel, a prijde se na to az pri restore. pg_dump je natolik jednoducha a overena aplikace, ze bych spis tipoval na nejake prehlednuti nebo opomenuti uzivatele, ale zpetne tezko rict, o co se jednalo.

101

Server / Re:Spolehlivá databáze jako náhrada Oracle AQ

« kdy: 23. 08. 2021, 09:46:07 »

Ahoj, k plne spokojenosti na jednom projektu provozujeme Oracle AQ kde pres to bez nejmensich problemu protekly miliardy msg. Ted uvazujeme o prechodu ( jako alternativu ) na jinou DB platformu.

Problem je ze nevim (resp. nenasel jsem)  jestli pro MySQL, PgSQL apod existuje neco podobneho. Nepotrebuji zadne silene HA reseni, staci mi neco co bude spolehlive frontovat jednoduche msg (enqueue, dequeue, single-consumer).

Pro PostgreSQL existuje https://github.com/pgq/pgq - roky nad tím byl postavený Skype, tak to asi bude použitelné.

102

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 07. 07. 2021, 08:50:22 »

treba casto k nejake tabulce joinujete jinou tabulku s nejakou netrivialni podminkou, nad hodnotami z te jine tabulky provadite nejake netrivialni mapovani

takovych operaci je vic a chcete je ruzne kombinovat

muzete vytvorit pro kazdy pripad zvlastni pohled, nebo nechat ORM ty dotazy generovat

Jinak v SQL mám pro tento účel pohledy (kdybych chtěl udělat tyto vazby perzistentní) anebo CTE pro semi pohledy.

Ale je to jedno, jestli pohledy si vytváříte aplikačně nebo databázově. Dneska i 8 řada MySQL už umí nematerializované pohledy, takže není důvod obcházet databázi.

103

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 07. 07. 2021, 08:46:08 »

ORM ma vic informaci nez schema, ma treba vic moznosti jak preddefinovat ruzne implicitni joiny.

treba casto k nejake tabulce joinujete jinou tabulku s nejakou netrivialni podminkou, nad hodnotami z te jine tabulky provadite nejake netrivialni mapovani

takovych operaci je vic a chcete je ruzne kombinovat

muzete vytvorit pro kazdy pripad zvlastni pohled, nebo nechat ORM ty dotazy generovat

Jasně, ale a) je to statická věc - nepodchytíte tím žádnou dynamiku, b) není to nic, co by ORM získalo samo, musí to programátor explicitně napsat - a je funkčně jedno jestli to programátor udělá ručně SQL nebo přes definici v aplikaci, a pak to SQL vygeneruje query builder.  ORM nikdy nemůže získat žádnou znalost samo. A minimálně v tuto chvíli neexistuje samoučící se (adaptabilní) ORM systém - všechno to jsou statické systémy.

Je velký rozdíl jestli píšete aplikaci vůči velké databázi s netriviální zátěží nebo s malou databází s malou zátěží. U velké databáze by měl komplexní SQL dotaz programátora "bolet". Chtěnou vlastností různých ORM systémů je maskování komplexity dotazů - jenomže to způsobuje dva problémy - umožňuje dlouhodobě pracovat s špatně navržený datovým modelem, aniž by se programátor pozvracel - ale špatně navržený datový model nutně vede k pomalým dotazům a slabému výkonu - a v pozdější době, kdy už programátor musí psát některé dotazy ručně, tak zvrací každý den, nebo striktně odmítne jakýkoliv zásah - a pak tam máte dotazy, které ručně trvají 20ms, a generované 20000ms - a pokud takových dotazů máte víc, tak hezky tavíte CPU.

104

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 07. 07. 2021, 07:43:09 »

ORM ma vic informaci nez schema, ma treba vic moznosti jak preddefinovat ruzne implicitni joiny.

105

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 07. 07. 2021, 06:50:09 »

To je tak vágně položený příspěvek, že na něj nejsem schopen šikovně reagovat. Obecně v něm tuším názorový vzor, stejně jako u @Miroslav Šilhavý, že ORM nemůže (z principu) něco vidět, co vývojář může. S tím kategoricky nesouhlasím. Jistě, jsou určité okrajové oblasti které může vědět pouze vývojář - například, že nějaká tabulka se nemá z iracionálních důvodů optimalizovat. Ale to jsou okrajové případy řešitelné natvrdo hintem. Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe.

V databázi (ve schématu) nemáte žádné informace o procesech - o tom, jak se data mění, v jakých proporcích, jak a kde dochází k zámkům, atd atd. Schéma je statická záležitost - minimálně v tuto chvíli neumí popsat dynamiku dat a dynamické (chronologické) závislosti. Schéma například neobsahuje žádnou informaci o frekvenci update, kterou já jako vývojář beru v potaz už při návrhu schématu. Jelikož sleduji vývoj zpracování statistik (práce Tomáše Vondry), tak vím, jak je náročné vysledovat něco, co není explicitně zadáno v datech databáze (například závislosti mezi sloupci, korelace mezi tabulkami). Ne, že by to nebylo technicky realizovatelné - ale ta úloha je náročná - příliš dat, příliš kombinací. Takže větu "Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe." považuji za úplně odtrženou od reality. Databáze je model, popisuje zjednodušenou realitu, a tudíž nemůže principiálně obsahovat vše, a je potřeba brát v potaz výpočetní náročnost optimalizačních úloh.