Příspěvky

1

Vývoj / Javascript / React - Chybové hlášky v konzoli prohlížeče

« kdy: 15. 08. 2024, 15:43:36 »

Když vyvíjím frontend ve Vue nebo v Reactu, tak chybové hlášky, které lze najít v konzoli prohlížeče při procházení frontendové aplikace, jsou často napsané tak, že nejde v kódu najít místo, kde chyba vznikla.

Důvod, proč to nejde v kódu nalézt, je ten, že kód je do prohlížeče poslán zkompilovaný, tzn. potom typická chybová hláška vypadá třeba takto:

Kód: [Vybrat]

index.js:6
Warning: `value` prop on `input` should not be null. Consider using an empty string to clear the component or `undefined` for uncontrolled components.
    at input
    at td
    at tr
    at tbody
    at table
    at details
    at main
    at Component (http://localhost:60000/static/js/main.chunk.js:15616:88)
    at Route (http://localhost:60000/static/js/vendors~main.chunk.js:43137:29)
    at Switch (http://localhost:60000/static/js/vendors~main.chunk.js:43306:29)
    at Router (http://localhost:60000/static/js/vendors~main.chunk.js:42809:30)
    at HashRouter (http://localhost:60000/static/js/vendors~main.chunk.js:42360:35)
    at App (http://localhost:60000/static/js/main.chunk.js:82:97)

Načež jak asi tušíte, soubor "index.js:6" kam přesměruje browser když na hlášku vývojář klikne, odkazuje na onen zkompilovaný JS soubor a vývojář se nedozví nic.

Takže moje otázka je - dá se s tím vůbec něco dělat, abych se jako vývojář dozvěděl přesněji, kde je v kódu chyba? Co třeba nějak zapnout vývojářský režim a přimět NPM, aby ty soubory pro localhost nekompiloval?

2

Windows a jiné systémy / Autentikátor pro mobil umožňující plné zálohování

« kdy: 03. 08. 2024, 10:05:29 »

Mám starší iPhone kde používám Microsoft Authenticator pro přihlášení se do různých věcí k mým zákazníkům. Když bych přešel na nový iPhone, tak jsem si právě vyzkoušel, že sice zmíněný MS Auth umí udělat zálohu, ale neumí obnovit všechny tokenizery - u některých to chce, abych opět prošel procesem vytvoření tokenizeru, což řešit tenhle proces v korporátu u zákazníka je dost opruz.

Takže otázka zní, jestli neexistuje nějaký authentikátor, který umí udělat plnou zálohu. Přecejenom je to prostě software, má to nějaké svoje vnitřní id nebo něco, a nevím co brání tomu, abych si to v novém telefonu plně obnovil do původního stavu.

3

O serveru Root.cz / Co se to děje s rychlostí načítání Forum.root.cz?

« kdy: 28. 06. 2024, 12:23:38 »

Celé to tady vypadá, jak kdyby Root.cz přemigroval do Cloudu a nějaký diletant z managementu zamítnul zaplatit dostatečně dimenzovanou databázi.

4

Studium a uplatnění / Re:Snížení mezd v IT

« kdy: 27. 06. 2024, 15:36:00 »

A že by jste se podívali co říká český statistický úřad?

5

Hardware / Skleněná deska pro 3D tiskárnu Creality Ender 3

« kdy: 27. 06. 2024, 10:56:06 »

Zdravím,

mám tiskárnu Ender 3 a potřebuju koupit novou skleněnou desku na tisk. Ta originalní deska byla ze skla a měla k sobě kovové packy, kterýma se dala přidělat k základní kovové platformě.

Tady vidím že se prodává deska:

https://www.alza.cz/creality-pei-printing-platform-kit-d8602460.htm?evt=ac

Ale nemůžu najít náhradní pracky. Píšou nicméně u ní, že je magnetická - nepřichytí se mi díky tomu k té topné desce sama bez těch pacek?

Díky

6

Odkladiště / Re:Používáte WhatsApp/Mesenger kvůli kamarádům?

« kdy: 27. 06. 2024, 09:53:59 »

To je největší crap aplikace co vůbec je, nenávidím Facebook, ani si nejdou přes mobil přečíst zprávy, aniž by to nechtělo otvírat tuhle děsnou aplikaci.

A dneska už Facebook jenom otevřu, zjistím, že většina věcí na nástěnce je spam, a hned ten šrot zase zavírám. A s poplatkem 200,- Kč se museli zbláznit, tolik jim nikdy za ten jejich žďorb platit nebudu, ani nemám jistotu že mi přestanou tapetovat stránku marketingovýma skupinama.

A nesnáším už od pohledu toho zakladatele FB, vypadá jak ten robočlověk Dat ze Startreku.

7

/dev/null / Náhrada za Uloz.to?

« kdy: 06. 06. 2024, 19:19:46 »

Chtěl jsem se podívat na Youtube na Červeného trpaslíka, viz:

https://www.youtube.com/watch?v=rnJH50KFIiU&ab_channel=Petr%C5%A0t%C4%9Bp%C3%A1n

A zasekl jsem se na tom, že tam nejsou celée díly - ještě před nějakou dobou tam celé díly byly. No a na Uloz.to už to k mání není. A co se týče Torrentů, tak tam prokazatelně sondujou policajti.

Co se teď s tím dá dělat?

8

Server / Re:Výkonnostní spiky v trvání queries v Postgres

« kdy: 31. 05. 2024, 12:29:06 »

Jak říkám, cíl je stránkovat přes ty záznamy a vracet je přes API - to je cíl - není cíl se kochat jak se DB nenadře - máte business requirement na vaši službu a potřebujete implementovat stránkování. Buďto přes OFFSET a když je to teda antipattern, dobrá, tak tedy přes date.

To by nebylo špatný říct hned na začátku. Že vlastně nepotřebuješ OFFSET 500000, ale stránkování. Bez offsetu se dá stránkovat pomocí tzv. cursor-based pagination - místo abych v příštím dotazu řekl "chci stránku 10 s 50 záznamy na stránku", tak řeknu "Chci dalších 10 záznamů po X" (kde X je hodnota poslední položky na mojí stránce, podle které to mám seřazený)

Jo rozumím, na to potřebuju mít číslo záznamu a to musí být rostoucí, to je doable. Akorát teda když user přijde k UI a chce udělat jump v tabulce záznamů na stránku 100, tak se musí stejně proiterovat všechny předchozí stránky, aby si ono číslo záznamu na stránce 100 získal. Ale na některé věci se ten tvůj pagination určitě hodí víc.

9

Server / Re:Výkonnostní spiky v trvání queries v Postgres

« kdy: 30. 05. 2024, 13:10:58 »

Rozumím, dobře, díky za vysvětlení.

Takže příště stránkování se budu snažit dělat by date nebo něco podobného, a nikoliv by offset. Tím sice nejsem schopen pohlídat velikost stránky, ale může se to přesto v určitých chvílích hodit.

10

Server / Re:Výkonnostní spiky v trvání queries v Postgres

« kdy: 30. 05. 2024, 12:53:32 »

Ale ani v indexu není nikde informace,

Myslím, že tazatel naráží na "Index only access", které některé MVCC databáze co vím mají. Je to ale něco za něco, jestlitomu rozumím dobře, tak to znamená přepisovat do indexů informace o tom, zdali je záznam commited nebo ne, což znamená další IO režii navíc při zápisech (a kdovíjaké další problémy). Postgresql to do indexů co vím nezapisuje, takže nemůže tuto techniku použít.

Postgres má index only scan (s podporou visibility map). To vám zrychlí čtení dat, ale pořád při OFFSET 10000 musíte přečíst 10000 hodnot z indexu. Pokud chcete dělat efektivně s relačními db (nemluvím jen o Postgresu), tak OFFSET s nějakým vyšším číslem je antipattern

K tomu antipatternu. Řekněme, že mám tabulku:

Orders(id, date)

A budu tím chtít procházet. Můžu udělat:

SELECT *
FROM Orders
ORDER BY date ASC
LIMIT 500
OFFSET 100000

Nebo můžu ud2lat:

SELECT *
FROM Orders
WHERE date > '...' AND date <= '...'

A teď mi zkuste vysvětlit, v čem bude query dole rychlejší, když to nahoře je antipatern. Jak říkám, cíl je stránkovat přes ty záznamy a vracet je přes API - to je cíl - není cíl se kochat jak se DB nenadře - máte business requirement na vaši službu a potřebujete implementovat stránkování. Buďto přes OFFSET a když je to teda antipattern, dobrá, tak tedy přes date.

Technicky vzato, v čem se ve druhé případě postgres méně nadře?

Protože v prvním případě se musi engine podívat do date_index a proiterovat prvních 100000 entries, aby si to následně vybralo 500 následujíchc entries a vytáhnout si je z tabulky Orders, kde je 10 mil záznamů.

Ve druhém případě však musí udělat totéž: musí si proiterovat date_index, zjistit, které záznamy zplňují podmínku, a potom si je vytáhnout z tabulky Orders.

To vyžaduje trochu vysvětlení, proč je v tom případě OFFSET antipatern.

11

Server / Re:Výkonnostní spiky v trvání queries v Postgres

« kdy: 30. 05. 2024, 11:45:03 »

Jasně tomu rozumím a dává mi smysl, že když řeknu postgres:

ORDER BY date OFFSET 250000 LIMIT 500

Tak použije index a query je hotový ve stovkách ms. A když řeknu Postgres

ORDE BY date OFFSET 500000 LIMIT 1000

Tak už query trvá přes 10 vteřin, protože se postgres přepne.

Ale: Kdyby se to nepřeplo, tak to určitě nebude trvat několik vteřin ale prostě násobek toho horního času. Tzn. já vím, že by theory někde je řečeno, že v určitých situacích je seq scan rychlejší než index scan s následným randomom access, ale v >> praxi <<, protože ladím postgres queries posledních 5 let často, tak jasně vidím, že seq scan zpravidla nikdy nechci, protože trvá >> násobně << déle. V praxi.

Takže někde "in RDB theory" je lepší seq. scan, ale v praxi já jasně vidím, že zpravidla vždycky je lepší index scan.

Taky kolikrát jsem zuřil když jsem hledal, proč mi pg přepne na seq. scan, a X-krát jsem četl, že je seq scan výhodnější v určitých situacích, a já přitom jasně vidím, že je násobně nevýhodnější, a vidím to jasně i teď u výše uvedených queries.

A potom co se týká toho ORDER BY, tak já asi pořád nesouhlasím s vám v tom, že to neumí zjistit OFFSET 10000 hned indexu. Protože ty indexy jsou sortovány. Pakliže já mám v indexu sortovány záznamy podle datumu Ascending, tak můžu skočit na záznam č. 10001 v INDEXU, a vím, že je na stránce 12345 na řádku 123. Z indexu si pak načtu pozice dalších 500 záznamů a vím, že jsou sorted a že jsou OFFSET 10000 v tabulce.

By theory jistojistě to udělat takto lze, technicky. O tom jsem přesvědčen. jestli to však je v silách Postgres to nevím. Já na vlasnní oči viděl, jaké dokáže Postgres query engine dělat do očí bijící nesmysly.

Jako např. že si je schopno počítat json_agg funkce a jine funkce v SELECTU u záznamů, které nejsou vráceny v konečném
výsledku dotazu, a zpomalí tím query násobně.

Nebo to, že Postgres nedokáže optimalizovat Views používané ve FROM klauzuli v jiném View, tzn. nedokáže jakoby "mergnout" a optimalizovat 2 selecty ve 2 Views. A tak namísto Views já musím uděla strašný copy-paste a použít jeden obří SQL query, aby Postgrs pochopilo, že některé věci může vykrátit. Katastrofa, a vede to k velkému nepořádku, protože Views mají velké SQL queries schovávat.

12

Server / Re:Výkonnostní spiky v trvání queries v Postgres

« kdy: 30. 05. 2024, 08:27:45 »

Takhle v principu tpo přece nějak musí umět fungovat, ne? Nehledě na to, že technicky vzato můžu na SSD disk se speciálním naformátováním vkládat záznamy do jednotlivých bloků, každému bloku dám identifkátor, a potom s tím SSD diskem rovnou skočím na daný blok. I tohle technicky vzato je proveditelné, že můžu na záznam skočit přímo. A když ne přímo, tak alespoň na nějaký agregační uzel, a z něj už potom přímo.

Tak by mě zajímalo jak to dělá postgres.

Databáze označuje řádky číslem datové stránky a pozicí na stránce - můžete se jednoduše a rychle přesunout na 100 stránku a 10 řádek na této stránce. Ale nikdy nevíte kolikátý je to řádek od začátku tabulky (nevíte kolik je řádku před a nevíte kolik je řádků za).

Ale to přece víte, protože jste na tu 100 stránku a 10 řádek skočil prostřednictvím toho indexu. A vy podle indexu víte, že to je offset 10000 třeba.

13

Server / Re:Výkonnostní spiky v trvání queries v Postgres

« kdy: 29. 05. 2024, 20:02:49 »

Takto by to přece mělo fungovat, ne? Tzn. tabulka Objednávky co má 40 sloupců může mít klidně 10GB, ale index idx0 má třeba jen 500MB, a ani ty se nemusí přečíst všechny, stačí nad tím indexem, tzn. souborem na disku, udělat iteraci 250000 záznamů a dalších 500 vrať.

Někdy bych byl rači kdybych si ty query plany mohl psát sám.

Ne tak to nefunguje - tabulka není pole - je to halda, kde data mohou být kdekoliv - řádky nejsou očíslované. Možná si index můžete vynutit použitím ORDER BY - nicméně pořád se bude skrz index číst 250000 záznamů, což je zoufale pomalé. I kdybyste si ty query plány psal sám, tak by vám to bylo k ničemu, jelikož v relační databázi není žádná rychlá možnost skoku na ntý záznam. V historických databázích s fixní délkou věty to šlo, pokud jste z tabulky nikdy nemazali, ale v moderních relačních databázích s proměnlivou délkou věty žádná taková magie není.

No počkat, tohle bych potřeboval líp pochopit. Databáze si přece i na disku dělá svoje speciální soubory, a měl jsem i v představě či v naději, že si to umí pracovat až s jednotlivými bloky na disku.

Pokud vy si v indexu najdete přes query 1 zázname přes equals, tak ten index musí vrátit nějaký identifikátor, ne? A ten identifikátor to musí být něco, jak vytáhne ten záznam z té originální velké tabulky.

Tzn. index "něco" vrátí, a databáze na to něco v tabulce dokáže "skočit", a když ne skočit tam přímo, tak alespoň přibližně skočit někam, proiterovat omezenou množinu dat, najít záznam a vrátit ho. Jako Hashmapa.

Technicky vzato, když se nad tím zamyslím jako programátor. Mám nějakou tabulku, tak ji budu reprezentovat soubory na disku. Těch souborů tam může být třeba 100000. A když mi někdo řekne "Dej mi záznam "93fj2fj209fjh2dgrd3109f92", tak já vím, že tento záznam bude v souboru s číslem 12344.

Takhle v principu tpo přece nějak musí umět fungovat, ne? Nehledě na to, že technicky vzato můžu na SSD disk se speciálním naformátováním vkládat záznamy do jednotlivých bloků, každému bloku dám identifkátor, a potom s tím SSD diskem rovnou skočím na daný blok. I tohle technicky vzato je proveditelné, že můžu na záznam skočit přímo. A když ne přímo, tak alespoň na nějaký agregační uzel, a z něj už potom přímo.

Tak by mě zajímalo jak to dělá postgres.

14

Server / Re:Výkonnostní spiky v trvání queries v Postgres

« kdy: 29. 05. 2024, 18:36:48 »

Nicméně tyto queries tam samozřejmě nespouštím běžně, říkám jen, že dokáží způsobit spike a r
Neodpustím si však poznámku, že nakolik ORDER BY date OFFSET 500000 LIMIT 1000 zní šíleně, pořád by to mělo být přes index, tzn. těch 1000 řádků si to nejprve najde přes index, a potom z tabulky si to natáhne oněch 1000 záznamů přes random access. Nelíbí se mi, že to způsobí spike, protože to přece není zase taková hrůza, jak se zdá. To Postgres tam něco "vyvádí".

OFFSET neznamená jump na pozici - znamená zahoď, co jsi spočítal - takže když tam máte OFFSET 500000 LIMIT 1000, tak se samozřejmě index nepoužije - jelikož čtete víc než čtvrtinu tabulky.  Tohle nemůže fungovat - jestli stránkuje tímhle mechanismem, tak je hodně nešťastné - buďto to musíte převést na WHERE id > x LIMIT 1000 nebo používat kurzor a postupně si fetchovat.

Dobře řekněme že mám tabulku:

Objednavky

A mám tam 10 mil záznamů. A udělám:

SELECT *
FROM Objednavky
ORDER BY date ASC
OFFSET 250000
LIMIT 500

A mám index:

CREATE INDEX idx0 ON Objednavky (date ASC)


Tak potom query plan by měl postupovat takto:

1. Vlezu do indexu idx0
2. Ten je sortován by default ASC.
3. Přeskočím prvních 250000 záznamů z indexu
4. Vezmu následujících 500 záznamů v indexu
5. S těmi záznamy z indexu vlezu do tabulky Objednavky a načtu z disku oněch 500 záznamů přes random access.

Takto by to přece mělo fungovat, ne? Tzn. tabulka Objednávky co má 40 sloupců může mít klidně 10GB, ale index idx0 má třeba jen 500MB, a ani ty se nemusí přečíst všechny, stačí nad tím indexem, tzn. souborem na disku, udělat iteraci 250000 záznamů a dalších 500 vrať.

Někdy bych byl rači kdybych si ty query plany mohl psát sám.

15

Server / Re:Výkonnostní spiky v trvání queries v Postgres

« kdy: 29. 05. 2024, 17:53:39 »

Nj, jenže je otázka, co to je to čtení každých 30s.

Pakliže já mám dobře udělané indexy, tak queries mi vrací max řekněme 100 záznamů. Co na tom záleží, že je tam 8GB dat, když podle index scanu se jich načte z tabulky jen třeba 100.

Problém můžou být queries typu ORDER BY date OFFSET  250000 LIMIT 500, ty dokážou spolehlivě vytvořit spike, trvají přibližně 2 vteřiny.

Zajímavé je, že už třeba query ORDER BY date OFFSET 500000 LIMIT 1000 dokáže v 50% případů trvat přes 30s, tipuju že se to občas přepne na sequential scan.

Nicméně tyto queries tam samozřejmě nespouštím běžně, říkám jen, že dokáží způsobit spike a request co trvá 30ms rázem trvá přes 300ms.

Neodpustím si však poznámku, že nakolik ORDER BY date OFFSET 500000 LIMIT 1000 zní šíleně, pořád by to mělo být přes index, tzn. těch 1000 řádků si to nejprve najde přes index, a potom z tabulky si to natáhne oněch 1000 záznamů přes random access. Nelíbí se mi, že to způsobí spike, protože to přece není zase taková hrůza, jak se zdá. To Postgres tam něco "vyvádí".

Zároveň s tím, ORDER BY date OFFSET  250000 LIMIT 500 si nemyslím že by mělo trvat 2 sekundy, když to jde přes index. Přijde mi to jako moc.

Líbilo by se mi, kdyby to dokázalo udělat OFFSET 500000 LIMIT 1000 a zároveň s tím by mi délka hlavních requestu nepřekročila 300ms. Kdyby to zvládlo tohle, měl bych klid a jistotu, že DB je dostatečně dimenzovaná.